PCI Compliance Dashboard - v10

Table of content
Introduction and News

Glossary
Executive summary
Chart - % Compliance
Chart - Severity
PCI Team
Scope definition
Documentation
Crypto Keys list
Merchant types
Compensating Controls definition
Vulnerability scans
Penetration tests
SANS-PCI Matrix
Requirement 1
Requirement 2
Requirement 3
Requirement 4
Requirement 5
Requirement 6
Requirement 7
Requirement 8
Requirement 9
Requirement 10
Requirement 11
Requirement 12
Return to Table of content
PCI Compliance Dashboard VERSION 10

Please feel free to use this compliance dashboard to sustain your PCI compliance jour
discussion with your internal team, QSA and acquiring banks.
Comments, feedbacks and suggestions are welcome. Send them to Didier Godart (D@d
Some sheets are protected to prevent accidental changes. You may unprotect them at a
required.
Version history
What's new in this version
PCI 30 seconds newsletters
Table of content
How to start using this dashboard?
1.Define your scope (Scope sheet)
2.Define your PCI Team (PCI team sheet)
3.Select your Merchant type (Excutive Summary sheet)
4.Optionally select the option to show all requirements or Hide non applicable requirements
5.For each requirement sheet:
6.Select the appropriate answer (In place or Not) and fill appropriate cells (Proof, Stage,remediation, estimated, Com
the owner responsible for actions)
7.In case of compensating controls provide the description within the associated compensating controls sheet
8.Control your compliance status through the Excutive summary board (Executive sheet) and associated charts (% of
Severity)
Version History
V0.1 Requirements and testing procedures Jan-11
V0.2 Add merchant type for each requirements Feb 2011
V0.3 Include Prioritized Approach milestones as defined by PCIco August 2011
Add a column Priority with PCIco Milestones (1 to 6)
Add a column Status of implementation
Add a column Estimated date to completion
Add sheet actors
V0.4 Add a sheet" What is my merchant Type?" with the full description of the merchant October 2011
types
Add Major observations from the 2011 Verizon PCI Compliance Report for each of
the twelve requirement
Add a column "Validation instructions for QSA/ISA" from the new released ROC-
QSA Reporting Instruction Manual
V0.5 Add Guidance for each requirements from the "Navigating PCI DSS V2.0" November 2011
Add a compensating control sheet for the definition and management of
compensating controls. Whenever a compensating control is present refer to it into
the column (in place) by the associated ID into the compensating controls sheet
Add Glossary
Add an Executive Summary Tab Including # of requirements, % of compliance, December 2011

Severity (sum of all severities) depending on the selected merchant type.
Add Charts Tab including Severity per Requirement and % compliance per
requirement
Add Severity Column (= PCI defined priority for not in place requirements)
Add list boxes for the In place/not in place and Compensating control present.
V0.6 All sheets are protected to avoid accidental deletion. (No password)
Instructions:
1.Select your merchant type within the sheet "Executive summary"
2.Select the appropriate answer for each requirements (Column L: Y/N/C)
3. Use the compensating controls sheet to describe your controls whenever used.
4.View your compliance progress through the "Executive summary" and " Charts"
sheets.
V0.7 1.Navigation: Add Table of content and navigation links May 2012
2.Rename sheet "PCI Actor" to "PCI Team"
3.Associate column "Owner" in requirements sheets to the name of individuals
listed within sheet "PCI Team". A list box allows the selection of a name from this
sheet.
4. Add Documentation sheet listing all your documentation related to PCI.
5.Add row "SANS Top 20 Critical Security Controls" - Matching subcontrols for each
PCI requirement wherever possible.
6.Add Sheet " SANS-PCI" Listing all SANS Top 20 Critical Security Controls and Sub-
controls together with PCI requirements partially or fully matching the sub-
controls. Also % of match for each SANS Controls. For more details on the Matching
matrix read the associated Technical paper "PCI-SANS Top 20 Critical Security
Controls"
7.Add "Scope" sheet allowing you to define the Card Data Environment (CDE)
8. Add two buttons within the Executive Summary Sheet allowing you to
hide/unhide non applicable requirements associated to the selected Merchant
Type (THANKS to Tony). Macros do not work on MAC.
9. Dissociate form chart sheet in two specific chart sheets (% of compliance and
Severity)
V0.8 Adapt SANS numerotation to new version (Version 3.1 October 3, 2011) July 2012
WHAT'S NEW IN THIS VERSION

V0.9 Update the documentation sheet with the list of (required or optional) technical April 2013
and non-technical documents together with their associated PCI DSS requirements.
V10 Update Scope sheet with Criticality, Patch level, Scan date and Scan report location June 2013
Add a sheet "PCI Crypto Key list" to list all keys used within the scope: KeyId,
Purpose, Key custodians, status.
Add sheet Vulnerability scans (When, By who, results)
Add sheet Penetration Tests (When, By who, resulls)
Compliance Dashboard home page
PCI 30 Seconds Newsletters

PCI 30 Seconds newsletter #1 - PCI what are you talking about?
PCI 30 seconds newsletter #2 - Payment processing terminology and workflow
PCI 30 seconds newsletter #3 - Distributing roles
PCI 30 seconds newsletter #4 - Merchant levels
PCI 30 seconds newsletter #5 - What is your type?
PCI 30 seconds newsletter #6 - PCI DSS in a nutshel
PCI 30 seconds newsletter #7 - Define the scope of an assessment
PCI 30 seconds newsletter #8 - certification program, striving for quality
PCI 30 seconds newsletter #9 - The validation toolbox
PCI 30 seconds newsletter #10 - Prioritized Approach
PCI 30 seconds newsletter #11 - Tokenization
PCI 30 seconds newsletter #12 - the gap analysis process
PCI 30 seconds newsletter #3 - Compensating controls, magic trick or mirage?
PCI 30 seconds newsletter #14 - The world is not perfect!
PCI 30 seconds newsletter #15 - Nice Look!
PCI 30 seconds newsletter #16 Is your organization behaving like a fashion victim or a clown?
PCI 30 seconds newsletter #17 Why are my scan reports so thick? - Impact of "potential" vulnerabilities
PCI 30 seconds newsletter #18 What to do if compromised?
PCI 30 seconds newsletter #19 - Your PCI Logbook. What's required in terms of Log management?
PCI 30 seconds newsletter #20 PCI DSS and SANS Top 20 Critical Security Controls: The Sumo match.
PCI 30 seconds newsletter #21 - "Qualified" internal scanning staff using "appropriate" scanning tools - What does th
PCI 30 seconds newsletter #22 - Don't get lost in translation with Executives. Get them listening.
PCI 30 seconds newsletter # 23 Introduction to Risk Assessment
PCI 30 second newsletter #24 - PCIco strengthens the scoping rules
PCI 30 seconds newsletter #25 - A New Standard is Born.
PCI 30 seconds newsletter #26 - PCIP is it worth it?
PCI 30 seconds newsletter #27 -Static versus Active Protection Systems. What Impact on Quarterly Scans?
PCI 30 Seconds newsletter #28 - The PCI Library - What docs are required for compliance?
PCI 30 seconds newsletter #29 - Do all PCI DSS requirements apply?
PCI 30 seconds newsletter #30 - Trainings your organization must deliver to comply with PCI DSS
Other articles
Ebook - Demystifying PCI DSS
Thoughts on the Verizon PCI Compliance Report
Can I use compensating control to resolve vulnerabilities found during a scan?
What to do if my organization can't demonstrate four passing Internal or external scans?
Verizon 2011 PCI Compliance Report
Business and IT security: two worlds that can't talk.
Cyber attack ranked within the top 5 risks in terms of probability
RSION 10
PCI compliance journey, to support the
Didier Godart (D@dgozone.com).
unprotect them at any time. No password
nts
mediation, estimated, Comments and select
sating controls sheet

and associated charts (% of compliance and
Contributors
Peter Hill
Didier Godart
Risk Product Manager Rapid7
+32 498787744
SkypeID Dgozone
didier_godart@rapid7.com
Didier Godart
+32 498787744
SkypeID Dgozone
Didier Godart
+32 498787744
SkypeID Dgozone
Didier Godart
+32 498787744 About Didier About Rapid7 Join the community!
SkypeID Dgozone
Didier Godart
+32 498787744
SkypeID Dgozone
didier_godart@rapid7.com About Didier About Rapid7 Join the community!
Swathy Anand About Swathy About Fuze Network

Vice President - Project
Management
Fuze Network
swathyanand@gmail.com
Didier Godart
+32 498787744
SkypeID Dgozone
didier_godart@rapid7.com About Didier About Rapid7 Join the community!
Tony Wilson About Tony About Indelible data

Managing Director
Indelible Data (a division of
Indelible Designs Limited)
tony@indelible-data.co.uk
"Didier Godart
Risk Product Manager Rapid7 About Didier About Rapid7 Join the community!
+32 498787744
SkypeID Dgozone
"
"Didier Godart
Risk Product Manager Rapid7 About Didier About Rapid7 Join the community!
+32 498787744
SkypeID Dgozone
"Didier Godart
Founder Dgozone
"
(www.dgozone.com)
+32 498787744 About Didier About Rapid7 Join the community!
SkypeID Dgozone
d@dgozone.com
"
" vulnerabilities
umo match.
anning tools - What does that mean?
Quarterly Scans?
AAA Acronym for authentication, authorization, and accounting. Protocol for authenticating a user based on their
verifiable identity, authorizing a user based on their user rights, and accounting for a users consumption of
network resources.
Access Control Mechanisms that limit availability of information or information-processing resources only to authorized persons
or applications.
Account Data Account data consists of cardholder data plus sensitive authentication data. See Cardholder Data and Sensitive
Authentication Data
Account Number See Primary Account Number (PAN).
Acquirer Also referred to as acquiring bank or acquiring financial institution. Entity that initiates and maintains
relationships with merchants for the acceptance of payment cards.
Adware Type of malicious software that, when installed, forces a computer to automatically display or download
AES advertisements.
Abbreviation for Advanced Encryption Standard. Block cipher used in symmetric key cryptography adopted by
NIST in November 2001 as U.S. FIPS PUB 197 (or FIPS 197).
ANSI Acronym for American National Standards Institute. Private, non-profit organization that administers and
coordinates the U.S. voluntary standardization and conformity assessment system.
Anti-Virus Program or software capable of detecting, removing, and protecting against various forms of malicious software
(also called malware) including viruses, worms, Trojans or Trojan horses, spyware, adware, and rootkits.
Application Includes all purchased and custom software programs or groups of programs, including both internal and external
(for example, web) applications.
Audit Log Also referred to as audit trail. Chronological record of system activities. Provides an independently verifiable trail
sufficient to permit reconstruction, review, and examination of sequence of environments and activities
surrounding or leading to operation, procedure, or event in a transaction from inception to final results.
Audit Trail See Audit Log.
ASV Acronym for Approved Scanning Vendor. Company approved by the PCI
SSC to conduct external vulnerability scanning services.
Authentication Process of verifying identity of an individual, device, or process. Authentication typically occurs through the use of
one or more authentication factors such as:

Something you know, such as a password or passphrase
Something you have, such as a token device or smart card
Something you are, such as a biometric
Authentication Credentials Combination of the user ID or account ID plus the authentication factor(s) used to authenticate an individual,
device, or process,
Authorization Granting of access or other rights to a user, program, or process. For a network, authorization defines what an
individual or program can do after successful authentication.
For the purposes of a payment card transaction authorization occurs when a merchant receives transaction
approval after the acquirer validates the transaction with the issuer/processor.
B
Backup Duplicate copy of data made for archiving purposes or for protecting against damage or loss.
Bluetooth Wireless protocol using short-range communications technology to facilitate transmission of data over short
C
distances.
Cardholder Non-consumer or consumer customer to whom a payment card is issued to or any individual authorized to use the
payment card.
Cardholder Data At a minimum, cardholder data consists of the full PAN. Cardholder data may also appear in the form of the full
PAN plus any of the following: cardholder name, expiration date and/or service code
See Sensitive Authentication Data for additional data elements that may be transmitted or processed (but not
stored) as part of a payment transaction.
Cardholder Data The people, processes and technology that store, process or transmit cardholder data or sensitive authentication
Environment data, including any connected system components.
Card Verification Code or Also known as Card Validation Code or Value, or Card Security Code.
Value Refers to either: (1) magnetic-stripe data, or (2) printed security features.
(1) Data element on a card's magnetic stripe that uses secure cryptographic process to protect data integrity on
the stripe, and reveals any alteration or counterfeiting. Referred to as CAV, CVC, CVV, or CSC depending on
payment card brand. The following list provides the terms for each card brand:
CAV Card Authentication Value (JCB payment cards)
CVC Card Validation Code (MasterCard payment cards)
CVV Card Verification Value (Visa and Discover payment cards)
CSC Card Security Code (American Express)
(2) For Discover, JCB, MasterCard, and Visa payment cards, the second type of card verification value or code is the
rightmost three-digit value printed in the signature panel area on the back of the card. For American Express
payment cards, the code is a four-digit unembossed number printed above the PAN on the face of the payment
cards. The code is uniquely associated with each individual piece of plastic and ties the PAN to the plastic. The
following list provides the terms for each card brand:
CID Card Identification Number (American Express and Discover payment cards)
CAV2 Card Authentication Value 2 (JCB payment cards)
CVC2 Card Validation Code 2 (MasterCard payment cards)
CVV2 Card Verification Value 2 (Visa payment cards)
CERT Acronym for Carnegie Mellon University's Computer Emergency Response Team. The CERT Program develops
and promotes the use of appropriate technology and systems management practices to resist attacks on
networked systems, to limit damage, and to ensure continuity of critical services.
CIS Acronym for Center for Internet Security. Non-profit enterprise with mission to help organizations reduce the
risk of business and e-commerce disruptions resulting from inadequate technical security controls.
Column-Level Database Technique or technology (either software or hardware) for encrypting contents of a specific column in a database
Encryption versus the full contents of the entire database. Alternatively, see Disk Encryption or File-Level Encryption.
Compensating Controls Compensating controls may be considered when an entity cannot meet a requirement explicitly as stated, due to
legitimate technical or documented business constraints, but has sufficiently mitigated the risk associated with the
requirement through implementation of other controls. Compensating controls must:
(1) Meet the intent and rigor of the original PCI DSS requirement;
(2) Provide a similar level of defense as the original PCI DSS requirement;
(3) Be above and beyond other PCI DSS requirements (not simply in compliance with other PCI DSS
requirements); and
(4) Be commensurate with the additional risk imposed by not adhering to the PCI DSS requirement.
See Compensating Controls Appendices B and C in PCI DSS Requirements and Security Assessment Procedures
for guidance on the use of compensating controls.
Compromise Also referred to as data compromise, or data breach. Intrusion into a computer system where unauthorized
disclosure/theft, modification, or destruction of cardholder data is suspected.
Console Screen and keyboard which permits access and control of a server, mainframe computer or other system type in a
networked environment.
Consumer Individual purchasing goods, services, or both.
Cryptography Discipline of mathematics and computer science concerned with information security, particularly encryption and
authentication. In applications and network security, it is a tool for access control, information confidentiality, and
integrity.
D
Database Structured format for organizing and maintaining easily retrievable information. Simple database examples are
tables and spreadsheets.
Database Administrator Also referred to as DBA. Individual responsible for managing and administering databases.
Default Accounts Login account predefined in a system, application, or device to permit initial access when system is first put into
service. Additional default accounts may also be generated by the system as part of the installation process.
Default Password Password on system administration, user, or service accounts predefined in a system, application, or device;
usually associated with default account. Default accounts and passwords are published and well known, and
therefore easily guessed.
Degaussing Also called disk degaussing. Process or technique that demagnetizes the disk such that all data stored on the disk
is permanently destroyed.
Disk Encryption Technique or technology (either software or hardware) for encrypting all stored data on a device (for example, a
hard disk or flash drive). Alternatively, File- Level Encryption or Column-Level Database Encryption is used to
encrypt contents of specific files or columns.
DMZ Abbreviation for demilitarized zone. Physical or logical sub-network that provides an additional layer of security
to an organizations internal private network. The DMZ adds an additional layer of network security between the
Internet and an organizations internal network so that external parties only have direct connections to devices in
the DMZ rather than the entire internal network.
DNS Acronym for Domain Name System or domain name server. System that stores information associated with
domain names in a distributed database on networks such as the Internet.
DSS Acronym for Data Security Standard and also referred to as PCI DSS.
Dual Control Process of using two or more separate entities (usually persons) operating in concert to protect sensitive functions
or information. Both entities are equally responsible for the physical protection of materials involved in vulnerable
transactions. No single person is permitted to access or use the materials (for example, the cryptographic key). For
manual key generation, conveyance, loading, storage, and retrieval, dual control requires dividing knowledge of
the key among the entities. (See also Split Knowledge.)
Dynamic Packet FilteringSee Stateful Inspection.
E
ECC Acronym for Elliptic Curve Cryptography. Approach to public-key cryptography based on elliptic curves over finite
fields. See Strong Cryptography.
Egress Filtering Method of filtering outbound network traffic such that only explicitly allowed traffic is permitted to leave the
Encryption network.
Process of converting information into an unintelligible form except to holders of a specific cryptographic key. Use
of encryption protects information between the encryption process and the decryption process (the inverse of
encryption) against unauthorized disclosure. See Strong Cryptography.
Encryption Algorithm A sequence of mathematical instructions used for transforming unencrypted text or data to encrypted text or
data, and back again. See Strong Cryptography.
Entity Term used to represent the corporation, organization or business which is undergoing a PCI DSS review.
F
File Integrity Monitoring Technique or technology under which certain files or logs are monitored to detect if they are modified. When
critical files or logs are modified, alerts should be sent to appropriate security personnel.
File-Level Encryption Technique or technology (either software or hardware) for encrypting the full contents of specific files.
Alternatively, see Disk Encryption or Column-Level Database Encryption.
FIPS Acronym for Federal Information Processing Standards. Standards that are publicly recognized by the U.S.
Federal Government; also for use by non- government agencies and contractors.
Firewall Hardware and/or software technology that protects network resources from unauthorized access. A firewall
permits or denies computer traffic between networks with different security levels based upon a set of rules and
other criteria.
Forensics Also referred to as computer forensics. As it relates to information security, the application of investigative tools
and analysis techniques to gather evidence from computer resources to determine the cause of data
compromises.
FTP Acronym for File Transfer Protocol. Network protocol used to transfer data from one computer to another
through a public network such as the Internet. FTP is widely viewed as an insecure protocol because passwords
and file contents are sent unprotected and in clear text. FTP can be implemented securely via SSH or other
technology.
G
Acronym for General Packet Radio Service. Mobile data service available to users of GSM mobile phones.
Recognized for efficient use of limited bandwidth. Particularly suited for sending and receiving small bursts of
GPRS
data, such as e-mail and web browsing.
GSM Acronym for Global System for Mobile Communications. Popular standard for mobile phones and networks.
Ubiquity of GSM standard makes international roaming very common between mobile phone operators, enabling
subscribers to use their phones in many parts of the world.
H
Hashing Process of rendering cardholder data unreadable by converting data into a fixed-length message digest via Strong
Cryptography. Hashing is a (mathematical) function in which a non-secret algorithm takes any arbitrary length
message as input and produces a fixed length output (usually called a hash code or message digest). A hash
function should have the following properties:
(1) It is computationally infeasible to determine the original input given only the hash code,
(2) It is computationally infeasible to find two inputs that give the same hash code.
In the context of PCI DSS, hashing must be applied to the entire PAN for the hash code to be considered rendered
unreadable. It is recommended that hashed cardholder data includes a salt value as input to the hashing function
(see Salt).
Host Main computer hardware on which computer software is resident.

Hosting Provider Offers various services to merchants and other service providers. Services range from simple to complex; from
shared space on a server to a whole range of shopping cart options; from payment applications to connections
to payment gateways and processors; and for hosting dedicated to just one customer per server. A hosting
provider may be a shared hosting provider, who hosts multiple entities on a single server.
HTTP Acronym for hypertext transfer protocol. Open internet protocol to transfer or convey information on the World
Wide Web.
HTTPS Acronym for hypertext transfer protocol over secure socket layer. Secure HTTP that provides authentication and
encrypted communication on the World Wide Web designed for security-sensitive communication such as web-
based logins.
Hypervisor Software or firmware responsible for hosting and managing virtual machines. For the purposes of PCI DSS, the
hypervisor system component also includes the virtual machine monitor (VMM).
I
ID Identifier for a particular user or application.
IDS Acronym for intrusion detection system. Software or hardware used to identify and alert on network or system
intrusion attempts. Composed of sensors that generate security events; a console to monitor events and alerts
and control the sensors; and a central engine that records events logged by the sensors in a database. Uses system
of rules to generate alerts in response to security events detected.
IETF Acronym for Internet Engineering Task Force. Large, open international community of network designers,
operators, vendors, and researchers concerned with evolution of Internet architecture and smooth operation of
Internet. The IETF has no formal membership and is open to any interested individual.
Index Token A cryptographic token that replaces the PAN, based on a given index for an unpredictable value.
Information Security Protection of information to insure confidentiality, integrity, and availability.
Information System Discrete set of structured data resources organized for collection, processing, maintenance, use, sharing,
dissemination, or disposition of information.
Ingress Filtering Method of filtering inbound network traffic such that only explicitly allowed traffic is permitted to enter the
Insecure network.
A protocol, service, or port that introduces security concerns due to the lack of controls over confidentiality
Protocol/Service/Port and/or integrity. These security concerns include services, protocols, or ports that transmit data and
authentication credentials (e.g., password/passphrase in clear-text over the Internet), or that easily allow for
exploitation by default or if misconfigured. Examples of insecure services, protocols, or ports include but are not
limited to FTP, Telnet, POP3, IMAP, and SNMP.
IP Acronym for internet protocol. Network-layer protocol containing address information and some control
information that enables packets to be routed. IP is the primary network-layer protocol in the Internet protocol
suite.
IP Address Also referred to as internet protocol address. Numeric code that uniquely identifies a particular computer on the
Internet.
IP Address Spoofing Attack technique used by a malicious individual to gain unauthorized access to computers. The malicious
individual sends deceptive messages to a computer with an IP address indicating that the message is coming from
a trusted host.
IPS Acronym for intrusion prevention system. Beyond an IDS, an IPS takes the additional step of blocking the
attempted intrusion.
IPSEC Abbreviation for Internet Protocol Security. Standard for securing IP communications by encrypting and/or
authenticating all IP packets. IPSEC provides security at the network layer.
ISO Better known as International Organization for Standardization. Non- governmental organization consisting of a
network of the national standards institutes of over 150 countries, with one member per country and a central
secretariat in Geneva, Switzerland, that coordinates the system.
Issuer Entity that issues payment cards or performs, facilitates, or supports issuing services including but not limited to
issuing banks and issuing processors. Also referred to as issuing bank or issuing financial institution.
Issuing services Examples of issuing services may include but are not limited to authorization and card personalization.
K
Key In cryptography, a key is a value that determines the output of an encryption algorithm when transforming plain
text to ciphertext. The length of the key generally determines how difficult it will be to decrypt the ciphertext in a
given message. See Strong Cryptography.
Key Management In cryptography, it is the set of processes and mechanisms which support key establishment and maintenance,
including replacing older keys with new keys as necessary.
L
Acronym for local area network. A group of computers and/or other devices that share a common
LAN communications line, often in a building or group of buildings.
LDAP Acronym for Lightweight Directory Access Protocol. Authentication and authorization data repository utilized for
querying and modifying user permissions and granting access to protected resources.
Log See Audit Log.
LPAR Abbreviation for logical partition. A system of subdividing, or partitioning, a computer's total resources
processors, memory and storageinto smaller units that can run with their own, distinct copy of the operating
system and applications. Logical partitioning is typically used to allow the use of different operating systems and
applications on a single device. The partitions may or may not be configured to communicate with each other or
share some resources of the server, such as network interfaces.
M
MAC Acronym for message authentication code. In cryptography, it is a small piece of information used to
authenticate a message. See Strong Cryptography.
MAC Address Abbreviation for media access control address. Unique identifying value assigned by manufacturers to network
adapters and network interface cards.
Magnetic-Stripe Data Also referred to as track data. Data encoded in the magnetic stripe or chip used for authentication and/or
authorization during payment transactions. Can be the magnetic stripe image on a chip or the data on the track 1
and/or track 2 portion of the magnetic stripe.
Mainframe Computers that are designed to handle very large volumes of data input and output and emphasize throughput
computing. Mainframes are capable of running multiple operating systems, making it appear like it is operating as
multiple computers. Many legacy systems have a mainframe design.
Malicious Software / Software designed to infiltrate or damage a computer system without the owner's knowledge or consent. Such
Malware software typically enters a network during many business-approved activities, which results in the exploitation of
system vulnerabilities. Examples include viruses, worms, Trojans (or Trojan horses), spyware, adware, and rootkits.
Masking In the context of PCI DSS, it is a method of concealing a segment of data when displayed or printed. Masking is
used when there is no business requirement to view the entire PAN. Masking relates to protection of PAN when
displayed or printed. See Truncation for protection of PAN when stored in files, databases, etc.
Merchant For the purposes of the PCI DSS, a merchant is defined as any entity that accepts payment cards bearing the logos
of any of the five members of PCI SSC (American Express, Discover, JCB, MasterCard or Visa) as payment for goods
and/or services. Note that a merchant that accepts payment cards as payment for goods and/or services can also
be a service provider, if the services sold result in storing, processing, or transmitting cardholder data on behalf of
other merchants or service providers. For example, an ISP is a merchant that accepts payment cards for monthly
billing, but also is a service provider if it hosts merchants as customers.
Monitoring Use of systems or processes that constantly oversee computer or network resources for the purpose of alerting
personnel in case of outages, alarms, or other predefined events.
MPLS Acronym for multi protocol label switching. Network or telecommunications mechanism designed for
connecting a group of packet-switched networks.
N
NAT Acronym for network address translation. Known as network masquerading or IP masquerading. Change of an IP
address used within one network to a different IP address known within another network.
Network Two or more computers connected together via physical or wireless means.
Network Administrator Personnel responsible for managing the network within an entity. Responsibilities typically include but are not
limited to network security, installations, upgrades, maintenance and activity monitoring.
Network Components Include, but are not limited to firewalls, switches, routers, wireless access points, network appliances, and other
security appliances.
Network Security Scan Process by which an entitys systems are remotely checked for vulnerabilities through use of manual or automated
tools. Security scans that include probing internal and external systems and reporting on services exposed to the
network. Scans may identify vulnerabilities in operating systems, services, and devices that could be used by
malicious individuals.
Network Segmentation Network segmentation isolates system components that store, process, or transmit cardholder data from systems
that do not. Adequate network segmentation may reduce the scope of the cardholder data environment and thus
reduce the scope of the PCI DSS assessment. See the Network Segmentation section in the PCI DSS Requirements
and Security Assessment Procedures for guidance on using network segmentation. Network segmentation is not a
PCI DSS requirement. See System Components.
NIST Acronym for National Institute of Standards and Technology. Non-regulatory federal agency within U.S.
Commerce Department's Technology Administration. Their mission is to promote U.S. innovation and industrial
competitiveness by advancing measurement science, standards, and technology to enhance economic security
and improve quality of life.
NMAP Security-scanning software that maps networks and identifies open ports in network resources.
Non-Consumer Users Individuals, excluding cardholders, who access system components, including but not limited to employees,
administrators, and third parties.
NTP Acronym for Network Time Protocol. Protocol for synchronizing the clocks of computer systems, network
devices and other system components.
O
Off-the-Shelf Description of products that are stock items not specifically customized or designed for a specific customer or user
and are readily available for use.
Operating System / OS Software of a computer system that is responsible for the management and coordination of all activities and the
sharing of computer resources. Examples of operating systems include Microsoft Windows, Mac OS, Linux and
Unix.
OWASP Acronym for Open Web Application Security Project. A non-profit organization focused on improving the security
of application software. OWASP maintains a list of critical vulnerabilities for web applications. (See
http://www.owasp.org).
P
PA-QSA Acronym for Payment Application Qualified Security Assessor, company approved by the PCI SSC to conduct
assessments on payment applications against the PA-DSS.
PAN Acronym for primary account number and also referred to as account number. Unique payment card number
(typically for credit or debit cards) that identifies the issuer and the particular cardholder account.
Password / Passphrase A string of characters that serve as an authenticator of the user.
Pad In cryptography, the one-time pad is an encryption algorithm with text combined with a random key or "pad" that
is as long as the plain-text and used only once. Additionally, if key is truly random, never reused, and, kept secret,
the one-time pad is unbreakable
Parameterized Queries A means of structuring SQL queries to limit escaping and thus prevent injection attacks.
PAT Acronym for port address translation and also referred to as network address port translation. Type of NAT
that also translates the port numbers.
Patch Update to existing software to add functionality or to correct a defect.
Payment Application Any application that stores, processes, or transmits cardholder data as part of authorization or settlement
Payment Cards For purposes of PCI DSS, any payment card/device that bears the logo of the founding members of PCI SSC, which
are American Express, Discover Financial Services, JCB International, MasterCard Worldwide, or Visa, Inc.
PCI Acronym for Payment Card Industry.
Acronym for personal data assistant or personal digital assistant. Handheld mobile devices with capabilities
PDA such as mobile phones, e-mail, or web browser.
PED PIN entry device
Penetration Test Penetration tests attempt to exploit vulnerabilities to determine whether unauthorized access or
other malicious activity is possible. Penetration testing includes network and application testing as
well as controls and processes around the networks and applications, and occurs from both outside
the network trying to come in (external testing) and from inside the network.
Personnel Full-time and part-time employees, temporary employees, contractors, and consultants who are resident on the
entitys site or otherwise have access to the cardholder data environment.
Personally Identifiable Information that can be utilized to identify an individual including but not limited to name, address, social security
Information number, phone number, etc.
PIN Acronym for personal identification number. Secret numeric password known only to the user and a system to
authenticate the user to the system. The user is only granted access if the PIN the user provided matches the PIN
in the system. Typical PINs are used for automated teller machines for cash advance transactions. Another type of
PIN is one used in EMV chip cards where the PIN replaces the cardholders signature.
PIN Block A block of data used to encapsulate a PIN during processing. The PIN block format defines the
content of the PIN block and how it is processed to retrieve the PIN. The PIN block is composed of the
PIN, the PIN length, and may contain subset of the PAN.
POI Acronym for Point of Interaction, the initial point where data is read from a card. An electronic
transaction-acceptance product, a POI consists of hardware and software and is hosted in acceptance
equipment to enable a cardholder to perform a card transaction. The POI may be attended or
unattended. POI transactions are typically integrated circuit (chip) and/or magnetic-stripe card-based
Policy Organization-wide rules governing acceptable use of computing resources, security practices, and guiding
development of operational procedures
POS Acronym for point of sale. Hardware and/or software used to process payment card transactions at merchant
Private Network locations.
Network established by an organization that uses private IP address space. Private networks are commonly
designed as local area networks. Private network access from public networks should be properly protected with
the use of firewalls and routers.
Procedure Descriptive narrative for a policy. Procedure is the how to for a policy and describes how the policy is to be
implemented.
Protocol Agreed-upon method of communication used within networks. Specification describing rules and procedures that
computer products should follow to perform activities on a network.
PTS Acronym for PIN Transaction Security, PTS is a set of modular evaluation requirements managed by PCI Security
Standards Council, for PIN acceptance POI terminals. Please refer to www.pcisecuritystandards.org.
Public Network Network established and operated by a telecommunications provider, for specific purpose of providing data
transmission services for the public. Data over public networks can be intercepted, modified, and/or diverted
while in transit. Examples of public networks in scope of the PCI DSS include, but are not limited to, the Internet,
wireless, and mobile technologies.
PVV Acronym for PIN verification value. Discretionary value encoded in magnetic stripe of payment card.
Q
QSA Acronym for Qualified Security Assessor, company approved by the PCI SSC to conduct PCI DSS on-site
R
assessments.
RADIUS Abbreviation for Remote Authentication Dial-In User Service. Authentication and accounting system. Checks if
information such as username and password that is passed to the RADIUS server is correct, and then authorizes
access to the system. This authentication method may be used with a token, smart card, etc., to provide two-
factor authentication.
Acronym for role-based access control. Control used to restrict access by specific authorized users based on
RBAC their job responsibilities.
Remote Access Access to computer networks from a remote location, typically originating from outside the network. An example
of technology for remote access is VPN.
Removable Electronic Media Media that store digitized data and which can be easily removed and/or transported from one computer system to
another. Examples of removable electronic media include CD-ROM, DVD-ROM, USB flash drives and removable
hard drives.
ROC Report on Compliance - Report containing details documenting an entitys compliance status with the PCI DSS.
Report on Validation Also referred to as ROV. Report containing details documenting a payment applications compliance with the PCI
Re-keying PA-DSS.
Process of changing cryptographic keys. Periodic re-keying limits the amount of data encrypted by a single key.
Remote Lab Environment A lab that is not maintained by the PA-QSA.
Reseller / Integrator An entity that sells and/or integrates payment applications but does not develop them.
RFC 1918 The standard identified by the Internet Engineering Task Force (IETF) that defines the usage and appropriate
address ranges for private (non-internet routable) networks.
Risk Analysis / Risk Process that identifies valuable system resources and threats; quantifies loss exposures (that is, loss potential)
Assessment based on estimated frequencies and costs of occurrence; and (optionally) recommends how to allocate resources
to countermeasures so as to minimize total exposure.
Rootkit Type of malicious software that when installed without authorization, is able to conceal its presence and gain
administrative control of a computer system.
Router Hardware or software that connects two or more networks. Functions as sorter and interpreter by looking at
addresses and passing bits of information to proper destinations. Software routers are sometimes referred to as
gateways.
RSA Algorithm for public-key encryption described in 1977 by Ron Rivest, Adi Shamir, and Len Adleman at
Massachusetts Institute of Technology (MIT); letters RSA are the initials of their surnames.
S
Salt Random string that is concatenated with other data prior to being operated on by a hash function. See also Hash.
Sampling The process of selecting a cross-section of a group that is representative of the entire group. Sampling may be
used by assessors to reduce overall testing efforts, when it is validated that an entity has standard, centralized PCI
DSS security and operational processes and controls in place. Sampling is not a PCI DSS requirement.
SANS Acronym for SysAdmin, Audit, Networking and Security, an institute that provides computer security training
and professional certification. (See www.sans.or
Scoping Process of identifying all system components, people, and processes to be included in a PCI DSS assessment. The
first step of a PCI DSS assessment is to accurately determine the scope of the review.
SDLC Acronym for system development life cycle. Phases of the development of a software or computer system that
includes planning, analysis, design, testing, and implementation.
Secure Coding The process of creating and implementing applications that are resistant to tampering and/or compromise.
Secure Wipe Also called secure delete, a program utility used to delete specific files permanently from a computer system.
Security Officer Also called secure delete, a program utility used to delete specific files permanently from a computer system.
Security Policy Set of laws, rules, and practices that regulate how an organization manages, protects, and distributes sensitive
Security Protocols information
Network communications protocols designed to secure the transmission of data. Examples of security protocols
include, but are not limited to SSL/TLS, IPSEC, SSH, etc.
SAQ Acronym for Self-Assessment Questionnaire. Tool used by any entity to validate its own compliance with the PCI
Sensitive Area DSS.
Any data center, server room or any area that houses systems that stores, processes, or transmits cardholder data.
This excludes the areas where only point-of-sale terminals are present such as the cashier areas in a retail store.
Sensitive Authentication Data Security-related information (including but not limited to card validation codes/values, full magnetic-stripe data,
PINs, and PIN blocks) used to authenticate cardholders and/or authorize payment card transactions.
Separation of Duties Practice of dividing steps in a function among different individuals, so as to keep a single individual from being
able to subvert the process.
Server Computer that provides a service to other computers, such as processing communications, file storage, or
accessing a printing facility. Servers include, but are not limited to web, database, application, authentication,
DNS, mail, proxy, and NTP.
Service Code Three-digit or four-digit value in the magnetic-stripe that follows the expiration date of the payment card on the
track data. It is used for various things such as defining service attributes, differentiating between international
and national interchange, or identifying usage restrictions.
Service Provider Business entity that is not a payment brand, directly involved in the processing, storage, or transmission of
cardholder data. This also includes companies that provide services that control or could impact the security of
cardholder data. Examples include managed service providers that provide managed firewalls, IDS and other
services as well as hosting providers and other entities. Entities such as telecommunications companies that only
provide communication links without access to the application layer of the communication link are excluded.
SHA-1/SHA-2 Acronym for Secure Hash Algorithm. A family or set of related cryptographic hash functions including SHA-1 and
SHA-2. See Strong Cryptography.
Smart Card Also referred to as chip card or IC card (integrated circuit card). A type of payment card that has integrated
circuits embedded within. The circuits, also referred to as the chip, contain payment card data including but not
limited to data equivalent to the magnetic-stripe data.
SNMP Acronym for Simple Network Management Protocol. Supports monitoring of network attached devices for any
conditions that warrant administrative attention.
Spyware Type of malicious software that when installed, intercepts or takes partial control of the users computer without
the users consent.
Acronym for Structured Query Language. Computer language used to create, modify, and retrieve data from
SQL relational database management systems.
SQL Injection Form of attack on database-driven web site. A malicious individual executes unauthorized SQL commands by
taking advantage of insecure code on a system connected to the Internet. SQL injection attacks are used to steal
information from a database from which the data would normally not be available and/or to gain access to an
organizations host computers through the computer that is hosting the database.
SSH Abbreviation for Secure Shell. Protocol suite providing encryption for network services like remote login or
remote file transfer.
SSL Acronym for Secure Sockets Layer. Established industry standard that encrypts the channel between a web
browser and web server to ensure the privacy and reliability of data transmitted over this channel.
Stateful Inspection Also called dynamic packet filtering, it is a firewall capability that provides enhanced security by keeping track of
communications packets. Only incoming packets with a proper response (established connections) are allowed
through the firewall.
Strong Cryptography Cryptography based on industry-tested and accepted algorithms, along with strong key lengths and proper key-
management practices. Cryptography is a method to protect data and includes both encryption (which is
reversible) and hashing (which is not reversible, or one way). Examples of industry-tested and accepted
standards and algorithms for encryption include AES (128 bits and higher), TDES (minimum double-length keys),
RSA (1024 bits and higher), ECC (160 bits and higher), and ElGamal (1024 bits and higher).
See NIST Special Publication 800-57 (http://csrc.nist.gov/publications/) for more information.
SysAdmin Abbreviation for system administrator. Individual with elevated privileges who is responsible for managing a
computer system or network.
System Components Any network component, server, or application included in or connected to the cardholder data environment.
System-level object Anything on a system component that is required for its operation, including but not limited to application
executable and configuration files, system configuration files, static and shared libraries & DLL's, system
executables, device drivers and device configuration files, and added third-party components.
T
TACACS Acronym for Terminal Access Controller Access Control System. Remote authentication protocol commonly used
in networks that communicates between a remote access server and an authentication server to determine user
access rights to the network. This authentication method may be used with a token, smart card, etc., to provide
two-factor authentication.
TCP Acronym for Transmission Control Protocol. Basic communication language or protocol of the Internet.
TDES Acronym for Triple Data Encryption Standard and also known as 3DES or Triple DES. Block cipher formed
from the DES cipher by using it three times. See Strong Cryptography.
TELNET Abbreviation for telephone network protocol. Typically used to provide user- oriented command line login
sessions to devices on a network. User credentials are transmitted in clear text.
Threat Condition or activity that has the potential to cause information or information processing resources to be
intentionally or accidentally lost, modified, exposed, made inaccessible, or otherwise affected to the detriment of
the organization
TLS Acronym for Transport Layer Security. Designed with goal of providing data secrecy and data integrity between
two communicating applications. TLS is successor of SSL.
Token A value provided by hardware or software that usually works with an authentication server or VPN to perform
dynamic or two-factor authentication. See RADIUS, TACACS, and VPN.
Transaction Data Data related to electronic payment card transaction.
Trojan Also referred to as Trojan horse. A type of malicious software that when installed, allows a user to perform a
normal function while the Trojan performs malicious functions to the computer system without the users
knowledge.
Truncation Method of rendering the full PAN unreadable by permanently removing a segment of PAN data. Truncation relates
to protection of PAN when stored in files, databases, etc. See Masking for protection of PAN when displayed on
screens, paper receipts, etc.
Trusted Network Network of an organization that is within the organizations ability to control or manage.
Two-Factor Authentication Method of authenticating a user whereby two or more factors are verified. These factors include something the
user has (such as hardware or software token), something the user knows (such as a password, passphrase, or
PIN) or something the user is or does (such as fingerprints or other forms of biometrics).
U
Untrusted Network Network that is external to the networks belonging to an organization and which is out of the organizations ability
to control or manage.
V
Virtualization Virtualization refers to the logical abstraction of computing resources from physical constraints. One common
abstraction is referred to as virtual machines or VMs, which takes the content of a physical machine and allows it
to operate on different physical hardware and/or along with other virtual machines on the same physical
hardware. In addition to VMs, virtualization can be performed on many other computing resources, including
applications, desktops, networks, and storage.
Virtual Machine Monitor The VMM is included with the hypervisor and is software that implements virtual machine hardware abstraction.
(VMM) It manages the system's processor, memory, and other resources to allocate what each guest operating system
requires.
Virtual Machine A self-contained operating environment that behaves like a separate computer. It is also known as the Guest,
and runs on top of a hypervisor.
Virtual Appliance (VA) A VA takes the concept of a pre-configured device for performing a specific set of functions and run this device as
a workload. Often, an existing network device is virtualized to run as a virtual appliance, such as a router, switch,
or firewall.
Virtual Switch or Router A virtual switch or router is a logical entity that presents network infrastructure level data routing and switching
functionality. A virtual switch is an integral part of a virtualized server platform such as a hypervisor driver,
module, or plug-in.
Virtual Terminal A virtual terminal is web-browser-based access to an acquirer, processor or third party service provider website to
authorize payment card transactions, where the merchant manually enters payment card data via a securely
connected web browser. Unlike physical terminals, virtual terminals do not read data directly from a payment
card. Because payment card transactions are entered manually, virtual terminals are typically used instead of
physical terminals in merchant environments with low transaction volumes.
VLAN Abbreviation for virtual LAN or virtual local area network. Logical local area network that extends beyond a
single traditional physical local area network.
VPN Acronym for virtual private network. A computer network in which some of connections are virtual circuits
within some larger network, such as the Internet, instead of direct connections by physical wires. The end points
of the virtual network are said to be tunneled through the larger network when this is the case. While a common
application consists of secure communications through the public Internet, a VPN may or may not have strong
security features such as authentication or content encryption.
A VPN may be used with a token, smart card, etc., to provide two-factor authentication.
Vulnerability Flaw or weakness which, if exploited, may result in an intentional or unintentional compromise of a system.
W
Acronym for wide area network. Computer network covering a large area, often a regional or company wide
WAN computer system.
Web Application An application that is generally accessed via a web browser or through web services. Web applications may be
available via the Internet or a private, internal network.
Web Server Computer that contains a program that accepts HTTP requests from web clients and serves the HTTP responses
(usually web pages).
WEP Acronym for Wired Equivalent Privacy. Weak algorithm used to encrypt wireless networks. Several serious
weaknesses have been identified by industry experts such that a WEP connection can be cracked with readily
available software within minutes. See WPA.
Wireless Access Point Network that connects computers without a physical connection to wires.
WLAN Acronym for wireless local area network. Local area network that links two or more computers or devices
WPA/WPA2 without
Acronymwires.
for WiFi Protected Access. Security protocol created to secure wireless networks. WPA is the successor
to WEP.. WPA2 was also released as the next generation of WPA.
Scope Definition

Scope: Area of computer system network that possesses cardholder data or sensitive authentication data and those
systems and segments that directly attach or support cardholder processing"
Define your Card Data Environment (CDE)
Perimeter
IP address/URL Name Type Purpose Owner
Internal
IP address/URL Name Type Purpose Owner
Scope Definition
System Admin Criticality Patch level Last Scan date Scan report location
System Admin Criticality Patch level last Scan date Last scan report
ORGANIZATION TYPE HERE YOUR COMPANY NAME
NAME:
(See the merchant types)
Merchant Type: D You MUST select in cell B3 your Merchant type (A, B, C, C-V
#
# of
PCI-DSS REQUIREMENTS % compliance # in Place # not in Place Compensating Severity
Requirements Controls
1 75% 28 21 7 0 24
2 0% 26 0 26 0 67
3 5% 37 2 35 0 135
4 22% 9 2 7 0 14
5 0% 7 0 7 0 14
6 0% 36 0 36 0 129
7 0% 9 0 9 0 36
8 0% 33 0 33 0 111
9 0% 29 0 29 0 111
10 0% 33 0 33 0 132
11 0% 25 0 25 0 64
12 0% 44 0 44 0 216
Click on above
requirements to
access the
associated
sheet.
Documentation
Return to table of content
Make the list of all your documentation related to your PCI project.
Techical documentation
Ref Title/Topic Description PCI DSS Req Version Owner
Global network diagram Global network diagram (Confidential) 1.1
Ref1
Ref2 Includes development/test and production 6.4
Lightened network diagram environments
Non-confidential for external communication with third Optional
Ref3 party. No internal IP's.
PCI Scope definition Document describing the PCI scope, network diagram, 1.1 + Scope
components, function, flow, card data storage,
Ref4 processing, transmission
Firewall/router rule sets For each Firewall/router in scope:
Firewall F1 and F2 + Router
Includes a list of secure and unsecure services, 1.1.5
protocols and ports together with business justification
for each FW and routers.
Includes a list of restricted connections between 1.2
untrusted networks and system components in the
cardholder data environment
Includes a description of inbound and outbound traffic 1.2.1
Includes a rule stating that Internal addresses cannot 1.3.4
pass from the Internet into the DMZ.
Includes a requirement for stateful inspection 1.3.6
Includes segregation of CDE (Ensure that system 1.3.7
components that store cardholder data are on an
Ref5 internal network zone, segregated from the DMZ)
System Configuration/hardening For each system components in scope:
for all components in scope Includes a list of services, protocols and daemons 2.2
enabled + business justification.
DocumentationSystem Configuration/hardening
for all components in scope
Includes a list of common security parameter settings 2.2.3

for the system components
Includes a list of unnecessary functionalities (for 2.2.4
example, scripts, drivers, features, subsystems, file
systems, etc.) removed/disabled
Includes Removal of Telnet and other remote login 2.3
commands
Includes the list of anti-virus/anti-malware software 5.1
and description of associated processes
Includes a description of access control configuration 7.2
Includes a description of user authentication method 8.2
Includes a description of method ensuring the interity 11.5
of critical files
Ref6 Includes the list of files considered as critical 11.5
Encryption / Transmission Lists the security protocols used in scope wherever 4.1
cardholder data is transmitted or received over open,
Ref7 public networks.
Patch inventory Inventory/historic of applied patched for each 6.1
Ref8 components
IDS/IPS config Lists active and static protection systems (IDS/IPS) used 11.4
within the scope and their associated configuration
Ref9 and processes.
Policies, Procedures and standards documentation

Ref Title Description PCI DSS Req Version Owner
Role and responsibilities for Description of Groups, Roles and Responsibilities for 1.1.4
network and security Logical Management of Network Components.
management
Description of Groups, Roles and Responsibilities for
security management including key management.
Documentation
Firewall/router configuration and Formal process for testing and approval of all network 1.1
change management process connections and changes to firewall and router
configurations
Includes a statement enforcing review of firewall and 1.1.6
router rule sets at least every six months.
Includes limitation of inbound and outbound traffic to 1.2
that which is necessary for the cardholder data
environment
Includes a statement preventing any disclosure of 1.3.8
private IP addresses and routing information to
external parties and exceptions
Includes enabling and activation of audit trails. 10.1
Configuration Standards System configuration and hardening procedures for 2.2
(Windows, SQL,) each type of system component in scope.
Includes policy and procedures for changing of Vendor 2.1

Default Settings
Includes a statement enforcing one primary function 2.2.1
per system
Includes a statement enforcing that only necessary 2.2.2
services or protocols are enabled. + Justifiation
Includes a list of common security parameter settings 2.2.3
for the system components
Includes a statement enforcing removal of all 2.2.4
unnecessary functionality (for example, scripts, drivers,
features, subsystems, file systems, etc.)
Includes a statement enforcing encryption of non- 2.3
console admin access.
Includes a statement ensuring removal/deactivation of 2.3
Telnet and other remote login commands for use
internally
Includes a statement enforcing audit trails activation 10.1
Protection of Laptop/Desktop in Description of technical measures, configuration and 1.4
scope associated processes protecting laptop and desktop.
Such as personal firewall and anti-virus.
Documentation
Data retention and disposal policy Formal data retention policy identifying what data 3.1/3.2.1/3.2.
and process needs to be retained, and where that data resides so it 2/3.2.3
can be securely destroyed or deleted as soon as it is no
longer needed.
Includes types of data retained (No sensitive data)

Includes a statement preventing presence of card data
in
- All logs (for example, transaction, history, debugging,
error)
- History files
- Trace files
- Database contents
Includes a statement preventing storage of CVV and

PIN
Includes procedure for Obtaining and protecting
cardholder data
Includes procedure for Accessing, Modifying or
Transferring cardholder data
Includes procedures for disposing of and destroying
data.
Includes business justification for retention of
cardholder data
Data display protection Primary Account Number (PAN) Policy and Procedures 3.3
for Displaying the PAN Digits
Includes a statement enforcing masking of PAN when

displayed (the first six and last four digits are the
maximum number of digits to be displayed)
Includes a list of users/roles having legitimate business
reason to access data.
Key protection and management Policy and procedures associated to the generation and 3.5/3.6
protection of keys used for encryption of cardholder
data (PGP, )
Includes the selection process of key custodians 3.6.8

Documentation
Tokenization Process Description of the processes and mechanisms used to Optional

generate and protect the token, associated
components and data
Anti-virus Information about anti-virus technology in used and 5.1
how it is updated/managed.
Security Patch Management Procedures for the identification, risk ranking, testing, 6.1
distribution, deployment and implementation of
security Patches
Includes a statement enforcing installation of all critical
new security patches within one month.
Describe the processes used to identify new security 6.2
vulnerabilities, and that a risk ranking is assigned to
such vulnerabilities
Includes a list of online Resources for Patch
Management, Alerts, Security and Support, As
Applicable .
Software Development processes Description of the software development processes in 6.3
used
Lists of industry standards and/or best practices.
Includes a statement enforcing to take Security into
account throughout the life cycle.
Includes a statement enforcing review of Custom

application code changes prior to release to production
or customers in order to identify any potential coding
vulnerability.
Includes a statement enforcing separation of 6.4

development/test and production environments
Includes a statement enforcing separation of duties 6.4.2

between development/test and production
environments
Documentation
Secure coding/Testing Software Development Secure Coding Guidelines and 6.5-6.5.9

Training Policy and Procedures
Includes a statement enforcing training of developers 6.5
in secure coding technique
Includes a description of the testing process used to 6.6
ensure apps are not vulnerable to coding mistake (SQL
Inj,)
Test procedures Policy and procedures associated to the test of
applications
Includes a statement preventing usage of Live PAN in 6.4.3
test environment
Includes a statement enforcing removal of Test data 6.4.4
and accounts before production
Change control procedures for Procedures for the implementation of security patches 6.4.5
implementation of security and software modification
patches and software
modifications
Includes statements enforcing: 6.4.5
i. Documentation of impact
ii. Documented approval by authorized parties
iii. Testing of functionality to ensure the change does
not adversely impact the security of the system
iv. Testing of all custom code updates for compliance
with PCI DSS Requirement 6.5 (to address the
vulnerabilities identified in 6.5.1 6.5.9)
v. Back-out procedures
Includes a statement enforcing execution of internal 11.2.3

and external scans after any significant change.
Data control/ Data Control & Access Control Policies and Procedures.
Access Control/
Includes a statement restricting access rights for 7.1.1

privileged user IDs to least privileges necessary to
perform job responsibilities.
Access Control/
Documentation
Includes a statement enforcing assignment of privileges 7.1.2

are based on job classification and function
Includes a statement enforcing documented approval 7.1.3
by authorized parties (in writing or electronically) for
all access, and that it must specify required privileges
Includes a statement requiring implemntation of access 7.1.4
controls via an automated access control system.
Includes a statement enforcing that access control 7.2.1
systems are in place on all system components.
Includes a statement requiring configuration of access 7.2.2
control systems to enforce privileges assigned to
individuals based on job classification and function
Includes a statement enforcing that access control 7.2.3
systems have a default deny-all setting.
Includes a statement enforcing assignment of a unique 8.1

userId to users before being allowed to access system
components or cardholder data
Describes authentication method in used 8.2
Includes a statement enforcing usage of two-factor 8.3
authenticationfor all remote network access.
Proper Authentication & Password Policy and procedures associated to access 8.5
Management management and password management (Request,
authorization,
creation/modification/deletion/revokation change
control process)
Includes Password initialization/reset process 8.5.2
Includes a statement enforcing removal or disabling of 8.5.5

inactive user accounts over 90 days old
Includes management of Vendor remote access (for 8.5.6

maintenance)
Documentation
Includes a statement preventing Generic /Share and 8.5.8

exception management
Includes a statement prohibiting group and shared 8.5.8
passwords or other authentication methods
Includes a statement enforcing change of user 8.5.9
passwords at least every 90 days
Includes a statement enforcing a minimum password 8.5.10

length of at least seven characters.
Includes a statement enforcing that passwords contain 8.5.11
both numeric and alphabetic characters.
Includes a statement prohibiting submition of a new 8.5.11
password identical to the last four passwords.
Includes a statement enforcing UserId lock out after 8.5.12
not more than six attempts.
Includes a statement enforcing a lockout duration of 30 8.5.13
min minimum or until administrator enables the user
ID
Includes a statement requiring user re-authentication 8.5.14
whenever a session has been idle for more than 15
minutes
Job Classification Lists the Roles, privileges, access requirements, 7.1, 7.2, 12.4
security responsibilities
Security classification Lists the classification levels related to the
confidentiality of the data
User access inventory Lists who have access to what
Physical access protection Policy and procedures associated to the Protection of 9.1
physical areas, Visitor handling, Visitor Checklist 9.2/9.3/9.4
9.5/9.6
Media Distribution, Classification Policy and procedures for Media distribution and 9.7/9.8
and destruction classification
Documentation
Media Distribution, Classification
and destruction
Includes policy and procedures Storage, maintenance 9.9/9.10
and description of Hardcopy and Electronic Media
Policy and Procedures
Monitoring/logging Policy and procedures associated to
monitoring/logging
Includes a statement enforcing that audit trails are 10.1
enablement and activation for system components.
Includes a statement enforcing logging of access to 10.2.1
credit card data
Includes a statement enforcing logging of actions taken 10.2.2
by root administrators
Includes a statement enforcing logging of access to 10.2.3
audit trails
Includes a statement enforcing logging of invalid access 10.2.4
Includes a statement enforcing logging of the 10.2.5
mechanism used to identify and authenticate
Includes a statement enforcing logging of initialization 10.2.6
of audit logs is logged
Includes a statement enforcing creation/deletion of 10.2.7
system components
Lists the type of data to be logged: UserId, type of 10.3
event, Date and time,Success or failure,origin of event,
affected data, system component or resource.
Includes a statement enforcin the use of Time 10.4
synchronization technology
Describes the measures taken for the protection of 10.5
audit trails
Describes the process associated to the review of Logs 10.6/12.2
(When, How)
Includes a statement enforcing log retention for one 10.7
Detection of WAP year
Policy and procedures associated to the detection and 11.1
identification of wireless access points on a quarterly
basis
Lists all WAP and their business reasons
Documentation
ASV Scan process and scan reports Procedures associated to quarterly ASV scans and 11.2
internal scans + remediation
Includes a list of past scans, results + reports
Penetration testing Procedures associated to the execution of pen tests
Includes a statement requiring execution of 11.3
penetration testing at least annually and after any
significant changes to the environment.
Includes a list of past pen tests, results + Reports
Intrusion detection Procedures associated to the use and configuration of 11.4
process/configuration IDS/IPS
Includes a statement enforcing the use IDS at entry 11.4
points and other critical points
Lists IDS/IPS and location
File-integrity tools used Procedures and configuration associated to the File- 11.5
Integrity tools
Lists file-integrity tools used and the critical files they
are protecting.
-System executables
- Application executables
- Configuration and parameter files
- Centrally stored, historical or archived, log and audit
files
Risk Assessment Process Risk assessment process 12.1
Annual Risk Assessment Annual risk assessment reports 12.1

Daily Operational and security List of tasks/processes to be performed on a regular 12.3
procedures basis
Usage Policies and Procedures Policy and procedures associated to the use of critical 12.3
technology
Includes a statemente requiring explicit approval from 12.3.1
authorized parties to use the technologies.
Usage Policies and Procedures
Documentation
Includes a statement requiring that all technology use 12.3.2

be authenticated with user ID and password or other
authentication item (for example, token)
Includes a statement requiring a list of all devices and 12.3.3
personnel authorized to use the devices.
Includes a statement requiring labeling of devices with 12.3.4
information that can be correlated to owner, contact
information and purpose.
Includes a statement requiring acceptable uses for the 12.3.5
technology.
Includes a statement requiring acceptable network 12.3.6
locations for the technology.
Includes a statement requiring a list of company- 12.3.7
approved products.
Lists company approved products
Includes a statement requiring automatic disconnect of 12.3.8
sessions for remote-access technologies after a specific
period of inactivity
Includes a statement requiring activation of remote- 12.3.9
access technologies used by vendors and business
partners only when needed by vendors and business
partners, with immediate deactivation after use.
Includes a statement prohibiting copying, moving, or 12.3.10

storing of cardholder data onto local hard drives and
removable electronic media when accessing such data
via remote-access technologies.
Security Policy Security policy for employee and contractors 12.1

Describes Information Security responsibilities for 12.4
Employees and Contractors
Lists formal assignment of information security to a 12.5
Chief Security Officer or other security-knowledgeable
member of management.
Documentation
Includes assignment of responsibility for creating and 12.5.1

distributing security policies and procedures
Includes assignment of responsibility for monitoring 12.5.2
and analyzing security alerts and distributing
information to appropriate information security and
business unit management personnel is formally
assigned.
Includes assignment of responsibility for creating and 12.5.3
distributing security incident response and escalation
procedures is formally assigned.
Includes assignment of responsibility for administering 12.5.4
user account and authentication management
Includes assignment of responsibility for monitoring 12.5.5
and controlling all access to data
Security Awareness program Define a formal security awareness program for all 12.6
personnel
Includes multiple methods of communicating 12.6.1
awareness and educating personnel (for example,
posters, letters, memos, web based training, meetings,
and promotions).
Requires personnel to acknowledge, in writing or 12.6.2
electronically, at least annually that they have read and
understand the information security policy.
Listing of security awareness delivery. Proof that 12.6.1
personnel attend awareness training upon hire and at
least annually.
HR Screening process Description of HR screening process or associated law 12.7
limiting/preventing such due diligence
Service Provider management Policy and procedures associated to the management 12.8
policies and procedures of Service Providers
Includes proper due diligence prior to engaging any 12.8.3
service provider.
Includes a program to monitor its service providers PCI 12.8.4
DSS compliance status at least annually.
policies and procedures
Documentation
Written agreement that includes an acknowledgement 12.8.2

that the service providers are responsible for the
security of cardholder data the service providers
possess.
List of service providers 12.8.1
Incident response Plan Incident response plan 12.9
Includes: 12.9.1
Roles, responsibilities, and communication strategies in

the event of a compromise including notification of the
payment brands, at a minimum:
- Specific incident response procedures
- Business recovery and continuity procedures
- Data back-up processes
- Analysis of legal requirements for reporting
compromises (for example, California Bill 1386 which
requires notification of affected consumers in the event
of an actual or suspected compromise for any business
with California residents in their database)
- Coverage and responses for all critical system
components
- Reference or inclusion of incident response
procedures from the payment brands
Includes Assignment of specific personnel to be 12.9.3

available on a 24/7 basis to respond to alerts.
Includes annual testing 12.9.2
Includes appropriate training to staff with security 12.9.4
breach response responsibilities.
Includes a process to modify and evolve the incident
response plan according to lessons learned and to
incorporate industry developments.
Previous Incident or alert reports 12.9.1
Documentation
Location Published/DRAFT
Documentation
Location Published/DRAFT
Documentation
Documentation
Documentation
Documentation
Documentation
Documentation
Documentation
Documentation
Documentation
Documentation
Documentation
Compliance % per requirement
1 2 3 4 5 6 7 8 9 10 11 12
11 12
PCI Severity per requirements
300 216
200 135 129 132
111 111
100 67 36 64
24 14 14
0
Name Email Tel Function Areas of expertize
Name 1
Name 2
Name 3
Name 4
Merchant types
Types Description
A Card-not-present (e-commerce or mail/telephone-order) merchants, all cardholder data functions outsourced. This
would never apply to face-to-face merchants.
B Imprint-only merchants with no electronic cardholder data storage, or standalone, dial- out terminal merchants with
no electronic cardholder data storage
C-VT Merchants using only web-based virtual terminals, no electronic cardholder data storage
C Merchants with payment application systems connected to the Internet, no electronic cardholder data storage
D All other merchants not included in descriptions for SAQ types A through C above, and all service
providers defined by a payment brand as eligible to complete an SAQ.
Compensatin Constraints Objective Identified Risk
g
Control Id
# List constraints precluding Define the objective of the Identify any additional risk
compliance with the original original control; identify the posed by the lack of the
requirement. objective met by the original control.
compensating control.
1
2
3
4
5
6
7
8
9
10
11
Definition of Compensation Control Validation of Compensating Control Maintenance
Define the compensating controls and Define how the compensating controls Define process and controls
explain how they address the objectives of were validated and tested. in place to maintain
the original control and the increased risk, compensating controls
if any.
Make a list of all cryptographic keys used within the scope.
Key Id Purpose Location Key custodians Status (date) Key Length

SANS Top 20 Critical Security Controls and Subcontrols (+-200) Matching Matching Score Notes
PCI Reqs level
If Any
C1 Critical Control 1: Inventory of Authorized and 16.67% 1.5
Unauthorized Devices
C1.1 An accurate and up-to-date inventory, controlled by active Scoping P 0.5 While there is no specific inventory
monitoring and configuration management, can reduce the chance requirement, the inventory process
of attackers finding unauthorized and unprotected systems to is actually part of a scoping
exploit. exercice.
C1.2 Deploy an automated asset inventory discovery tool and use it to 11.1 P 0.5 No specific inventory requirements
build a preliminary asset inventory of systems connected to the 11.2 but target discovery is the first part
enterprise network. Both active tools that scan through network of the external scanning process.
address ranges and passive tools that identify hosts based on
analyzing their traffic should be employed.
C1.3 Maintain an asset inventory of all systems connected to the Scoping P 0.5 While there is no specific inventory
network and the network devices themselves, recording at least requirement, the inventory process
the network addresses, machine name(s), purpose of each system, is actually part of a scoping
an asset owner responsible for each device, and the department exercice.
associated with each device. The inventory should include every
system that has an Internet protocol (IP) address on the network,
including, but not limited to desktops, laptops, servers, network
equipment (routers, switches, firewalls,
C1.4 The asset inventory created must also include data on whether the - N 0
device is a portable device. Devices such as mobile phones, tablets,
laptops, and other portable electronic devices that store or process
data must be identified, regardless of whether or not they are
attached to the organizations network.
C1.5 Ensure that network inventory monitoring tools are operational and - N 0
continuously monitoring, keeping the asset inventory up to date on
a real-time basis, looking for deviations from the expected
inventory of assets on the network, and alerting security and/or
operations personnel when deviations are discovered.
C1.6 Secure the asset inventory database and related systems, ensuring - N 0
that they are included in periodic vulnerability scans and that asset
information is encrypted. Limit access to these systems to
authorized personnel only, and carefully log all such access. For
additional security, a secure copy of the asset inventory may be
kept in an off-line system air-gapped from the production network.
C1.7 In addition to an inventory of hardware, organizations should - N 0

develop an inventory of information assets that identifies their
critical information and maps critical information to the hardware
assets (including servers, workstations, and laptops) on which it is
located. A department and individual responsible for each
information asset should be identified, recorded, and tracked.
C1.8 Deploy network level authentication via 802.1x to limit and control - N 0
which devices can be connected to the network. 802.1x must be
tied into the inventory data to determine authorized vs.
unauthorized systems.
C1.9 Network access control can be used to monitor authorized systems - N 0

so if attacks occur, the impact can be remediated by moving the
untrusted system to a virtual local area network that has minimal
access.
C2 Critical Control 2: Inventory of Authorized and 0.00% 0

Unauthorized Software
C2.1 Devise a list of authorized software that is required in the - N 0
enterprise for each type of system, including servers, workstations,
and laptops of various kinds and uses.
C2.2 Deploy software inventory tools throughout the organization - N 0
covering each of the operating system types in use, including
servers, workstations, and laptops. The software inventory system
should track the version of the underlying operating system as well
as the applications installed on it. Furthermore, the tool should
record not only the type of software installed on each system, but
also its version number and patch level.
C2.3 The software inventory tool should also monitor for unauthorized - N 0
software installed on each machine. This unauthorized software
also includes legitimate system administration software installed on
inappropriate systems where there is no business need for it.
C2.4 Deploy application white listing technology that allows systems to - N 0

run only approved software and prevents execution of all other
software on the system. Such white listing tools must be based on
acceptable hashing algorithms for determining authorized binaries
to execute on a system.
C2.5 Virtual machines and/or air-gapped systems should also be used to - N 0

isolate and run applications that are required but based on higher
risk and that should not be installed within a networked
environment.
C3 Critical Control 3: Secure Configurations for 45.45% 5

Hardware and Software on Laptops, Workstations,
C3.1 and
Strict Servers
configuration management should be followed, building a 2.2 F 1
secure image that is used to build all new systems that are
deployed to the enterprise. Any existing system that becomes
compromised is re-imaged with the secure build. Regular updates
to this image are integrated into the organizations change
management processes.
C3.2 System images must have documented security settings that are 2.2 F 1
tested before deployment, approved by an organization change
control board, and registered with a central image library for the
organization or multiple organizations. These images should be
validated and refreshed on a regular basis (e.g., every six months)
to update their security configuration in light of recent
vulnerabilities and attack vectors.
C3.3 Standardized images should represent hardened versions of the 2.1 F 1
underlying operating system and the applications installed on the 2.2
system, such as those released by the NIST, NSA, Defense 2.2.2
Information Systems Agency (DISA), Center for Internet Security 2.2.3
(CIS), and others. This hardening would typically include removal of 2.2.4
unnecessary accounts, as well as the disabling or removal of
unnecessary services. Such hardening also involves, among other
measures, applying patches, closing open and unused network
ports, implementing intrusion detection systems and/or intrusion
prevention systems, and erecting host-based firewalls.
C3.4 Any deviations from the standard build or updates to the standard - N 0
build should be documented and approved in a change
management system.
C3.5 Organizations should negotiate contracts to buy systems configured - N 0
securely out of the box using standardized images, which should be
devised to avoid extraneous software that would increase their
attack surface and susceptibility to vulnerabilities.
C3.6 The master images themselves must be stored on securely - N 0

configured servers, with integrity checking tools and change
management to ensure that only authorized changes to the images
are possible. Alternatively, these master images can be stored in
offline machines, air-gapped from the production network, with
images copied via secure media to move them between the image
storage servers and the production network.
C3.7 Run the last version of software and make sure it is fully patched. 6.1 F 1
C3.7.1 Remove outdated or older software from the system. - N 0 No specific requirements but ASV
scans must fail targetsiff the version
of the operating system is an older
version no longer supported by the
vendo
C3.8 At least once a month, run assessment programs on a varying - N 0

sample of systems to determine which ones are configured
according to the secure configuration guidelines.
C3.9 Utilize file integrity checking tools on at least a weekly basis to 11.5 F 1
ensure that critical system files (including sensitive system and
application executables, libraries, and configurations) have not
been altered. All alterations to such files should be automatically
reported to security personnel. The reporting system should have
the ability to account for routine and expected changes,
highlighting unusual or unexpected alterations.
C3.10 Implement and test an automated configuration monitoring system - N 0

that measures all secure configuration elements that can be
measured through remote testing, using features such as those
included with SCAP-compliant tools to gather configuration
vulnerability information. These automated tests should analyze
both hardware and software changes, network configuration
changes, and any other modifications affecting security of the
system.
C3.11 Provide senior executives with charts showing the number of - N 0
systems that match configuration guidelines versus those that do
not match, illustrating the change of such numbers month by
month for each organizational unit.
C4 Critical Control 4: Continuous Vulnerability 20.00% 2

Assessment and Remediation
C4.1 Organizations should run automated vulnerability scanning tools 11.2 P 0.5 PCI requirements less restrictive
against all systems on their networks on a weekly or more frequent 11.2.1 (once a quarter or after major
basis. Where feasible, vulnerability scanning should occur on a 11.2.2 changes
daily basis using an up-to-date vulnerability scanning tool. 11.2.3
C4.1.1 Any vulnerability identified should be remediated in a timely 6.1 P 0.5 PCI less restrictive in terms of
manner, with critical vulnerabilities fixed within 48 hours. critical vulnerabilities fixing period
(One month)
C4.2 Event logs should be correlated with information from vulnerability - N 0
scans to fulfill two goals. First, personnel should verify that the
activity of the regular vulnerability scanning tools themselves is
logged. Second, personnel should be able to correlate attack
detection events with earlier vulnerability scanning results to
determine whether the given exploit was used against a known-
vulnerable target
C4.3 Organizations should deploy automated patch management tools - N 0
and software update tools for all systems for which such tools are
available and safe.
C4.4 In order to overcome limitations of unauthenticated vulnerability - N 0 11.2 requires ASV to run
scanning, organizations should ensure that all vulnerability unauthenticated scans with the
scanning is performed in authenticated mode either with agents known limitations. PCI rules should
running locally on each end system to analyze the security align on Top 20.
configuration or with remote scanners that are given administrative
rights on the system being tested.
C4.5 Organizations should compare the results from back-to-back 6.2 F 1 For the risk approach. Nothing
vulnerability scans to verify that vulnerabilities were addressed about validation /control process
either by patching, implementing a compensating control, or
documenting and accepting a reasonable business risk. Such
acceptance of business risks for existing vulnerabilities should be
periodically reviewed to determine if newer compensating controls
or subsequent patches can address vulnerabilities that were
previously accepted, or if conditions have changed increasing the
risk.
C4.6 Vulnerability scanning tools should be tuned to compare services - N 0 Checking services and configuration
that are listening on each machine against a list of authorized as part of a scan isn't explicitely
services. The tools should be further tuned to identify changes over required by PCI.
time on systems for both authorized and unauthorized services.
Organizations should use government-approved scanning
configuration files for their scanning to ensure that minimum
standards are met.
C4.7 Security personnel should chart the numbers of unmitigated, - N 0
critical vulnerabilities for each department/division.
C4.8 Security personnel should share vulnerability reports indicating - N 0
critical issues with senior management to provide effective
incentives for mitigation.
C4.9 Organizations should measure the delay in patching new - N 0
vulnerabilities and ensure that the delay is equal to or less than the
benchmarks set forth by the organization. The timeframe should be
no more than a week for critical patches, unless a mitigating control
that blocks exploitation is available.
C4.10 Critical patches must be evaluated in a test environment before - N 0
being pushed into production on enterprise systems. If such
patches break critical business applications on test machines, the
organization must devise other mitigating controls that block
exploitation on systems where the patch cannot be deployed
because of its impact on business functionality.
C5 Critical Control 5: Malware Defenses 37.50% 3

C5.1 Organizations should monitor workstations, servers, and mobile 5.1 P 0.5 PCI doesn't mention ati-malware
devices for active, up-to-date anti-malware protection with anti- protection.
virus, anti-spyware,
C5.1.1 personal firewalls 1.4 F 1
C5.1.2 and host-based IPS functionality. 11.4 P 0.5 11.4 requires the use of network
based IPS/IDS. PCI doesn't require
host based IPS
C5.1.3 All malware detection events should be sent to enterprise anti- - N 0 PCI doesn't address the
malware administration tools and event log servers. centralization of malware event
management. The closest
requirement is 5.2 requiring
generation of audit logs
C5.2 Organizations should employ anti-malware software and signature 5.2 F 1 5.2 is the closest requirement:
auto update features or have administrators manually push updates (Anti-virus must be current)
to all machines on a daily basis.
C5.2.1 After applying an update, automated systems should verify that - N 0
each system has received its signature update.
C5.3 Organizations should configure laptops, workstations, and servers - N 0
so that they will not auto-run content from USB tokens (i.e.,
thumb drives), USB hard drives, CDs/DVDs, Firewire devices,
external serial advanced technology attachment devices, mounted
network shares, or other removable media.
C5.4 Organizations should configure systems so that they conduct an - N 0

automated anti-malware scan of removable media when it is
inserted.
C5.5 All attachments entering the organizations e-mail gateway should - N 0 Should be part of 5.2 but email
be scanned and blocked if they contain malicious code. This servers could not be within the
scanning should be done before the e-mail is placed in the users scope.
inbox.
C5.6 Behavioral-based anomaly detection should be used to - N 0
complement and enhance traditional signature-based detection.
C5.7 Organizations should deploy network access control tools to verify - N 0
security configuration and patch-level compliance before granting
access to a network.
C5.8 Continuous monitoring should be performed on outbound traffic. - N 0
Any large transfers of data or unauthorized encrypted traffic should
be flagged and, if validated as malicious, the computer should be
moved to an isolated VLAN.
C6 Critical Control 6: Application Software Security 50.00% 4.5

C6.1 Organizations should protect web applications by deploying web 6.6 P 0.5 Code review OR WAF
application firewalls that inspect all traffic flowing to the web
application for common web application attacks, including but not
limited to cross-site scripting, SQL injection, command injection,
and directory traversal attacks. For applications that are not web-
based, specific application firewalls should be deployed if such
tools are available for the given application type. If the traffic is
encrypted, the device should either sit behind the encryption or be
capable of decrypting the traffic prior to analysis. If neither option
is appropriate, a host-based web application firewall should be
deployed.
C6.2 At a minimum, explicit error checking should be done for all input. - N 0
Whenever a variable is created in source code, the size and type
should be determined. When input is provided by the user it
should be verified that it does not exceed the size or the data type
of the memory location in which it is stored or moved in the future.
C6.3 Organizations should test in-house-developed and third-party- 6.3.2 F 1 No mention of automated static
procured web and other application software for coding errors and 6.4.5.3 code analysis software
malware insertion, including backdoors prior to deployment using 6.6
automated static code analysis software. If source code is not
available, these organizations should test compiled code using
static binary analysis tools. In particular, input validation and output
encoding routines of application software should be carefully
reviewed and tested.
C6.4 Organizations should test in-house-developed and third-party- 11.2 F 1
procured web applications for common security weaknesses using 11.2.3
automated remote web application scanners prior to deployment, 11.3.2
whenever updates are made to the application
and on a regular recurring basis.
C6.5 For applications that rely on a database, organizations should - N 0

conduct a configuration review of both the operating system
housing the database and the database software itself, checking
settings to ensure that the database system has been hardened
using standard hardening templates.
C6.6 Organizations should verify that security considerations are taken 6.3 F 1
into account throughout the requirements, design,
implementation, testing, and other phases of the software
development life cycle of all applications.
C6.7 Organizations should ensure that all software development 6.5 F 1 Testing procedure 6.5.a require to
personnel receive training in writing secure code for their specific verify training requirement t
development environment.
C6.8 Require that all in-house-developed software include white-list - N 0
filtering capabilities for all data input and output associated with
the system. These white lists should be configured to allow in or
out only the types of data needed for the system, blocking other
forms of data that are not required.
C6.9 Sample scripts, libraries, components, compilers, or any other - N 0 6.3.1 talks about account removal
unnecessary code that is not being used by an application should 6.4.4 talks about test data removal
be uninstalled or removed from the system. but no mention of scripts,
librairies,...
C7 Critical Control 7: Wireless Device Control 28.13% 4.5
C7.1 Organizations should ensure that each wireless device connected to 2.1.1 P 0.5 No mention of documented
the network matches an authorized configuration and security 4.1.1 configuration
profile, with a documented owner of the connection and a defined 11.1
business need. Organizations should deny access to those wireless
devices that do not have such a configuration and profile.
C7.2 Organizations should ensure that all wireless access points are - N 0
manageable using enterprise management tools. Access points
designed for home use often lack such enterprise management
capabilities, and should therefore be avoided in enterprise
environments.
C7.3 Network vulnerability scanning tools should be configured to detect 11.1 F 1

wireless access points connected to the wired network. Identified
devices should be reconciled against a list of authorized wireless
access points. Unauthorized (i.e., rogue) access points should be
deactivated.
C7.4 Organizations should use wireless intrusion detection systems - N 0
(WIDS) to identify rogue wireless devices and detect attack
attempts and successful compromises. In addition to WIDS, all
wireless traffic should be monitored by a wired IDS as traffic passes
into the wired network.
C7.5 802.1x should be used to control which devices are allowed to - N 0
connect to the wireless network.
C7.6 A site survey should be performed to determine what areas within - N 0
the organization need coverage. After the wireless access points are
strategically placed, the signal strength should be tuned to
minimize leakage to areas that do not need coverage.
C7.7 Where a specific business need for wireless access has been - N 0
identified, organizations should configure wireless access on client
machines to allow access only to authorized wireless networks.
C7.8 For devices that do not have an essential wireless business - N 0
purpose, organizations should disable wireless access in the
hardware configuration (basic input/output system or extensible
firmware interface), with password protections to lower the
possibility that the user will override such configurations.
C7.9 Organizations should regularly scan for unauthorized or 11.1 F 1
misconfigured wireless infrastructure devices, using techniques
such as war driving to identify access points and clients accepting
peer-to-peer connections. Such unauthorized or misconfigured
devices should be removed from the network, or have their
configurations altered so that they comply with the security
requirements of the organization.
C7.10 Organizations should ensure that all wireless traffic leverages at 4.1.1. F 1 PCI DSS doesn't specify an
least Advanced Encryption Standard (AES) encryption used with at encryption algorithm.
least WiFi Protected Access 2 protection.
C7.11 Organizations should ensure that wireless networks use - N 0
authentication protocols such as Extensible Authentication
Protocol-Transport Layer Security (EAP/TLS) or Protected Extensible
Authentication Protocol (PEAP), which provide credential
protection and mutual authentication.
C7.12 Organizations should ensure that wireless clients use strong, multi- - N 0
factor authentication credentials to mitigate the risk of
unauthorized access from compromised credentials.
C7.13 Organizations should disable peer-to-peer wireless network - N 0
capabilities on wireless clients, unless such functionality meets a
documented business need.
C7.14 Organizations should disable wireless peripheral access of devices - N 0
(such as Bluetooth), unless such access is required for a
documented business need.
C7.15 Wireless access points should never be directly connected to the 1.2.3 F 1
private network. They should either be placed behind a firewall or
put on a separate VLAN so all traffic can be examined and filtered.
C7.16 Organizations should configure all wireless clients used to access - N 0
agency networks or handle organization data in a manner so that
they cannot be used to connect to public wireless networks or any
other networks beyond those specifically allowed by the agency.
C8 Critical Control 8: Data Recovery Capability 40.00% 2

C8.1 - N 0 10.5.3 requires backup of audit trail
Organizations should ensure that each system is automatically files
backed up on at least a weekly basis, and more often for systems
storing sensitive information. To help ensure the ability to rapidly
restore a system from backup, the operating system,
application software, and data on a machine should each be
included in the overall backup procedure. These three components
of a system do not have to be included in the same backup file or
use the same backup software. However, each must be backed up
at least weekly.
C8.2 Data on backup media should be tested on a regular basis by - N 0
performing a data restoration process to ensure that the backup is
properly working.
C8.3 - N 0
Key personal should be trained on both the backup and restoration
processes. To be ready in case a major incident occurs, alternative
personnel should also be trained on the restoration process just in
case the primary IT point of contact is not available.
C8.4 Organizations should ensure that backups are properly protected 3.4 F 1
via physical security or encryption when they are stored locally, as 9.5
well as when they are moved across the network.
C8.5 Backup media, such as hard drives and tapes, should be stored in 9.5 F 1
physically secure, locked facilities.
C9 Critical Control 9: Security Skills Assessment and 33.33% 2

Appropriate Training to Fill Gaps
C9.1 Organizations should develop security awareness training for 12.6 F 1
various personnel job descriptions. The training should include
specific, incident-based scenarios showing the threats an
organization faces, and should present proven defenses against the
latest attack techniques.
C9.2 12.6 F 1
Awareness should be carefully validated with policies and training.
Policies tell users what to do, training provides them the skills to do
it, and awareness changes their behavior so that they understand
the importance of following the policy.
C9.3 Metrics should be created for all policies and measured on a - N 0 could be included in 12.6
regular basis. Awareness should focus on the areas that are (awareness program).
receiving the lowest compliance score.
C9.4 - N 0 No determination/validation of
Organizations should devise periodic security awareness level of understanding
assessment quizzes to be given to employees and contractors on at
least an annual basis in order to determine whether they
understand the information security policies and procedures, as
well as their role in those procedures.
C9.5 Organizations should conduct periodic exercises to verify that - N 0
employees and contractors are fulfilling their information security
duties by conducting tests to see whether employees will click on a
link from suspicious e-mail or provide sensitive information on the
telephone without following appropriate procedures for
authenticating a caller.
C9.6 Provide awareness sessions for users who are not following policies - N 0
after they have received appropriate training.
C10 Critical Control 10: Secure Configurations for 50.00% 4

Network Devices such as Firewalls, Routers, and
C10.1 Switches
Compare firewall, router, and switch configuration against standard 1.2.2 F 1
secure configurations defined for each type of network device in 1.1.5
use in the organization. The security configuration of such devices 1.1.6
should be documented, reviewed, and approved by an organization 2.2
change control board. Any deviations from the standard
configuration or updates to the standard configuration should be
documented and approved in a change control system.
C10.2 At network interconnection pointssuch as Internet gateways, 1.2 F 1

inter- organization connections, and internal network segments 1.2.1
with different security controlsimplement ingress and egress 1.1.5
filtering to allow only those ports and protocols with an explicit and
documented business need. All other ports and protocols should
be blocked with default-deny rules by firewalls, network-based IPS,
and/or routers.
C10.3 Network devices that filter unneeded services or block attacks - N 0
(including firewalls, network-based IPS, routers with access control
lists, etc.) should be tested under laboratory conditions with each
given organizations configuration to ensure that these devices
exhibit failure behavior in a closed/blocking fashion under
significant loads with traffic including a mixture of legitimate,
allowed traffic for that configuration intermixed with attacks at line
speeds.
C10.4 All new configuration rules beyond a baseline-hardened 1.1 F 1
configuration that allow traffic to flow through network security 1.1.1
devices, such as firewalls and network-based IPS, should be 1.1.2
documented and recorded in a configuration management system, 1.1.4
with a specific business reason for each change, a specific 1.1.5
individuals name responsible for that business need, and an 1.1.6
expected duration of the need. At least once per quarter, these
rules should be reviewed to determine whether they are still
required from a business perspective. Expired rules should be
removed.
C10.5 Network filtering technologies employed between networks with - N 0
different security levels (firewalls, network-based IPS tools, and
routers with access controls lists) should be deployed with
capabilities to filter Internet Protocol version 6 (IPv6) traffic.
However, if IPv6 is not currently being used it should be disabled.
Since many operating systems today ship with IPv6 support
activated, filtering technologies need to take it into account.
C10.6 Network devices should be managed using two-factor 2.3 F 1

authentication and encrypted sessions. Only true two-factor 8.3
authentication mechanisms should be used, such as a password
and a hardware token, or a password and biometric device.
Requiring two different passwords for accessing a system is not
two-factor authentication.
C10.7 The latest stable version of a network devices inter-network - N 0
operating system (IOS) or firmware must be installed within 30 days
of the update being released from the device vendor.
C10.8 The network infrastructure should be managed across network - N 0
connections that are separated from the business use of that
network, relying on separate VLANs or, preferably, on entirely
different physical connectivity for management sessions for
network devices.
C11 Critical Control 11: Limitation and Control of 41.67% 2.5

Network Ports, Protocols, and Services
C11.1 Host-based firewalls or port filtering tools should be applied on end - N 0

systems, with a default-deny rule that drops all traffic except those
services and ports that are explicitly allowed.
C11.2 Automated port scans should be performed on a regular basis 11.2.1 P 0.5 Part of the discovery phasis of a
against all key servers and compared to a known effective baseline. 11.2.2 newtork scan. Although, specific
If a new port is found open, an alert should be generated and 11.2.3 reports should be built to list these
reviewed. discrepencies.
C11.3 Any server that is visible from the Internet or an untrusted network - N 0
should be verified, and if it is not required for business purposes it
should be moved to an internal VLAN and given a private address.
C11.4 Services needed for business use across the internal network 1.1.5 P 0.5 1.1.5 is the closest requirement
should be reviewed quarterly via a change control group, and related to busines justification. No
business units should re- justify the business use. Sometimes mention of regular review.
services are turned on for projects or limited engagements, and
should be turned off when they are no longer needed.
C11.5 Operate critical services on separate physical host machines, such 2.2.1 F 1
as DNS, file, mail, web, and database servers.
C11.6 Application firewalls should be placed in front of any critical servers 6.6 P 0.5 PCI leaves the choice between a
to verify and validate the traffic going to the server. Any WAF or code-review.
unauthorized services or traffic should be blocked and an alert
generated.
C12 Critical Control 12: Controlled Use of 53.57% 7.5

Administrative Privileges
C12.1 Organizations should inventory all administrative passwords - N 0
C12.1. and validate that each person with administrative privileges on 7.1 P 0.5 General statement. Not talk
desktops, laptops, and servers is authorized by a senior executive specifically of Admin privileges.
C12.1. and that his/her administrative password has at least 12 semi- 8.5.10 P 0.5 General requirement of at least 7
random characters, consistent with the FDCC standard. characters. No specific req for
admin
C12.2 Before deploying any new devices in a networked environment, 2.1 F 1

organizations should change all default passwords for applications,
operating systems, routers, firewalls, wireless access points, and
other systems to a difficult-to-guess value.
C12.3 Organizations should configure all administrative-level accounts to 8.5.9 F 1 General requirement: 90 days. No
require regular password changes on a frequent interval of no specific requirement for admin
longer than 60 days. accounts.
C12.4 Organizations should ensure all service accounts have long and - N 0 Service account passwords aren't
difficult-to- guess passwords that are changed on a periodic basis, addressed.
as is done for traditional user and administrator passwords, at a
frequent interval of no longer than 90 days.
C12.5 Passwords for all systems should be stored in a well-hashed or 8.4 F 1

encrypted format.
C12.5. Furthermore, files containing these encrypted or hashed passwords - N 0
required for systems to authenticate users should be readable only
with superuser privileges.
C12.6 Organizations should ensure that administrator accounts are used - N 0
only for system administration activities, and not for reading e-mail,
composing documents, or surfing the Internet.
C12.6. Web browsers and e-mail clients especially must be configured to - N 0
never run as administrator.
C12.7 Through policy and user awareness, organizations should require - N 0
that administrators establish unique, different passwords for their
administrator and nonadministrative accounts. Each person
requiring administrative access should be given his/her own
separate account. Administrative accounts should never be shared.
Users should only use the Windows administrator or Unix root
accounts in emergency situations.
C12.8 Organizations should configure operating systems so that 8.5.12 P 0.5
passwords cannot be re-used within a certain timeframe, such as
six months.
C12.9 Organizations should implement focused auditing on the use of 10.2.2 F 1
administrative privileged functions and monitor for anomalous
behavior (e.g., system reconfigurations during the night shift).
C12.10 Organizations should configure systems to issue a log entry and 10.2.2 P 0.5 10.2.2 is the closest requirement
alert when an account is added to or removed from a domain
administrators group.
C12.11 All administrative access, including domain administrative access, - N 0 8.3 Two-factor only required for
should use two-factor authentication. remote access.
C12.12 Access to a machine (either remotely or locally) should be blocked - N 0
for administrator-level accounts. Instead, administrators should be
required to access a system using a fully logged and
nonadministrative account. Then, once logged in to the machine
without administrative privileges, the administrator should then
transition to administrative privileges using tools such as sudo on
Linux/UNIX, Runas on Windows, and other similar facilities for
other types of systems.
C12.13 If services are outsourced to third parties, language should be 12.8.2 F 1
included in the contracts to ensure that they properly protect and
control administrative access. It should be validated that they are
not sharing passwords and have accountability to hold
administrators liable for their actions.
C12.14 Organizations should segregate administrator accounts based on 7.2 P 0.5

defined roles within the organization. For example, Workstation 7.2.2
admin accounts should only be allowed administrative access of
workstations, laptops, etc.
C13 Critical Control 13: Boundary Defense 50.00% 6.5

C13.1 Organizations should deny communications with (or limit data flow - N 0
to) known malicious IP addresses (black lists) or limit access to
trusted sites (white lists). Lists of bogon addresses (unroutable or
otherwise unused IP addresses) are publicly available on the
Internet from various sources, and indicate a series of IP addresses
that should not be used for legitimate traffic traversing the
Internet.
C13.1. Tests can be periodically carried out by sending packets from bogon 1.1.1 P 0.5
source IP addresses into the network to verify that they are not
transmitted through network perimeters.
C13.2 Deploy network-based IDS sensors on Internet and extranet DMZ 11.4 F 1
systems and networks that look for unusual attack mechanisms and
detect compromise of these systems. These network-based IDS
sensors may detect attacks through the use of
signatures, network behavior analysis, or other mechanisms to
analyze traffic.
C13.3 Network-based IPS devices should be deployed to compliment IDS 11.4 F 1

by
blocking known bad signature or behavior of attacks. As attacks
become automated, methods such as IDS typically delay the
amount of time it takes for someone to react to an attack. A
properly configured network-based IPS can provide automation to
C13.4 block
On DMZ badnetworks,
traffic. monitoring systems (which may be built in to - N 0
the IDS sensors or deployed as a separate technology) should be
configured to record at least packet header information, and
preferably full packet header and payloads of the traffic destined
for or passing through the network border. This traffic should be
sent to a properly configured Security Event Information
Management (SEIM) system so that events can be correlated from
all devices on the network.
C13.5 Define a network architecture that clearly separates internal 1.1.3 F 1
systems from DMZ and extranet systems. DMZ systems are 1.3.7
machines that need to communicate with the internal network as
well as the Internet, while extranet systems are those whose
primary communication is with other systems at a business partner.
DMZ systems should never contain sensitive data and internal
systems should never be directly accessible from the Internet.
C13.6 Design and implement network perimeters so that all outgoing - N 0

web, file transfer protocol (FTP), and secure shell traffic to the
Internet must pass through at least one proxy on a DMZ network.
The proxy should support logging individual TCP sessions; blocking
specific URLs, domain names, and IP addresses to implement a
black list; and applying white lists of allowed sites that can be
accessed through the proxy while blocking all other sites.
Organizations should force outbound traffic to the Internet through
an authenticated proxy server on the enterprise perimeter. Proxies
can also be used to encrypt all traffic leaving an organization.
C13.7 Require all remote login access (including VPN, dial-up, and other 8.3 F 1
forms of access that allow login to internal systems) to use two-
factor authentication.
C13.8 All devices remotely logging into the internal network should be - N 0
managed by the enterprise, with remote control of their
configuration, installed software,
and patch levels.
C13.9 Organizations should periodically scan for back-channel 11.1 F 1 Discovery

connections to the Internet that bypass the DMZ, including 11.2
unauthorized VPN connections and dual-homed hosts connected to 11.3
the enterprise network and to other networks via wireless, dial-up
modems, or other mechanisms.
C13.10 To limit access by an insider or malware spreading on an internal 1.3.7 P 0.5

network, organizations should devise internal network
segmentation schemes to limit traffic to only those services needed
for business use across the internal network.
C13.11 Organizations should develop plans to rapidly deploy filters on - N 0
internal networks to help stop the spread of malware or an
intruder.
C13.12 To minimize the impact of an attacker pivoting between 6.6 P 0.5
compromised systems, only allow DMZ systems to communicate
with private network systems via application proxies or application-
aware firewalls over approved channels
C13.13 To help identify covert channels exfiltrating data through a firewall, - N 0

built-in firewall session tracking mechanisms included in many
commercial firewalls should be configured to identify TCP sessions
that last an unusually long time for the given organization and
firewall device, alerting personnel about the source and destination
addresses associated with these long sessions.
C14 Critical Control 14: Maintenance, Monitoring, and 68.75% 5.5

Analysis of Audit Logs
C14.1 Validate audit log settings for each hardware device and the 10.2 F 1
software installed on it, ensuring that logs include a date, 10.3
timestamp, source addresses, destination addresses, and various
other useful elements of each packet and/or transaction.
C14.1. Systems should record logs in a standardized format such as syslog - N 0

entries or those outlined by the Common Event Expression
initiative. If systems cannot generate logs in a standardized format,
log normalization tools can be deployed to convert logs into a
standardized format.
C.14.2 Ensure that all systems that store logs have adequate storage space - N 0
for the logs generated on a regular basis, so that log files will not fill
up between log rotation intervals.
C14.2. The logs must be archived and digitally signed on a periodic basis. 10.5 P 0.5 No requirement for digital
10.5.3 signature
C14.2 All remote access to a network, whether to the DMZ or the internal - N 0 Not specific requirement for
network (i.e., VPN, dial-up, or other mechanism), should be logged remote access
verbosely.
C.14.3 Operating systems should be configured to log access control 10.2.1 - F 1 Resource = CC data
events associated with a user attempting to access a resource (e.g., 10.2.7
a file or directory) without the appropriate permissions. Failed 10.3.4
logon attempts must also be logged.
C14.4 Security personnel and/or system administrators should run 10.6 F 1

biweekly reports that identify anomalies in logs. They should then
actively review the anomalies, documenting their findings.
C.14.5 Each organization should include at least two synchronized time 10.4 P 0.5 Don't mention about # of time
sources (i.e., Network Time Protocol NTP) from which all servers (10.4.3) synchronization sources
and network equipment retrieve time information on a regular
basis so that timestamps in logs are consistent.
C14.6 Network boundary devices, including firewalls, network-based IPS, 10.2 P 0.5 No specific mention of such devices
and inbound and outbound proxies, should be configured to 10.6
verbosely log all traffic (both allowed and blocked) arriving at the
device.
C14.7 For all servers, organizations should ensure that logs are written to 10.5.4 F 1
write-only devices or to dedicated logging servers running on
separate machines from hosts generating the event logs, lowering
the chance that an attacker can manipulate logs stored locally on
compromised machines.
C14.8 Organizations should deploy a SEIM system tool for log aggregation - N 0 No mention of SEIM
and consolidation from multiple machines and for log correlation
and analysis. Standard government scripts for analysis of the logs
should be deployed and monitored, and customized local scripts
should also be used. Using the SEIM tool, system administrators
and security personnel should devise profiles of common events
from given systems so that they can tune detection to focus on
unusual activity, avoid false positives, more rapidly identify
anomalies, and prevent overwhelming analysts with insignificant
alerts.
C15 Critical Control 15: Controlled Access Based on the 28.57% 2

Need to Know
C15.1 Organizations should establish a multi-level data - N 0 Could be part of a risk assessment
identification/classification scheme (e.g., a three- or four-tiered methodology.
scheme with data separated into categories based on the impact of
exposure of the data).
C15.2 Organizations should ensure that file shares have defined controls - N 0
(such as Windows share access control lists) that specify at least
that only authenticated users can access the share.
C15.3 Organizations should enforce detailed audit logging for access to 7.2 P 0.5 7.2 is the closest requiremement
nonpublic data and special authentication for sensitive data.
C15.4 The network should be segmented based on the trust levels of the 1.2 P 0.5
information stored on the servers. 1.3
C15.4. Whenever information flows over a network of lower trust level, 4.1 F 1
the information should be encrypted.
C15.5 The use of portable USB drives should either be limited or data - N 0
should automatically be encrypted before it is written to a portable
drive.
C15.6 Host-based data loss prevention (DLP) should be used to enforce - N 0
ACLs even when data is copied off a server. In most organizations,
access to the data is controlled by ACLs that are implemented on
the server. Once the data have been copied to a desktop system
the ACLs are no longer enforced and the users can send the data to
whomever they want.
C15.7 Deploy honeytokens on key servers to identify users who might be - N 0
trying to access information that they should not access.
C16 Critical Control 16: Account Monitoring and Control 68.18% 7.5
C16.1 Review all system accounts and disable any account that cannot be - N 0
associated with a business process and owner.
C16.2 Systems should automatically create a report on a daily basis that - N 0
includes a list of locked-out accounts, disabled accounts, accounts
with passwords that exceed the maximum password age, and
accounts with passwords that never expire. This list should be sent
to the associated system administrator in a secure fashion.
C16.3 Organizations should establish and follow a process for revoking 8.5.4 F 1
system access by disabling accounts immediately upon termination
of an employee or contractor.
C16.4 Organizations should regularly monitor the use of all accounts, 8.5.6 F 1
automatically 8.5.15
logging off users after a standard period of inactivity.
C16.5 Organizations should monitor account usage to determine dormant 8.5.5 F 1 PCI less restrictive (90 days)
accounts
that have not been used for a given period, such as 30 days,
notifying the user or users manager of the dormancy. After a
longer period, such as 60 days, the account should be disabled.
C16.6 When a dormant account is disabled, any files associated with that - N 0
account should be encrypted and moved to a secure file server for
analysis by security or management personnel.
C16.7 All nonadministrator accounts should be required to have a 8.5.10 P 0.5 PCI les restrictive (7 characters)
minimum length of 12 characters,
C16.7. contain letters, numbers, and special characters 8.5.11 P 0.5 PCI less restrictive (No special
characters)
C16.7. be changed at least every 90 days, have a minimal age of one day, 8.5.9 F 1 PCI is also 90 days
C1.7.3 and not be allowed to use the previous 15 passwords as a new 8.5.12 P 0.5 PCI less restrictive (the last 4)
password.
C16.8 After eight failed logon attempts within a 45-minute period, the 8.5.13 F 1 PCI more restrictive (6 attempts)
account should be locked
C16.8. for 120 minutes. 8.5.14 P 0.5 PCI less restrictive (30 minutes or
unlocked by administrator)
C16.9 On a periodic basis, such as quarterly or at least annually, 12.2 P 0.5 Partially covered through the
organizations should require that managers match active requirement for a User account
employees and contractors with each account belonging to their maintenance procedure.
managed staff. Security or system administrators should then
disable accounts that are not assigned to active employees or
contractors.
C16.10 Organizations should monitor attempts to access deactivated - N 0
accounts through audit logging.
C16.11 Organizations should profile each users typical account usage by - N 0
determining normal time-of-day access and access duration for
each user. Daily reports should be generated that indicate users
who have logged in during unusual hours or have exceeded their
normal login duration by 150 percent.
C17 Critical Control 17: Data Loss Prevention 30.00% 3

C17.1 Organizations should deploy approved hard drive encryption - N 0
software to mobile machines that hold sensitive data.
C17.2 Network monitoring tools should analyze outbound traffic looking 10.0 F 1
for a variety of anomalies, including large file transfers, long-time
persistent connections, connections at regular repeated intervals,
unusual protocols and ports in use, and possibly the presence of
certain keywords in the data traversing the network perimeter.
C17.3 Deploy an automated tool on network perimeters that monitors for - N 0

certain sensitive information (i.e., personally identifiable
information), keywords, and other document characteristics to
discover unauthorized attempts to exfiltrate data across network
boundaries and block such transfers while alerting information
security personnel.
C17.4 Conduct periodic scans of server machines using automated tools - N 0
to determine whether sensitive data (i.e., personally identity,
health, credit card, and classified information) is present on the
system in clear text. These tools, which search for patterns that
indicate the presence of sensitive information, can help identify if a
business or technical process is leaving behind or otherwise leaking
sensitive information in data at rest.
C17.5 Use outbound proxies to be able to monitor and control all - N 0

information leaving an organization.
C17.6 Data should be moved between networks using secure, 4.00 F 1 PCI requires encryption only
authenticated, and encrypted mechanisms. through public network
C17.7 Data stored on removable and easily transported storage media 3.4 F 1
such as USB tokens (i.e., thumb drives), USB portable hard drives,
and CDs/DVDs should be encrypted. Systems should be configured
so that all data written to such media are automatically encrypted
without user intervention.
C17.8 If there is no business need for supporting such devices, - N 0

organizations should configure systems so that they will not write
data to USB tokens or USB hard drives. If such devices are required,
enterprise software should be used that can configure systems to
allow only specific USB devices (based on serial number or other
unique property) to be accessed, and that can automatically
encrypt all data placed on such devices. An inventory of all
authorized devices must be maintained.
C17.9 Use network-based DLP solutions to monitor and control the flow - N 0
of data within the network. Any anomalies that exceed the normal
traffic patterns should be noted and appropriate action taken to
address them,.
C17.1 Monitor all traffic leaving the organization and detect any - N 0
0 unauthorized use of encryption. Attackers often use an encrypted
channel to bypass network security devices. Therefore it is essential
that organizations are able to detect rogue connections, terminate
the connection, and remediate the infected system.
C18 Critical Control 18: Incident Response Capability 100.00% 6

C18.1 12.5.3 F 1
Organizations should ensure that they have written incident 12.9
response procedures that include a definition of personnel roles for
handling incidents. The procedures should define the phases of
incident handling consistent with the NIST guidelines.
C18.2 Organizations should assign job titles and duties for handling 12.9.1 F 1
computer and network incidents to specific individuals.
Organizations should define management personnel who will
C18.3 support the incident handling process by acting in key decision- 12.9.1 F 1
making roles.
C18.4 12.9.1 F 1
Organizations should devise organization-wide standards for the
time required for system administrators and other personnel to
report anomalous events to the incident handling team, the
mechanisms for such reporting, and the kind of information that
should be included in the incident notification. This reporting
should also include notifying the appropriate US Community
Emergency Response Team in accordance with all government
requirements for involving that organization in computer incidents.
C18.5 Organizations should publish information for all personnel, 12.9.4 F 1
including employees and contractors, regarding reporting computer
anomalies and incidents to the incident handling team. Such
information should be included in routine employee awareness
activities.
C18.6 12.9.4 F 1
Organizations should conduct periodic incident scenario sessions
for personnel associated with the incident handling team to ensure
that they understand current threats and risks, as well as their
responsibilities in supporting the incident handling team.
C19 Critical Control 19: Secure Network Engineering 50.00% 2.5

C19.1 The network should be designed using a minimum of a three-tier 1.3 F 1
architecture (DMZ, middleware, and private network). Any system 1.3.1
accessible from the Internet should be on the DMZ, but DMZ 1.3.2
systems never contain sensitive data. Any system with sensitive 1.3.3
data should reside on the private network and never be directly
accessible from the Internet. DMZ systems should communicate
with private network systems through an application proxy residing
on the middleware tier.
C19.2 To support rapid response and shunning of detected attacks, the - N 0
network architecture and the systems that make it up should be
engineered for rapid deployment of new access control lists, rules,
signatures, blocks, blackholes, and other defensive measures.
C19.3 DNS should be deployed in a hierarchical, structured fashion, with - N 0
all internal network client machines configured to send requests to
intranet DNS servers, not to DNS servers located on the Internet.
These internal DNS servers should be configured to forward
requests they cannot resolve to DNS servers located on a protected
DMZ. These DMZ servers, in turn, should be the only DNS servers
allowed to send requests to the Internet.
C19.4 Security should be built into all phases of the software 6.3 F 1
development lifecycle, ensuring that any security issues are
addressed as early as possible.
C19.5 Organizations should segment the enterprise network into multiple, 1.3 P 0.5 Network segmentation is
separate trust zones to provide more granular control of system addressed as a way to reduce the
access and additional intranet boundary defenses. scope of the assessment.
C20 Critical Control 20: Penetration Tests and Red 35.71% 2.5
Team Exercises
C20.1 Organizations should conduct regular external and internal 11.3 F 1
penetration tests to identify vulnerabilities and attack vectors that
can be used to exploit enterprise systems successfully. Penetration
testing should occur from outside the network perimeter (i.e., the
Internet or wireless frequencies around an organization) as well as
from within its boundaries (i.e., on the internal network) to
simulate both outsider and insider attacks.
C20.2 Organizations should perform periodic red team exercises to test - N 0

the readiness of organizations to identify and stop attacks or to
respond quickly and effectively.
C20.3 Organizations should ensure that systemic problems discovered in 11.3b F 1 Noted exploitable vulnerabilities
penetration tests and red team exercises are fully mitigated. must be corrected
C20.4 - N 0
Organizations should measure how well the organization has

reduced the significant enablers for attackers by setting up
automated processes to find:
o Cleartext e-mails and documents with password in the filename
or body o Critical network diagrams stored online and in cleartext
o Critical configuration files stored online and in cleartext
o Vulnerability assessment, penetration test reports, and red team
finding
documents stored online and in cleartext
o Other sensitive information identified by management personnel
as critical to the
operation of the enterprise during the scoping of a penetration test
or red team
exercise.
C20.5 Supplement P 0.5 Social engineering is mentionned
Social engineering should be included within a penetration test. within the Supplemental document
The human element is often the weakest link in an organization and about pen test
one that attackers
often target.
C20.6 Organizations should devise a scoring method for determining the - N 0
results of
red team exercises so that results can be compared over time.
C20.7 - N 0
Organizations should create a test bed that mimics a production
environment
for specific penetration tests and red team attacks against elements
that are not typically tested in production, such as attacks against
supervisory control and data acquisition and other control systems.
Report here under all vulnerability scans executed.
Date Int/Ext Scanning solution Operator or ASV's IPs (FAIL/PASS) Report

location
Report here under all penetration tests executed.
Date Int/Ext Tests provider IPs # exploitable Report location

vulnerabilities
Firewallstoare
Return Table of content
devices that control computer traffic allowed between an entitys networks (internal) and untrusted networks (external), as w
A firewall examines all network traffic and blocks those transmissions that do not meet the specified security criteria.
Requirement
All systems must1: beInstall and
protected maintain
from a firewall
unauthorized access configuration to protect
from untrusted networks, cardholder
whether enteringdata
the system via the Internet as e-comm
Other system components may provide firewall functionality, provided they meet the minimum requirements for firewalls as provided in R
Major Observations from the Verizon 2011 PCI Compliance Report:

44 percent compliance, compared to the 46 percent who were found compliant in previous report
The most difficult part of meeting this requirement is the documentation of network device configurations, with only 63 percent of compa
Documentation is however, its frequently outdated.
Restricting inbound access (PCI Requirement 1.2.1) continues to be an issue for many being audited, with 23 percent of businesses found t
Insecure traffic, such as FTP and Telnet, is still flowing through many networks.
Most businesses dont have anyone with the time to dig into every rule in the firewalls to understand the complete rule sets.
PCI DSS Requirement Guidance
1.1 Establish firewall and router configuration Firewalls and routers are key components of the
standards that include the following: architecture that controls entry to and exit from the
network. These devices are software or hardware devices
that block unwanted access and manage authorized
access into and out of the network. Without policies and
procedures in place to document how staff should
configure firewalls and routers, a business could easily
lose its first line of defense in data-protection. The
policies and procedures will help to ensure that the
organizations first line of defense in the protection of its
data remains strong.
Virtual environments where data flows do not transit a
physical network should be assessed to ensure
appropriate network segmentation is achieved.
1.1.1 A formal process for approving and testing A policy and process for approving and testing all
all network connections and changes to the connections and changes to the firewalls and
firewall and router configurations routers will help prevent security problems caused
by misconfiguration of the network, router, or
firewall.
Data flows between virtual machines should be
included in policy and process
1.1.2 Current network diagram with all Network diagrams enable the organization to
connections to cardholder data, including any identify the location of all its network devices.
wireless networks Additionally, the network diagram can be used to
map the data flow of cardholder data across the
network and between individual devices in order to
fully understand the scope of the cardholder data
environment. Without current network and data
flow diagrams, devices with cardholder data may be
overlooked and may unknowingly be left out of the
layered security controls implemented for PCI DSS
and thus vulnerable to compromise.
Network and data flow diagrams should include
virtual system components and document Intra-
host data flows.
1.1.3 Requirements for a firewall at each Internet Using a firewall on every connection coming into (and
connection and between any demilitarized zone out of) the network allows the organization to monitor
(DMZ) and the internal network zone and control access in and out, and to minimize the
chances of a malicious individuals obtaining access to
the internal network.
1.1.4 Description of groups, roles, and This description of roles and assignment of responsibility
responsibilities for logical management of ensures that someone is clearly responsible for the
network components security of all components and is aware of their
responsibility, and that no devices are left unmanaged.
1.1.5 Documentation and business justification Compromises often happen due to unused or insecure
for use of all services, protocols, and ports service and ports, since these often have known
allowed, including documentation of security vulnerabilitiesand many organizations are vulnerable
features implemented for those protocols to these types of compromises because they do not
considered to be insecure. Examples of insecure patch security vulnerabilities for services, protocols, and
services, protocols, or ports include but are not ports they don't use (even though the vulnerabilities are
limited to FTP, Telnet, POP3, IMAP, and SNMP. still present). Each organization should clearly decide
which services, protocols, and ports are necessary for
their business, document them for their records, and
ensure that all other services, protocols, and ports and
disabled or removed. Also, organizations should consider
blocking all traffic and only re-opening those ports once
a need has been determined and documented.
Additionally, there are many services, protocols, or ports

that a business may need (or have enabled by default)
that are commonly used by malicious individuals to
compromise a network. If these insecure services,
protocols, or ports are necessary for business, the risk
posed by use of these protocols should be clearly
understood and accepted by the organization, the use of
the protocol should be justified, and the security
features that allow these protocols to be used securely
should be documented and implemented. If these
insecure services, protocols, or ports are not necessary
for business, they should be disabled or removed.
1.1.6 Requirement to review firewall and router This review gives the organization an opportunity
rule sets at least every six months at least every six months to clean up any
unneeded, outdated, or incorrect rules, and ensure
that all rule sets allow only authorized services and
ports that match business justifications.
It is advisable to undertake these reviews on a
more frequent basis, such as monthly, to ensure
that the rule sets are current and match the needs
of the business without opening security holes and
running unnecessary risks.
ports that match business justifications.
It is advisable to undertake these reviews on a
more frequent basis, such as monthly, to ensure
that the rule sets are current and match the needs
of the business without opening security holes and
running unnecessary risks.
1.2 Build firewall and router configurations that It is essential to install network protection, namely a
restrict connections between untrusted networks system component with (at a minimum) stateful
and any system components in the cardholder data inspection firewall capability, between the internal,
environment. trusted network and any other untrusted network that is
external and/or out of the entitys ability to control or
Note: An untrusted network is any network that is manage. Failure to implement this measure correctly
external to the networks belonging to the entity means that the entity will be vulnerable to unauthorized
under review, and/or which is out of the entity's access by malicious individuals or software.
ability to control or manage.
If firewall functionality is installed but does not have
rules that control or limit certain traffic, malicious
individuals may still be able to exploit vulnerable
protocols and ports to attack your network.
1.2.1 Restrict inbound and outbound traffic to This requirement is intended to prevent malicious
that which is necessary for the cardholder data individuals from accessing the organization's network via
environment. unauthorized IP addresses or from using services,
protocols, or ports in an unauthorized manner (for
example, to send data they've obtained from within your
network out to an untrusted server.
All firewalls should include a rule that denies all inbound

and outbound traffic not specifically needed. This will
prevent inadvertent holes that would allow other,
unintended and potentially harmful traffic in or out.
1.2.2 Secure and synchronize router configuration While running configuration files are usually
files. implemented with secure settings, the start-up files
(routers run these files only upon re-start) may not be
implemented with the same secure settings because
they only run occasionally. When a router does re-start
without the same secure settings as those in the running
configuration files, it may result in weaker rules that
allow malicious individuals into the network, because the
start-up files may not be implemented with the same
secure settings as the running configuration files.
1.2.3 Install perimeter firewalls between any The known (or unknown) implementation and
wireless networks and the cardholder data exploitation of wireless technology within a network is a
environment, and configure these firewalls to common path for malicious individuals to gain access to
deny or control (if such traffic is necessary for the network and cardholder data. If a wireless device or
business purposes) any traffic from the wireless network is installed without a companys knowledge, a
environment into the cardholder data malicious individual could easily and invisibly enter the
environment. network. If firewalls do not restrict access from wireless
networks into the payment card environment, malicious
individuals that gain unauthorized access to the wireless
network can easily connect to the payment card
environment and compromise account information.
Firewalls must be installed between all wireless networks

and the CDE, regardless of the purpose of the
environment to which the wireless network is connected.
This may include, but is not limited to, corporate
networks, retail stores, warehouse environments, etc.
1.3 Prohibit direct public access between the A firewall's intent is to manage and control all
Internet and any system component in the connections between public systems and internal
cardholder data environment. systems (especially those that store, process or transmit
cardholder data). If direct access is allowed between
public systems and the CDE, the protections offered by
the firewall are bypassed, and system components
storing cardholder data may be exposed to compromise.
1.3.1 Implement a DMZ to limit inbound traffic to The DMZ is that part of the network that manages
only system components that provide authorized connections between the Internet (or other untrusted
publicly accessible services, protocols, and ports. networks), and internal services that an organization
needs to have available to the public (like a web server).
It is the first line of defense in isolating and separating
traffic that needs to communicate with the internal
network from traffic that does not.
This functionality is intended to prevent malicious

individuals from accessing the organization's network via
unauthorized IP addresses or from using services,
protocols, or ports in an unauthorized manner.
1.3.2 Limit inbound Internet traffic to IP Termination of IP connections at the DMZ provides
addresses within the DMZ. opportunity for inspection and restriction of
source/destination, and/or inspection / blocking of
content, thus preventing unfiltered access between
untrusted and trusted environments.
1.3.3 Do not allow any direct connections Termination of IP connections both inbound and
inbound or outbound for traffic between the outbound provides opportunity for inspection and
Internet and the cardholder data environment. restriction of source/destination, and/or inspection /
blocking of content, thus preventing unfiltered access
between untrusted and trusted environments. This helps
prevent, for example, malicious individuals from sending
data they've obtained from within your network out to
an external untrusted server in an untrusted network.
1.3.4 Do not allow internal addresses to pass Normally a packet contains the IP address of the
from the Internet into the DMZ. computer that originally sent it. This allows other
computers in the network to know where it came
from. In certain cases, this sending IP address will be
spoofed by malicious individuals.
For example, malicious individuals send a packet with
a spoofed address, so that (unless your firewall
prohibits it) the packet will be able to come into your
network from the Internet, looking like it is internal,
and therefore legitimate, traffic. Once the malicious
individual is inside your network, they can begin to
compromise your systems.
Ingress filtering is a technique you can use on your

firewall to filter packets coming into your network to,
among other things, ensure packets are not spoofed
to look like they are coming from your own internal
network.
For more information on packet filtering, consider
obtaining information on a corollary technique called
egress filtering.
1.3.5 Do not allow unauthorized outbound traffic All traffic outbound from inside the cardholder data
from the cardholder data environment to the environment should be evaluated to ensure that
Internet. outbound traffic follows established, authorized rules.
Connections should be inspected to restrict traffic to
only authorized communications (for example by
restricting source/destination addresses/ports, and/or
blocking of content).
Where environments have no inbound connectivity

allowed, outbound connections may be achieved via
architectures or system components that interrupt and
inspect the IP connectivity.
1.3.6 Implement stateful inspection, also known A firewall that performs stateful packet inspection
as dynamic packet filtering. (That is, only keeps "state" (or the status) for each connection to the
established connections are allowed into the firewall. By keeping "state," the firewall knows
network.) whether what appears to be a response to a previous
connection is truly a response (since it "remembers"
the previous connection) or is a malicious individual or
software trying to spoof or trick the firewall into
allowing the connection.
1.3.7 Place system components that store Cardholder data requires the highest level of
cardholder data (such as a database) in an information protection. If cardholder data is located
internal network zone, segregated from the DMZ within the DMZ, access to this information is easier for
and other untrusted networks. an external attacker, since there are fewer layers to
penetrate.
Note: the intent of this requirement does not include
storage in volatile memory.
1.3.8 Do not disclose private IP addresses and Restricting the broadcast of IP addresses is essential to
routing information to unauthorized parties. prevent a hacker learning the IP addresses of the
internal network, and using that information to access
Note: Methods to obscure IP addressing may the network.
include, but are not limited to:
Effective means to meet the intent of this requirement
- Network Address Translation (NAT) may vary depending on the specific networking
- Placing servers containing cardholder data technology being used in your environment. For
behind proxy servers/firewalls or content caches, example, the controls used to meet this requirement
- Removal or filtering of route advertisements for may be different for IPv4 networks than for IPv6
private networks that employ registered networks.
addressing,
- Internal use of RFC1918 address space instead of One technique to prevent IP address information from
registered addresses. being discovered on an IPv4 network is to implement
Network Address translation (NAT). NAT, which is
typically managed by the firewall, allows an organization
to have internal addresses that are visible only inside the
network and external address that are visible externally.
If a firewall does not hide or mask the IP addresses of
the internal network, a malicious individual could
discover internal IP addresses and attempt to access the
network with a spoofed IP address.
For IPv4 networks, the RFC1918 address space is

reserved for internal addressing, and should not be
routable on the Internet. As such, it is preferred for IP
addressing of internal networks. However, organizations
may have reasons to utilize non-RFC1918 address space
on the internal network. In these circumstances,
prevention of route advertisement or other techniques
should be used to prevent internal address space being
broadcast on the Internet or disclosed to unauthorized
parties.
1.4 Install personal firewall software on any mobile If a computer does not have a firewall or anti-virus
and/or employee-owned computers with direct program installed, spyware, Trojans, viruses, worms and
connectivity to the Internet (for example, laptops rootkits (malware) may be downloaded and/or installed
used by employees), which are used to access the unknowingly. The computer is even more vulnerable
organizations network. when directly connected to the Internet and not behind
the corporate firewall. Malware loaded on a computer
when not behind the corporate firewall can then
maliciously target information within the network when
the computer is re-connected to the corporate network.
Note: The intent of this requirement applies to remote

access computers regardless of whether they are
employee owned or company owned. Systems that
cannot be managed by corporate policy introduce
weaknesses to the perimeter and provide opportunities
that malicious individuals may exploit.
when not behind the corporate firewall can then
maliciously target information within the network when
the computer is re-connected to the corporate network.
Note: The intent of this requirement applies to remote

access computers regardless of whether they are
employee owned or company owned. Systems that
cannot be managed by corporate policy introduce
weaknesses to the perimeter and provide opportunities
that malicious individuals may exploit.
and untrusted networks (external), as well as traffic into and out of more sensitive areas within an entitys internal trusted networks. The cardholder dat
d security criteria.
r data
ng the system via the Internet as e-commerce, employee Internet access through desktop browsers, employee e-mail access, dedicated connections such
uirements for firewalls as provided in Requirement 1. Where other system components are used within the cardholder data environment to provide fire
rations, with only 63 percent of companies meeting Requirement 1.1.5 regularly.
d, with 23 percent of businesses found to be non-compliant at the time of the assessment.
nd the complete rule sets.
SANS Testing Procedure

Top 20 Critical
Security Controls
C10.4 1.1 Obtain and inspect the firewall and router configuration standards and other
documentation specified below to verify that standards are complete. Complete the
following:
C10.4 1.1.1 Verify that there is a formal process for testing and approval of all network
C13.1.1 connections and changes to firewall and router configurations.
C10.4 1.1.2.a Verify that a current network diagram (for example, one that shows
cardholder data flows over the network) exists and that it documents all
connections to cardholder data, including any wireless networks.
1.1.2.b Verify that the diagram is kept current.
C13.5 1.1.3.a Verify that firewall configuration standards include requirements for a
firewall at each Internet connection and between any DMZ and the internal network
zone.
1.1.3.b Verify that the current network diagram is consistent with the firewall
configuration standards.
C10.4 1.1.4 Verify that firewall and router configuration standards include a description of
groups, roles, and responsibilities for logical management of network components.
C10.1 1.1.5.a Verify that firewall and router configuration standards include a documented
C10.2 list of services, protocols and ports necessary for businessfor example, hypertext
C10.4 transfer protocol (HTTP) and Secure Sockets Layer (SSL), Secure Shell (SSH), and
C11.4 Virtual Private Network (VPN) protocols.
1.1.5.b Identify insecure services, protocols, and ports allowed; and verify they are
necessary and that security features are documented and implemented by
examining firewall and router configuration standards and settings for each service.
C10.1 1.1.6.a Verify that firewall and router configuration standards require review of
C10.4 firewall and router rule sets at least every six months.
1.1.6.b Obtain and examine documentation to verify that the rule sets are reviewed
at least every six months.
C10.2 1.2 Examine firewall and router configurations to verify that connections are restricted
C15.4 between untrusted networks and system components in the cardholder data
environment, as follows:
C10.2 1.2.1.a Verify that inbound and outbound traffic is limited to that which is necessary
for the cardholder data environment, and that the restrictions are documented.
1.2.1.b Verify that all other inbound and outbound traffic is specifically denied, for
example by using an explicit deny all or an implicit deny after allow statement.
C10.1 1.2.2 Verify that router configuration files are secure and synchronizedfor
example, running configuration files (used for normal running of the routers) and
start-up configuration files (used when machines are re-booted), have the same,
secure configurations.
C15.4 1.2.3 Verify that there are perimeter firewalls installed between any wireless
C7.15 networks and systems that store cardholder data, and that these firewalls deny or
control (if such traffic is necessary for business purposes) any traffic from the
wireless environment into the cardholder data environment.
C19.1 1.3 Examine firewall and router configurationsincluding but not limited to the choke
C19.5 router at the Internet, the DMZ router and firewall, the DMZ cardholder segment, the
perimeter router, and the internal cardholder network segmentto determine that
there is no direct access between the Internet and system components in the internal
cardholder network segment, as detailed below.
C19.1 1.3.1 Verify that a DMZ is implemented to limit inbound traffic to only system
components that provide authorized publicly accessible services, protocols, and
ports.
C19.1 1.3.2 Verify that inbound Internet traffic is limited to IP addresses within the DMZ.
C19.1 1.3.3 Verify direct connections inbound or outbound are not allowed for traffic
between the Internet and the cardholder data environment.
C13.5 1.3.4 Verify that internal addresses cannot pass from the Internet into the DMZ.
C10.2 1.3.5 Verify that outbound traffic from the cardholder data environment to the
Internet is explicitly authorized
NC 1.3.6 Verify that the firewall performs stateful inspection (dynamic packet filtering).
(Only established connections should be allowed in, and only if they are associated
with a previously established session.)
C13.5 1.3.7 Verify that system components that store cardholder data are on an internal
C13.10 network zone, segregated from the DMZ and other untrusted networks.
NC 1.3.8.a Verify that methods are in place to prevent the disclosure of private IP
addresses and routing information from internal networks to the Internet.
1.3.8.b Verify that any disclosure of private IP addresses and routing information to
external entities is authorized.
C5.1.1 1.4.a Verify that mobile and/or employee-owned computers with direct connectivity
to the Internet (for example, laptops used by employees), and which are used to
access the organizations network, have personal firewall software installed and active.
1.4.b Verify that the personal firewall software is configured by the organization to
specific standards and is not alterable by users of mobile and/or employee-owned
computers.
ernal trusted networks. The cardholder data environment is an example of a more sensitive area within an entitys trusted network.
e e-mail access, dedicated connections such as business-to-business connections, via wireless networks, or via other sources. Often, seemingly insignific
cardholder data environment to provide firewall functionality, these devices must be included within the scope and assessment of Requirement 1.
Merchant TYPES
Validation instruction for QSA/ISA Priority A B
(For In-Place Requirements)
Identify the document(s) which defines the formal processes for:

i. Testing of all network connections
ii. Approval of all network connections
iii. Testing of all firewall configuration changes
iv. Approval of all firewall configuration changes
v. Testing of all router configuration changes
vi. Approval of all router configuration changes
Describe how the documented processes were observed to be implemented, for:

i. Testing of all network connections
ii. Approval of all network connections 6
iii. Testing of all firewall configuration changes
iv. Approval of all firewall configuration changes
v. Testing of all router configuration changes
vi. Approval of all router configuration changes
Identify the current network diagram(s).
Describe how observed network connections confirm that the diagram:
i. Iscurrent
ii. Includes all connections to cardholder data
iii. Includes any wireless network connections
.Identify the document requiring that the network diagram is kept current.
Describe the documented process for keeping the network diagram current.
Identify the responsible personnel interviewed who confirm the documented 1
process is followed.
Identify the firewall configuration standards that define requirements for:

i. A firewall at each Internet connection
ii. A firewall between any DMZ and the internal network zone
2
.Identify the current network diagrams and firewall configuration standards

reviewed. 2
Describe how the reviewed documents were confirmed to be consistent with one
another.
Identify the firewall configuration standards that include descriptions of the
following for logical management of components:
i. Groups ii. Roles
iii. Responsibilities
Identify the router configuration standards that include descriptions of the
following for logical management of components:
i. Groups ii. Roles
iii. Responsibilities
Identify the personnel holding those roles and responsibilities who were 6
interviewed, and who confirm that the roles and responsibilities are assigned as
documented for:
i. Logical management of router components
ii. Logical management of firewall components
For each of the following identify the firewall configuration standards which
define those necessary for business, including a business justification for each:
Services
Protocols
Ports
For each of the following identify the router configuration standards which define
those necessary for business, including a business justification for each:
Services
Protocols
Ports
Identify whether any insecure services, protocols or ports are allowed. For each
insecure service, protocol and port allowed:
i. Identify the documented justification.
ii. Identify the responsible personnel interviewed who confirm that each insecure
service/protocol/port is necessary.
iii. Identify the firewall and router configuration standards which define the security
features
required for each insecure service/protocol/port.
iv. Describe how observed firewall configurations verify the security features are 2
implemented.
v. Describe how observed router configurations verify the security features are
implemented
Identify the firewall configuration standards that require a review of firewall rule
sets at least every six months.
Identify the router configuration standards that require a review of router rule sets
at least every six months.
6
Identify documented results of previous:
i. Firewall rule set reviews
ii. Router rule set reviews
Identify the responsible personnel interviewed who confirm that:
i.Firewall rule set reviews are completed at least every six months. Router rule set 6
reviews ii:are completed at least every six months.
Describe how observed firewall/router configurations limit traffic to that which is

necessary for the cardholder data environment:
i. Inbound ii. Outbound
Identify the document that defines the restrictions and confirm this is consistent
with the observed configurations:
Describe how inbound and outbound traffic was observed to be limited to that 2
which is necessary for the cardholder data environment:
Describe how firewall and router configuration were observed to specifically deny all
other traffic: inboud and outbound. 2
Describe how the router configuration files were observed to be secured
Describe how the router configuration files were observed to be synchronized.
2
Describe how firewalls were observed to be in place between any wireless networks
and systems that store cardholder data.
Describe how firewall configurations were observed to deny or control all traffic
from any wireless environment into the cardholder data environment.
Identify the responsible personnel interviewed who confirm that any permitted
traffic from the wireless environment into the cardholder data environment is
necessary for business purposes
Identify the document defining system components that provide authorized publicly
accessible services, protocols, and ports.
Describe how observed firewall/router configurations ensure that the DMZ limits
inbounds traffic to only those system components
Describe how observed firewall/router configurations limit inbound Internet traffic

to IP addresses within the DMZ.
Describe how inbound Internet traffic was observed to be limited to IP addresses
within the DMZ. 2
Identify the network documents/diagrams specifying that direct connections are not
allowed for traffic between the Internet and the cardholder data environment:
Describe how observed firewall/router configurations prevent direct connections
between the Internet and the cardholder data environment:
Describe how observed traffic between the Internet and the cardholder data 2
environment confirms that direct connections are not permitted:
Describe how observed firewall/router configurations prevent internal addresses

passing from the Internet into the DMZ.
Describe how observed traffic from the Internet into the DMZ confirms that
internal addresses cannot pass from the Internet into the DMZ.
Identify the document that explicitly defines authorized outbound traffic from the
cardholder data environment to the Internet.
Describe how firewall/router configurations were observed to allow only explicitly
authorized traffic.
Describe how observed outbound traffic from the cardholder data environment to
the Internet confirms that only explicitly authorized traffic is allowed.
Describe how observed firewall configurations implement stateful inspection.

Describe how observed network traffic confirms that stateful inspection is
implemented (that is,
only established connections are allowed into the network).
2
For all system components that store cardholder data:
Identify the diagrams and/or other document(s) which define how system
components are located on an internal network zone, segregated from the DMZ and
other untrusted networks.
Describe how observed network and system configurations confirm the system
components are located on an internal network zone, segregated from the DMZ and
other untrusted networks. 2
Describe how observed network traffic confirms that the system components are
located on an internal network zone, segregated from the DMZ and other untrusted
networks.
Identify the document defining methods to prevent the disclosure of private IP

addresses and routing information from internal networks to the Internet.
Briefly describe the methods in place.
Describe how observed firewall/router configurations prevent private IP addresses
and routing
information from being disclosed to the Internet. 2
Describe how observed network traffic confirms that private IP addresses and
routing information are not disclosed to the Internet.
Identify the documents that specifies whether any disclosure of private IP addresses
and routing information to external parties is permitted
For each permitted disclosure, identify the repsonsible personnel interviewed who
confirmed that disclosure is authorized
Describe how observed configurations ensure that any disclosure of private IP
addresses and routing information to external entities is authorized.
Identify whether mobile and/or employee-owned computers with direct connectivity

to the Internet are used to access the organizations network.
Identify the document requiring that mobile and/or employee-owned computers with
direct connectivity to the Internet have personal firewall software:
i. Installed ii. Active
Describe how personal firewall software was observed on mobile and/or employee- 2
owned computers to be:
i. Installed ii. Active
Identify the document defining personal firewall software configuration standards.
Describe how personal firewall software on mobile and/or employee-owned
computers was observed to be:
i. Configured by the organization to the documented configuration standards
ii. Not alterable by mobile and/or employee-owned computer users
2
74 0 0
d network.
ces. Often, seemingly insignificant paths to and from untrusted networks can provide unprotected pathways into key systems. Firewalls are a key protecti
sment of Requirement 1.
Merchant TYPES
C-VT C D In Place ? Severity in case of Proofs / Stage of implementation
non compliance Documentation links
1 N 6
1 N 6
1 N 1
1 N 1
1 N 2
1 N 2
1 N 6
1 Y 0
1 Y 0
1 Y 0
1 Y 0
1 1 1 Y 0
1 1 1 Y 0
1 1 1 Y 0
1 Y 0
1 1 1 Y 0
1 1 1 Y 0
1 Y 0
1 Y 0
1 1 1 Y 0
1 Y 0
1 1 1 Y 0
1 1 1 Y 0
1 Y 0
1 Y 0
1 Y 0
1 1 Y 0
1 1 Y 0
10 8 28 Y 24
N
C
ystems. Firewalls are a key protection mechanism for any computer network.
Remediation plan Estimated date for completion Comments

Owner
Name
Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters
Malicious individuals (external and internal to an entity) often use vendor default passwords and other vendor default settings to comprom
Major observations from the 2011 Verizon PCI Compliance Report

Up to 56 percent in compliance from 48 percent the year before.
The most significant change was the requirement to change vendor-supplied default passwords, which was up to 82 percent from 48 perc
Requirements 2.2.3b (secure system configuration) and 2.2.4 (remove unnecessary services) both remain low, at 74 percent and 67 percen
Almost all systems administrators profess to know how to configure a system to be secure (Requirement 2.2.3a), but when it comes down t
2.1 Always change vendor-supplied defaults before Malicious individuals (external and internal to a
installing a system on the network, including but not company) often use vendor default settings, account
limited to passwords, simple network management names, and passwords to compromise systems.
protocol (SNMP) community strings, and elimination These settings are well known in hacker
of unnecessary accounts. communities and leave your system highly
vulnerable to attack.
2.1.1 For wireless environments connected to the Many users install these devices without
cardholder data environment or transmitting management approval and do not change default
cardholder data, change wireless vendor defaults, settings or configure security settings. If wireless
including but not limited to default wireless networks are not implemented with sufficient
encryption keys, passwords, and SNMP security configurations (including changing default
community strings. settings), wireless sniffers can eavesdrop on the
traffic, easily capture data and passwords, and easily
enter and attack your network. In addition, the key
exchange protocol for the older version of 802.11x
encryption (WEP) has been broken and can render
the encryption useless. Verify that firmware for
devices are updated to support more secure
protocols (for example, WPA2).
2.2 Develop configuration standards for all system There are known weaknesses with many operating
components. Assure that these standards address all systems, databases, and enterprise applications, and
known security vulnerabilities and are consistent there are also known ways to configure these
with industry-accepted system hardening standards. systems to fix security vulnerabilities. To help those
that are not security experts, security organizations
Sources of industry-accepted system hardening have established system-hardening
standards may include, but are not limited to: recommendations, which advise how to correct
these weaknesses. If systems are left with these
- Center for Internet Security (CIS) weaknessesfor example, weak file settings or
- International Organization for Standardization (ISO) default services and protocols (for services or
- SysAdmin Audit Network Security (SANS) Institute protocols that are often not needed)an attacker
- National Institute of Standards Technology (NIST) will be able to use multiple, known exploits to attack
vulnerable services and protocols, and thereby gain
access to your organization's network. Source
websites where you can learn more about industry
best practices that can help you implement
configuration standards include, but are not limited
to: www.nist.gov, www.sans.org, www.cisecurity.org,
www.iso.org.
System configuration standards must also be kept up

to date to ensure that newly identified weaknesses
are corrected prior to a system being installed on
the network.
2.2.1 Implement only one primary function per This is intended to ensure your organization's
server to prevent functions that require different system configuration standards and related
security levels from co-existing on the same processes address server functions that need to
server. (For example, web servers, database have different security levels, or that may introduce
servers, and DNS should be implemented on security weaknesses to other functions on the same
separate servers.) server. For example:
Note: Where virtualization technologies are in 1. A database, which needs to have strong security
use, implement only one primary function per measures in place, would be at risk sharing a server
virtual system component. with a web application, which needs to be open and
directly face the Internet.
2. Failure to apply a patch to a seemingly minor

function could result in a compromise that impacts
other, more important functions (such as a
database) on the same server.
This requirement is meant for all servers within the

cardholder data environment (usually Unix, Linux, or
Windows based). This requirement may not apply to
server to prevent functions that require different system configuration standards and related
security levels from co-existing on the same processes address server functions that need to
server. (For example, web servers, database have different security levels, or that may introduce
servers, and DNS should be implemented on security weaknesses to other functions on the same
separate servers.) server. For example:
Note: Where virtualization technologies are in 1. A database, which needs to have strong security
use, implement only one primary function per measures in place, would be at risk sharing a server
virtual system component. with a web application, which needs to be open and
directly face the Internet.
2. Failure to apply a patch to a seemingly minor

function could result in a compromise that impacts
other, more important functions (such as a
database) on the same server.
This requirement is meant for all servers within the

cardholder data environment (usually Unix, Linux, or
Windows based). This requirement may not apply to
systems which have the ability to natively
implement security levels on a single server (e.g.
mainframe).
Where virtualization technologies are used, each

virtual component (e.g. virtual machine, virtual
switch, virtual security appliance, etc.) should be
considered a server boundary. Individual
hypervisors may support different functions, but a
single virtual machine should adhere to the one
primary function rule. Under this scenario,
compromise of the hypervisor could lead to the
compromise of all system functions. Consequently,
consideration should also be given to the risk level
when locating multiple functions or components on
a single physical system.
2.2.2 Enable only necessary and secure services, As stated in Requirement 1.1.5, there are many
protocols, daemons, etc., as required for the protocols that a business may need (or have
function of the system. Implement security enabled by default) that are commonly used by
features for any required services, protocols or malicious individuals to compromise a network. To
daemons that are considered to be insecurefor ensure that only the necessary services and
example, use secured technologies such as SSH, S- protocols are enabled and that all insecure services
FTP, SSL, or IPSec VPN to protect insecure services and protocols are adequately secured before new
such as NetBIOS, file-sharing, Telnet, FTP, etc. servers are deployed, this requirement should be
part of your organization's configuration standards
and related processes.
2.2.3 Configure system security parameters to This is intended to ensure your organizations system
prevent misuse. configuration standards and related processes
specifically address security settings and parameters
that have known security implications.
2.2.4 Remove all unnecessary functionality, such The server-hardening standards must include
as scripts, drivers, features, subsystems, file processes to address unnecessary functionality with
systems, and unnecessary web servers. specific security implications (like
removing/disabling FTP or the web server if the
server will not be performing those functions).
2.3 Encrypt all non-console administrative access If remote administration is not done with secure
using strong cryptography. Use technologies such as authentication and encrypted communications,
SSH, VPN, or SSL/TLS for webbased management sensitive administrative or operational level
and other nonconsole administrative access. information (like administrators passwords) can be
revealed to an eavesdropper. A malicious individual
could use this information to access the network,
become administrator, and steal data.
2.4 Shared hosting providers must protect each This is intended for hosting providers that provide
entitys hosted environment and cardholder data. shared hosting environments for multiple clients on
These providers must meet specific requirements as the same server. When all data is on the same
detailed in Appendix A: Additional PCI DSS server and under control of a single environment,
Requirements for Shared Hosting Providers. often the settings on these shared servers are not
manageable by individual clients, allow clients to
add insecure functions and scripts that impact the
security of all other client environments; and
thereby make it easy for a malicious individual to
compromise one client's data and thereby gain
access to all other clients' data.
d other security parameters
nd other vendor default settings to compromise systems. These passwords and settings are well known by hacker communities and are easily determine
ds, which was up to 82 percent from 48 percent.

oth remain low, at 74 percent and 67 percent respectively.
uirement 2.2.3a), but when it comes down to building and maintaining a system in a compliant manner (Requirement 2.2.3c), were still failing in over a

Top 20 Critical
Security Controls
C3.3 2.1 Choose a sample of system components, and attempt to log on (with system
C12.2 administrator help) to the devices using default vendor-supplied accounts and
passwords, to verify that default accounts and passwords have been changed. (Use
vendor manuals and sources on the Internet to find vendor-supplied
accounts/passwords.)
C11.5 2.1.1 Verify the following regarding vendor default settings for wireless
C7.1 environments:
2.1.1.a Verify encryption keys were changed from default at installation, and are
changed anytime anyone with knowledge of the keys leaves the company or
changes positions
2.1.1.b Verify default SNMP community strings on wireless devices were changed.
2.1.1.c Verify default passwords/passphrases on access points were changed.
2.1.1.d Verify firmware on wireless devices is updated to support strong encryption

for authentication and transmission over wireless networks.
2.1.1.e Verify other security-related wireless vendor defaults were changed, if

applicable.
C3.1 2.2.a Examine the organizations system configuration standards for all types of system
C3.2 components and verify the system configuration standards are consistent with
C3.3 industry-accepted hardening standards.
C10.1
2.2.b Verify that system configuration standards are updated as new vulnerability
issues are identified, as defined in Requirement 6.2.
2.2.c Verify that system configuration standards are applied when new systems are
configured.
2.2.d Verify that system configuration standards include each item below (2.2.1
2.2.4).
NC 2.2.1.a For a sample of system components, verify that only one primary function is
implemented per server.
2.2.1.b If virtualization technologies are used, verify that only one primary function
is implemented per virtual system component or device.
C3.3 2.2.2.a For a sample of system components, inspect enabled system services,
C10.1 daemons, and protocols. Verify that only necessary services or protocols are
enabled.
2.2.2.b Identify any enabled insecure services, daemons, or protocols. Verify they
are justified and that security features are documented and implemented.
C3.3 2.2.3.a Interview system administrators and/or security managers to verify that they
C10.6 have knowledge of common security parameter settings for system components.
2.2.3.b Verify that common security parameter settings are included in the system
configuration standards.
2.2.3.c For a sample of system components, verify that common security
parameters are set appropriately.
C3.3 2.2.4.a For a sample of system components, verify that all unnecessary functionality
(for example, scripts, drivers, features, subsystems, file systems, etc.) is removed.
2.2.4.b Verify enabled functions are documented and support secure configuration.
2.2.4.c Verify that only documented functionality is present on the sampled system
components.
C10.6 2.3 For a sample of system components, verify that non-console administrative access
is encrypted by performing the following:
2.3.a Observe an administrator log on to each system to verify that a strong encryption
method is invoked before the administrators password is requested.
2.3.b Review services and parameter files on systems to determine that Telnet and
other remote login commands are not available for use internally.
2.3.c Verify that administrator access to the web-based management interfaces is

encrypted with strong cryptography.
NC 2.4 Perform testing procedures A.1.1 through A.1.4 detailed in Appendix A: Additional
PCI DSS Requirements for Shared Hosting Providers for PCI DSS assessments of shared
hosting providers, to verify that shared hosting providers protect their entities
(merchants and service providers) hosted environment and data.
communities and are easily determined via public information.
ment 2.2.3c), were still failing in over a quarter of all cases.
Validation Instructions for QSA/ISA Priority A B C-VT C

Identify the sample of system components observed. 1 1

For each sampled system component, describe how attempts to log on using vendor-
supplied accounts and passwords confirm that all default accounts and passwords are
changed before installing a system on the network. 2
1 1
Identify the document requiring that wireless encryption keys must be changed: i. 1 1
From default at installation
ii. Anytime anyone with knowledge of the keys leaves the organization or changes
positions
Identify the responsible personnel interviewed who confirm the documented
processes for changing keys are followed:
i. At installation
ii. Anytime anyone with knowledge of the keys leaves the organization or changes 2
positions
Describe how observed wireless configurations confirm that key changes are
completed as required.
Identify the document requiring that default SNMP community strings must be 1 1
changed. 2
Describe how observed wireless configurations confirm that default SNMP
community strings are changed.
Identify the document requiring that default passwords/passphrases on access 1 1
points must be changed.
Describe how observed wireless configurations confirm that default 2
passwords/passphrases are changed.
Identify the document requiring that firmware on wireless devices must be updated 1 1
to support encryption for authentification and transmission
Describe how observed wireless configurations confirm that firware is updated to 2
support strong encryption for authnetification and transmission.
Identify the document that defines any other security-related wireless vendor 1 1
defaults.
Describe how the observed wireless configurations confirm that other security- 2
related vendor
defaults are changed, as applicable.
Identify the documented system configuration standards
Describe how the configuration standards were confirmed to:
i. Cover all types of system components
ii. Address all known security vulnerabilities
iii. Be consistent with industry-accepted system hardening standards Identify the 3
industry-accepted hardening standards.
Describe the process for updating system configuration standards as new vulnerability
issues are identified.
Identify the responsible personnel interviewed who confirm that the process is
followed.
Describe how the process was observed to be implemented. 3
Describe how the reviewed system configuration standards were confirmed to be
updated with new vulnerability issues.
Identify the document defining the process for applying system configuration
standards to new systems.
Describe how observed system configurations confirm the configuration standards 3
are applied.
Describe how it was observed that configuration standards are applied when new
systems are configured.
Identify the system configuration standards requiring that:
i. Only one primary function is implemented per server, including virtual system
components
or devices, as applicable.
ii. Only necessary services or protocols are enabled and security features are
implemented for any required services, protocols or daemons considered insecure. 3
iii. System security parameters are configured to prevent misuse.
iv. All unnecessary functionality (for example, scripts, drivers, features, subsystems, file
systems, etc.) is removed.
Identify the sample of system components observed.

For each sampled system component, describe how observed system
configurations confirm
that only one primary function per server is implemented. 3
Identify personnel interviewed and describe how systems were observed to
determine whether virtualization technologies are used.
If virtualization technologies are used:
Identify the functions for which virtualization technologies are used.
Identify the sample of virtual system components or devices observed.
For each sampled virtual system component and device, describe how the observed
configurations confirm only one primary function is implemented per virtual system
component or device.
Identify the sample of system components observed. For each sampled system 1 1
component:
Describe how system configurations were inspected to identify all enabled: o
Services
o Daemons
o Protocols
Identify the document specifying that each enabled service, daemon and protocol is 3
necessary for that system component.
From the sample of system components observed in 2.2.2.a, identify if any insecure
services, daemons, or protocols are enabled.
For each insecure service, daemon, or protocol identified:
i. Briefly describe why it is considered to be insecure.
ii. Identify the documented business justification.
iii. Identify the document defining security features for the insecure service,
daemon or 3
protocol.
iv. Describe how the observed system configurations confirm that security features
are
implemented in accordance with documentation.
Identify the systems administrators, security managers and other responsible
personnel interviewed.
Describe how each person interviewed demonstrated they have knowledge of 3
common security parameter settings for the system components that they
configure.
Identify the system configuration standards that define the common security
parameter 3
settings.
For each sampled system component, describe how common security parameters 3
were observed to be set according to the documented system configuration
standards.
For each sampled system component, describe how it was observed that all
unnecessary
functionality is removed. 3
For each sampled system component:

i. Identify the document defining the authorized functions that are allowed to be
enabled.
ii. Describe how enabled functions were identified on each system component. 3
iii. Confirm that all observed enabled functions are documented.
iv. Describe how the enabled functions were observed to support secure
configuration.
For each sampled system component, describe how documentation and observed
system configurations were compared to confirm that only documented 3
functionality is present on the system components.
Identify the sample of system components observed For each sampled system 1
component:
i. Identify the strong encryption method used for non-console administrative access.
ii. Describe how strong encryption was observed to be invoked before the 2
administrator
password is requested.
For each sampled system component, describe how the observed services and 1
parameter files confirm that the following are not available for use internally: 2
Telnett and other remote-login command
For each sampled system component: 1

i. Describe how administrator access to web-based management interfaces is
configured to
require strong cryptography. 2
ii. Describe how administrator access to the web-based management interfaces was
observed to confirm that all such access is encrypted with strong cryptography.
Identify whether the assessed entity is a shared hosting provider.
If the entity is a shared hosting provider, identify here that Appendix A: Additional
PCI DSS
Requirements for Shared Hosting Providers has been completed and is included in the
ROC.
67 0 0 8 12
D In place? Severity Proofs / Documentation links Stage of implementation
1 N 2
1 N 2
1 N 2
1 N 2
1 N 2
1 N 2
1 N 2
1 N 3
1 N 3
1 N 3
1 N 3
1 N 3
1 N 3
1 N 3
1 N 3
1 N 3
1 N 3
1 N 3
1 N 3
1 N 3
1 N 3
1 N 2
1 N 2
1 N 2
1 N 2
1 N 3
26 Y 67
N
C
Remediation plan Estimated date for completion Comments Owner
Requirement 3: Protect stored cardholder data
Protection methods such as encryption, truncation, masking, and hashing are critical components of cardholder data protection. If an intru
cardholder data if full PAN is not needed, and not sending unprotected PANs using end-user messaging technologies, such as e-mail and in
Please refer to the PCI DSS and PA-DSS Glossary of Terms, Abbreviations, and Acronyms for definitions of strong cryptography and other
Major observations from the 2011 Verizon PCI Compliance report

Keeping stored cardholder data to a minimum seems to be a particularly difficult task for many companies.
Organizations rarely adhere to their retention policy
33 percent of businesses were unable to meet with Requirement 3.1
Requirement 3.4, encrypt cardholder data, is met only 63 percent of the time.
Requirement 3.6.4 is met in only 61 percent of cases,
3.1 Keep cardholder data storage to a minimum by A formal data retention policy identifies what data
implementing data retention and disposal policies, needs to be retained, and where that data resides
procedures and processes, as follows. so it can be securely destroyed or deleted as soon as
it is no longer needed. In order to define
appropriate retention requirements, an entity first
needs to understand their own business needs as
well as any legal or regulatory obligations that apply
to their industry, and/or that apply to the type of
data being retained.
Extended storage of cardholder data that exceeds

business need creates an unnecessary risk. The only
cardholder data that may be stored after
authorization is the primary account number or PAN
(rendered unreadable), expiration date, cardholder
name, and service code.
Implementing secure deletion methods ensure that

the data cannot be retrieved when it is no longer
needed
3.1.1 Implement a data retention and disposal

policy that includes:
- Limiting data storage amount and retention time

to that which is required for legal, regulatory, and
business requirements
- Processes for secure deletion of data when no
longer needed
- Specific retention requirements for cardholder
data
- A quarterly automatic or manual process for
identifying and securely deleting stored cardholder
data that exceeds defined retention requirements
identifying and securely deleting stored cardholder
data that exceeds defined retention requirements
3.2 Do not store sensitive authentication data after Sensitive authentication data consists of magnetic
authorization (even if encrypted). stripe (or track) data6, card validation code or
Sensitive authentication data includes the data as value7, and PIN data8. Storage of sensitive
cited in the following Requirements 3.2.1 through authentication data after authorization is
3.2.3: prohibited! This data is very valuable to malicious
individuals as it allows them to generate counterfeit
Note: It is permissible for issuers and companies that payment cards and create fraudulent transactions.
support issuing services to store sensitive See PCI DSS and PA-DSS Glossary of Terms,
authentication data if there is a business justification Abbreviations, and Acronyms for the full definition
and the data is stored securely. of sensitive authentication data.
Note: It is allowable for companies that perform,

facilitate, or support issuing services to store
sensitive authentication data ONLY IF they have a
legitimate business need to store such data. It
should be noted that all PCI DSS requirements apply
to issuers, and the only exception for issuers and
issuer processors is that sensitive authentication
data may be retained if there is a legitimate reason
to do so. A legitimate reason is one that is necessary
for the performance of the function being provided
for the issuer and not one of convenience.
Any such data must be stored securely and in

accordance with PCI DSS and specific payment
brand requirements.
3.2.1 Do not store the full contents of any track If full track data is stored, malicious individuals who
(from the magnetic stripe located on the back of a obtain that data can reproduce and sell payment
card, equivalent data contained on a chip, or cards.
elsewhere). This data is alternatively called full
track, track, track 1, track 2, and magnetic-stripe
data.
Note: In the normal course of business, the

following data elements from the magnetic stripe
may need to be retained:
- The cardholders name

- Primary account number (PAN)
- Expiration date
- Service code
To minimize risk, store only these data elements as

needed for business.
3.2.2 Do not store the card verification code or The purpose of the card validation code is to protect
value (three-digit or four-digit number printed on "card-not-present" transactionsInternet or mail
the front or back of a payment card) used to order/telephone order (MO/TO) transactions
verify card-notpresent transactions. where the consumer and the card are not present.
These types of transactions can be authenticated as
coming from the card owner only by requesting this
card validation code, since the card owner has the
card in-hand and can read the value. If this
prohibited data is stored and subsequently stolen,
malicious individuals can execute fraudulent
Internet and MO/TO transactions.
3.2.3 Do not store the personal identification These values should be known only to the card
number (PIN) or the encrypted PIN block. owner or bank that issued the card. If this
prohibited data is stored and subsequently stolen,
malicious individuals can execute fraudulent PIN-
based debit transactions (for example, ATM
withdrawals).
3.3 Mask PAN when displayed (the first six and last
four digits are the maximum number of digits to be The display of full PAN on items such as computer
displayed). screens, payment card receipts, faxes, or paper
reports can result in this data being obtained by
Notes: unauthorized individuals and used fraudulently. The
- This requirement does not apply to employees and PAN can be displayed in full form on the merchant
other parties with a legitimate business need to see copy receipts; however the paper receipts should
the full PAN. adhere to the same security requirements as
- This requirement does not supersede stricter electronic copies and follow the guidelines of the
requirements in place for displays of cardholder data PCI Data Security Standard, especially Requirement
for example, for point-of-sale (POS) receipts. 9 regarding physical security. The full PAN can also
be displayed for those with a legitimate business
need to see the full PAN.
This requirement relates to protection of PAN

displayed on screens, paper receipts, etc., and is not
to be confused with Requirement 3.4 for protection
of PAN when stored in files, databases, etc.
3.4 Render PAN unreadable anywhere it is stored Lack of protection of PANs can allow malicious
(including on portable digital media, backup media, individuals to view or download this data. PANs
and in logs) by using any of the following stored in primary storage (databases, or flat files
approaches: such as text files spreadsheets) as well as non-
primary storage (backup, audit logs, exception or
- One-way hashes based on strong cryptography troubleshooting logs) must all be protected. Damage
(hash must be of the entire PAN) from theft or loss of backup tapes during transport
- Truncation (hashing cannot be used to replace the can be reduced by ensuring PANs are rendered
truncated segment of PAN) unreadable via encryption, truncation, or hashing.
- Index tokens and pads (pads must be securely Since audit, troubleshooting, and exception logs
stored) have to be retained, you can prevent disclosure of
- Strong cryptography with associated key- data in logs by rendering PANs unreadable (or
management processes and procedures removing them) in logs.
Note: It is a relatively trivial effort for a By correlating hashed and truncated versions of a
malicious individual to reconstruct original given PAN, a malicious individual may easily derive
PAN data if they have access to both the the original PAN value. Controls that prevent the
truncated and hashed version of a PAN. correlation of this data will help ensure that the
Where hashed and truncated versions of original PAN remains unreadable.
the same PAN are present in an entitys
environment, additional controls should Please refer to the PCI DSS and PA-DSS Glossary of
be in place to ensure that the hashed and Terms, Abbreviations, and Acronyms for definitions
truncated versions cannot be correlated of strong cryptography.
to reconstruct the original PAN.
3.4.1 If disk encryption is used (rather than file- or The intent of this requirement is to address the
column-level database encryption), logical access acceptability of disk encryption for rendering
must be managed independently of native cardholder data unreadable. Disk encryption
operating system access control mechanisms (for encrypts data stored on a computer's mass storage
example, by not using local user account and automatically decrypts the information when an
databases). Decryption keys must not be tied to authorized user requests it. Disk-encryption systems
user accounts. intercept operating system read and write
operations and carry out the appropriate
cryptographic transformations without any special
action by the user other than supplying a password
or pass phrase at the beginning of a session. Based
on these characteristics of disk encryption, to be
compliant with this requirement, the disk-
encryption method cannot have:
1) A direct association with the operating system, or

2) Decryption keys that are associated with user
accounts.
3.5 Protect any keys used to secure cardholder data Cryptographic keys must be strongly protected
against disclosure and misuse: because those who obtain access will be able to
decrypt data. Key-encrypting keys, if used, must be
Note: This requirement also applies to key- at least as strong as the data-encrypting key in order
encrypting keys used to protect dataencrypting keys to ensure proper protection of the key that encrypts
such key-encrypting keys must be at least as the data as well as the data encrypted with that key.
strong as the data-encrypting key.
The requirement to protect keys from disclosure and
misuse applies to both data- encrypting keys and
key-encrypting keys. Because one key-encrypting key
may grant access to many data-encrypting keys, the
key-encrypting keys require strong protection
measures. Methods for secure storage of key-
encrypting keys include but are not limited to
hardware security modules (HSMs) and tamper
evident storage with dual control and split
knowledge.
3.5.1 Restrict access to cryptographic keys to the There should be very few who have access to
fewest number of custodians necessary. cryptographic keys, usually only those who have key
custodian responsibilities.
3.5.2 Store cryptographic keys securely in the fewest Cryptographic keys must be stored securely, usually
possible locations and forms. encrypted with key-encrypting keys, and stored in
very few locations. It is not intended that the key-
encrypting keys be encrypted, however they are to
be protected against disclosure and misuse as
defined in Requirement 3.5. Storing key-encrypting
keys in physically and/or logically separate locations
from data-encrypting keys reduces the risk of
unauthorized access to both keys.
3.5.2 Store cryptographic keys securely in the fewest Cryptographic keys must be stored securely, usually
possible locations and forms. encrypted with key-encrypting keys, and stored in
very few locations. It is not intended that the key-
encrypting keys be encrypted, however they are to
be protected against disclosure and misuse as
defined in Requirement 3.5. Storing key-encrypting
keys in physically and/or logically separate locations
from data-encrypting keys reduces the risk of
unauthorized access to both keys.
3.6 Fully document and implement all key- The manner in which cryptographic keys are
management processes and procedures for managed is a critical part of the continued security
cryptographic keys used for encryption of of the encryption solution. A good key management
cardholder data, including the following: process, whether it is manual or automated as part
of the encryption product, is based on industry
Note: Numerous industry standards for key standards and addresses all key elements at 3.6.1
management are available from various resources through 3.6.8.
including NIST, which can be found at
http://csrc.nist.gov.
3.6.1 Generation of strong cryptographic keys The encryption solution must generate strong keys,
as defined in the PCI DSS and PA-DSS Glossary of
Terms, Abbreviations, and Acronyms under "strong
cryptography."
3.6.2 Secure cryptographic key distribution The encryption solution must distribute keys
securely, meaning the keys are not distributed in the
clear, and only to custodians identified in 3.5.1.
3.6.3 Secure cryptographic key storage The encryption solution must store keys securely,
meaning the keys are not stored in the clear
(encrypt them with a key-encryption key).
3.6.4 Cryptographic key changes for keys that A cryptoperiod is the time span during which a
have reached the end of their cryptoperiod (for particular cryptographic key can be used for its
example, after a defined period of time has defined purpose. Considerations for defining the
passed and/or after a certain amount of cryptoperiod include, but are not limited to, the
ciphertext has been produced by a given key), as strength of the underlying algorithm, size or length
defined by the associated application vendor or of the key, risk of key compromise, and the
key owner, and based on industry best practices sensitivity of the data being encrypted.
and guidelines (for example, NIST Special Periodic changing of encryption keys when the keys
Publication 800-57). have reached the end of their cryptoperiod is
imperative to minimize the risk of someones
obtaining the encryption keys, and being able to
decrypt data.
If provided by encryption application vendor, follow
the vendors documented processes or
recommendations for periodic changing of keys. The
designated key owner or custodian can also refer to
industry best practices on cryptographic algorithms
and key management, for example NIST Special
Publication 800-57, for guidance on the appropriate
cryptoperiod for different algorithms and key
lengths.
The intent of this requirement applies to keys used
to encrypt stored cardholder data, and any
respective key-encrypting keys.
3.6.5 Retirement or replacement (for example, Old keys that are no longer used or needed should
archiving, destruction, and/or revocation) of keys be retired and destroyed to ensure that the keys can
as deemed necessary when the integrity of the no longer be used. If old keys need to be kept (to
key has been weakened (for example, departure support archived, encrypted data, for example) they
of an employee with knowledge of a clear-text should be strongly protected. (See 3.6.6 below.) The
key), or keys are suspected of being encryption solution should also allow for and
compromised. facilitate a process to replace keys that are known to
be, or suspected of being, compromised.
Note: If retired or replaced cryptographic keys
need to be retained, these keys must be securely
archived (for example, by using a key encryption
key). Archived cryptographic keys should only be
used for decryption/verification purposes.
3.6.6 If manual clear-text cryptographic key Split knowledge and dual control of keys are used to
management operations are used, these eliminate the possibility of one persons having
operations must be managed using split access to the whole key. This control is applicable for
knowledge and dual control (for example, manual key management operations, or where key
requiring two or three people, each knowing only management is not implemented by the encryption
their own key component, to reconstruct the product.
whole key).
Note: Examples of manual key management

operations include, but are not limited to: key
generation, transmission, loading, storage and
destruction.
3.6.7 Prevention of unauthorized substitution of The encryption solution should not allow for or
cryptographic keys. accept substitution of keys coming from
unauthorized sources or unexpected processes.
3.6.8 Requirement for cryptographic key This process will ensure individuals that act as key
custodians to formally acknowledge that they custodians commit to the key- custodian role and
understand and accept their key-custodian understand the responsibilities.
responsibilities.
nts of cardholder data protection. If an intruder circumvents other security controls and gains access to encrypted data, without the proper cryptograph
essaging technologies, such as e-mail and instant messaging.
finitions of strong cryptography and other PCI DSS terms.
companies.

Top 20 Critical
Security Controls
NC 3.1 Obtain and examine the policies, procedures and processes for data retention and
disposal, and perform the following:
NC 3.1.1.a Verify that policies and procedures are implemented and include legal,
regulatory, and business requirements for data retention, including specific
requirements for retention of cardholder data (for example, cardholder data needs
to be held for X period for Y business reasons).
3.1.1.b Verify that policies and procedures include provisions for secure disposal of
data when no longer needed for legal, regulatory, or business reasons, including
disposal of cardholder data.
3.1.1.c Verify that policies and procedures include coverage for all storage of
cardholder data.
3.1.1.d Verify that policies and procedures include at least one of the following:
- A programmatic process (automatic or manual) to remove, at least quarterly,

stored cardholder data that exceeds requirements defined in the data retention
policy
- Requirements for a review, conducted at least quarterly, to verify that stored
cardholder data does not exceed requirements defined in the data retention policy.
3.1.1.e For a sample of system components that store cardholder data, verify that
the data stored does not exceed the requirements defined in the data retention
policy.
NA 3.2.a For issuers and/or companies that support issuing services and store sensitive
authentication data, verify there is a business justification for the storage of sensitive
authentication data, and that the data is secured.
3.2.b For all other entities, if sensitive authentication data is received and deleted,
obtain and review the processes for securely deleting the data to verify that the data is
unrecoverable.
3.2.c For each item of sensitive authentication data below, perform the following
steps:
NA 3.2.1 For a sample of system components, examine data sources, including but not
limited to the following, and verify that the full contents of any track from the
magnetic stripe on the back of card or equivalent data on a chip are not stored
under any circumstance:
- Incoming transaction data

- All logs (for example, transaction, history, debugging, error)
- History files
- Trace files
- Several database schemas
- Database contents
limited to the following, and verify that the threedigit or four-digit card verification
code or value printed on the front of the card or the signature panel (CVV2, CVC2,
CID, CAV2 data) is not stored under any circumstance:

- History files
- Trace files
- Database contents
limited to the following and verify that PINs and encrypted PIN blocks are not stored
under any circumstance:

- History files
- Trace files
- Database contents
NA 3.3 Obtain and examine written policies and examine displays of PAN (for example, on
screen, on paper receipts) to verify that primary account numbers (PANs) are masked
when displaying cardholder data, except for those with a legitimate business need to
see full PAN.
C17.7 3.4.a Obtain and examine documentation about the system used to protect the PAN,
C8.4 including the vendor, type of system/process, and the encryption algorithms (if
applicable). Verify that the PAN is rendered unreadable using any of the following
methods:
- One-way hashes based on strong cryptography

- Truncation
- Index tokens and pads, with the pads being securely stored
- Strong cryptography, with associated key-management processes and procedures
3.4.b Examine several tables or files from a sample of data repositories to verify the
PAN is rendered unreadable (that is, not stored in plain-text).
3.4.c Examine a sample of removable media (for example, back-up tapes) to confirm
that the PAN is rendered unreadable.
3.4.d Examine a sample of audit logs to confirm that the PAN is rendered unreadable
or removed from the logs.
NC 3.4.1.a If disk encryption is used, verify that logical access to encrypted file systems
is implemented via a mechanism that is separate from the native operating systems
mechanism (for example, not using local user account databases).
3.4.1.b Verify that cryptographic keys are stored securely (for example, stored on
removable media that is adequately protected with strong access controls).
3.4.1.c Verify that cardholder data on removable media is encrypted wherever
stored.
Note: If disk encryption is not used to encrypt removable media, the data stored on
this media will need to be rendered unreadable through some other method.
NC 3.5 Verify processes to protect keys used for encryption of cardholder data against
disclosure and misuse by performing the following:
NC 3.5.1 Examine user access lists to verify that access to keys is restricted to the fewest
number of custodians necessary.
NC 3.5.2.a Examine system configuration files to verify that keys are stored in encrypted
format and that key-encrypting keys are stored separately from data-encrypting
keys.
3.5.2.b Identify key storage locations to verify that keys are stored in the fewest
possible locations and forms.
NC 3.6.a Verify the existence of key-management procedures for keys used for encryption
of cardholder data.
3.6.b For service providers only: If the service provider shares keys with their
customers for transmission or storage of cardholder data, verify that the service
provider provides documentation to customers that includes guidance on how to
securely transmit, store and update customers keys, in accordance with Requirements
3.6.1 through 3.6.8 below.
3.6.c Examine the key-management procedures and perform the following:
NC 3.6.1 Verify that key-management procedures are implemented to require the

generation of strong keys.
NC 3.6.2 Verify that key-management procedures are implemented to require secure

key distribution.
NC 3.6.3 Verify that key-management procedures are implemented to require secure

key storage.
NC 3.6.4 Verify that key-management procedures are implemented to require periodic
key changes at the end of the defined cryptoperiod.
NC 3.6.5.a Verify that key-management procedures are implemented to require the

retirement of keys when the integrity of the key has been weakened.
3.6.5.b Verify that the key-management procedures are implemented to require the
replacement of known or suspected compromised keys.
3.6.5.c If retired or replaced cryptographic keys are retained, verify that these keys
are not used for encryption operations.
NC 3.6.6 Verify that manual clear-text key-management procedures require split

knowledge and dual control of keys.
NC 3.6.7 Verify that key-management procedures are implemented to require the
prevention of unauthorized substitution of keys.
NC 3.6.8 Verify that key-management procedures are implemented to require key

custodians to acknowledge (in writing or electronically) that they understand and
accept their key-custodian responsibilities.
ted data, without the proper cryptographic keys, the data is unreadable and unusable to that person. Other effective methods of protecting stored data
Validation Instructions for QSA/ISA Priority A B C-VT

1 ###
Identify the documented policies and procedures that: 1 ###

i. Define the legal, regulatory, and business requirements for data retention
ii. Specifically address retention requirements for cardholder data Identify the
responsible personnel interviewed who confirm:
i. The legal, regulatory, and business requirements that retention requirements are
based on
ii. That the documented policies and procedures for data retention are implemented
Identify the documented policies and procedures which define processes for secure 1 ###
disposal of data when no longer needed for legal, regulatory, or business reasons,
including disposal of cardholder data.
Briefly describe the implemented processes.
Describe how the documented policies and procedures were verified to include 1 ###
coverage for all storage of cardholder data.
Identify the documented policies and procedures that: 1 ###
i. Define processes for ensuring that stored cardholder data does not exceed
requirements defined in the data retention policy
ii. Require that the processes be performed at least quarterly
Describe the implemented processes (may be a programmatic process, requirements
for a review, or a combination of both).
Identify the sample of system components that store cardholder data. 1 ###
For each sampled system component, describe how it was observed that data stored
does not exceed the requirements of data retention and disposal policy.
Identify whether the assessed entity is an issuer or supports issuing services. If the 1 ###
assessed entity is an issuer or supports issuing services:
i. Identify and describe the business justification for storing sensitive authentication
data.
ii. Identify the responsible personnel interviewed who confirm the business
justification.
iii. Describe how the data was observed to be secured.
For all instances where sensitive authentication data is received and deleted: 1 ### 1
i. Identify the document defining the processes for securely deleting sensitive
authentication
data.
ii. Describe how the processes for securely deleting the data were verified to render
the data unrecoverable.
1 ### 1
Identify the sample of system components observed. 1 ### 1
For each sampled system component, identify the observed data sources, including:
i. Incoming transaction data
ii. All logs (for example, transaction, history, debugging, error)
iii. History files iv. Trace files
v. Several database schemas vi. Database contents
vii. Any other data sources in scope
For each sampled system component and data source, describe how observation of
the data sources confirms that full track data is not stored under any circumstance.
Identify the sample of system components observed. 1 ### 1 1

the data sources confirms that card verification codes or values (CVV2, CVC2, CID,
CAV2) are not stored under any circumstance.
Identify the sample of system components observed. 1 ### 1

the data sources confirms that PINs or encrypted PIN blocks are not stored under any
circumstance.
Identify all instances where primary account numbers (PAN) is displayed. 5 ### 1 1
Identify the document that:
i. Requires PAN is masked when displayed, except for those with a legitimate business
need to see full PAN.
ii. Identifies those with a legitimate business need to see full PAN
For all instances where PAN is displayed, describe how PAN was observed to be
masked, except where there is a legitimate business need to view the full PAN.
Identify all instances where PAN is stored (including system components, 5 ###
portable digital media, backup media, and in logs).
For each instance of stored PAN:
i. Identify the documents describing the methods for protecting the PAN.
ii. Briefly describe the implemented methodsincluding the vendor, type of
system/process, and the encryption algorithms (if applicable)used to protect
the PAN.
iii. Describe how the implemented methods render the PAN unreadable using
any of the following defined methods:
o One-way hashes based on strong cryptography
o Truncation
o Index tokens and pads, with the pads being securely stored
o Strong cryptography, with associated key-management processes and
procedures
Identify the sample of data repositories observed. 5 ###

Identify the tables or files examined within each sampled data repository.
For each table or file examined from each sampled data repository, describe
how the observed data confirms PAN is rendered unreadable.
Identify the sample of removable media observed. 5 ###

For each item in the sample, describe how PAN was observed to be rendered
unreadable.
Identify the sample of audit logs observed. 5 ###

For each item in the sample, describe how PAN was observed to be rendered
unreadable or removed.
Identify whether disk encryption is used. If disk encryption is used: 5 ###
i. Describe the observed disk encryption mechanisms in use.
ii. For each disk encryption mechanism in use, describe how the disk
encryption mechanism was observed to be separate from the native operating
systems mechanism (that is, logical access to the encrypted file system is
managed independently of the native operating system access controls)
If disk encryption is used, describe how cryptographic keys were observed to 5 ###
be stored securely.
If disk encryption is used, describe how cardholder data on removable media 5 ###
was observed to be encrypted wherever stored.
5 ###
Identify observed user access lists for cryptographic key storage. 5 ###
For each key storage location, describe how observed user access lists
confirm that access to keys is restricted to the fewest number of custodians
necessary.
Describe how system configuration files were observed to confirm that: i. 5 ###
Keysarestoredinencryptedform.
ii. Key-encrypting keys are stored separately from data encrypting keys.
Identify all locations where keys are stored. 5 ###
Describe how the observed locations confirm that keys are stored in the fewest
possible
locations and forms.
Identify the documents defining key-management procedures for keys used for 5 ###
encryption of cardholder data.
If the entity being assessed is a service provider: 5 ###

Identify whether the service provider shares keys with their customers for
transmission or storage of cardholder data.
If keys are shared with customers:
i. Identify the document providing customers guidance on how to securely transmit,
store, and update customers keys in accordance with Requirements 3.6.1 through
3.6.8
ii. Describe how the document was observed to be provided to customers.
5 ###
Identify the document that defines procedures for the generation of strong keys. 5 ###
Describe how the procedures for the generation of strong keys were observed to be
implemented.
Identify the document that defines procedures for secure key distribution. 5 ###
Describe how the procedures for secure key distribution were observed to be
implemented.
Identify the document that defines procedures for secure key storage. 5 ###
Describe how the procedures for secure key storage were observed to be
implemented.
Identify the document that defines: 5 ###
i. Key cryptoperiod(s)
ii. The procedures for periodic key changes at the end of the defined cryptoperiod(s)
Describe how the procedures for periodic key changes at the end of the defined
cryptoperiod(s) were observed to be implemented.
Identify the document that defines procedures for the retirement of keys when the 5 ###
integrity of the key has been weakened (for example, departure of an employee with
knowledge of a clear- text key).
Describe how the procedures for retirement of keys when the integrity of the key has
been weakened were observed to be implemented.
Identify the document that defines procedures for the replacement of known or 5 ###
suspected compromised keys.
Describe how the procedures for replacement of known or suspected compromised
keys were observed to be implemented.
Identify whether retired or replaced cryptographic keys are retained. If retired or 5 ###
replaced cryptographic keys are retained:
i. Identifythedocumentwhichrequiresthatthesekeys: o Are securely archived
o Are not used for encryption operations
ii. Describehowthekeyswereobservedtobe: o Securely archived
o Not used for encryption operations
dentify whether manual clear-text cryptographic key management operations are 5 ###
used. If manual clear-text cryptographic key management operations are used:
Identify the document that defines procedures requiring: o Split knowledge of keys
o Dual control of keys
Describe how the following procedures were observed to be implemented for manual
clear-text cryptographic key operations:
o Split knowledge of keys o Dual control of keys
Identify the document that defines procedures for prevention of unauthorized 5 ###
substitution of keys.
Describe how the procedures for the prevention of unauthorized substitution of keys
were observed to be implemented.
Identify the document that defines procedures for key custodians to acknowledge that 5 ###
they understand and accept their key-custodian responsibilities.
Describe how key custodian acknowledgements were observed to be implemented.
Identify the key custodians interviewed who confirm that they understand and
accept their key-custodian responsibilities.
137 ###0 6 2
ds of protecting stored data should be considered as potential risk mitigation opportunities. For example, methods for minimizing risk include not storin
C D In Place ? Severity Proofs / Stage of implementation

Documentation links
1 Y 0
1 Y 0
1 N 1
1 N 1
1 N 1
1 N 1
1 N 1
1 1 N 1
1 1 N 1
1 1 N 1
1 1 N 1
1 1 N 1
1 1 N 5
1 N 5
1 N 5
1 N 5
1 N 5
1 N 5
1 N 5
1 N 5
1 N 5
1 N 5
1 N 5
1 N 5
1 N 5
1 N 5
1 N 5
1 N 5
1 N 5
1 N 5
1 N 5
1 N 5
1 N 5
1 N 5
1 N 5
1 N 5
1 N 5
6 37 Y 135
N
C
ethods for minimizing risk include not storing cardholder data unless absolutely necessary, truncating
Name 1
Requirement 4: Encrypt transmission of cardholder data across open, public networks
Sensitive information must be encrypted during transmission over networks that are easily accessed by malicious individuals. Misconfigure
Major observations from the 2011 Verizon PCI Compliance Report:

Compliance with Requirement 4 increased from 63 percent to 72 percent.
83% of business comply with 4.2
Many businesses have segmented their wireless networks and no longer allow any PCI- regulated traffic containing sensitive cardholder da
4.1 Use strong cryptography and security protocols Sensitive information must be encrypted during
(for example, SSL/TLS, IPSEC, SSH, etc.) to safeguard transmission over public networks, because it is easy
sensitive cardholder data during transmission over and common for a malicious individual to intercept
open, public networks. and/or divert data while in transit.
Examples of open, public networks that are in scope For example, Secure Sockets Layer (SSL) encrypts
of the PCI DSS include but are not limited to: web pages and the data entered into them. When
using SSL secured websites, ensure https is part of
- The Internet the URL.
- Wireless technologies,
- Global System for Mobile communications (GSM) Note that some protocol implementations (such as
- General Packet Radio Service (GPRS). SSL version 2.0 and SSH version 1.0) have
documented vulnerabilities, such as buffer
overflows, that an attacker can use to gain control of
the affected system. Whichever security protocol is
used, ensure it is configured to use only secure
configurations and versions to prevent an insecure
connection being used.
4.1.1 Ensure wireless networks transmitting Malicious users use free and widely available
cardholder data or connected to the cardholder tools to eavesdrop on wireless communications.
data environment, use industry best practices (for Use of strong cryptography can limit disclosure of
example, IEEE 802.11i) to implement strong sensitive information across the network. Many
encryption for authentication and transmission. known compromises of cardholder data stored
only in the wired network originated when a
Note: The use of WEP as a security control was malicious user expanded access from an insecure
prohibited as of 30 June 2010. wireless network. Examples of wireless
implementations requiring strong cryptography
include but are not limited to GPRS, GSM, WIFI,
satellite, and Bluetooth.
Strong cryptography for authentication and

transmission of cardholder data is required to
prevent malicious users from gaining access to
the wireless network the data on the network
or utilizing the wireless networks to get to
other internal networks or data. WEP encryption
should never be used as the sole means of
encrypting data over a wireless channel since it is
not considered strong cryptography, it is
vulnerable due to weak initialization vectors in
the WEP key- exchange process, and it lacks
required key rotation. An attacker can use freely
available brute-force cracking tools to easily
penetrate WEP encryption.
Current wireless devices should be upgraded

(example: upgrade access point firmware to
WPA2) to support strong encryption. If current
devices cannot be upgraded, new equipment
should be purchased or other compensating
controls implemented to provide strong
encryption.
4.2 Never send unprotected PANs by end-user E-mail, instant messaging, and chat can be easily
messaging technologies (for example, e-mail, instant intercepted by packet-sniffing during delivery
messaging, chat, etc.). traversal across internal and public networks. Do not
utilize these messaging tools to send PAN unless
they provide strong encryption.
etworks
essed by malicious individuals. Misconfigured wireless networks and vulnerabilities in legacy encryption and authentication protocols continue to be tar
ed traffic containing sensitive cardholder data to flow over the airwaves.

Top 20 Critical
Security Controls
C15.4.1 4.1 Verify the use of security protocols wherever cardholder data is transmitted or
C17.6 received over open, public networks. Verify that strong cryptography is used during
data transmission, as follows:
4.1.a Select a sample of transactions as they are received and observe transactions as
they occur to verify that cardholder data is encrypted during transit.
4.1.b Verify that only trusted keys and/or certificates are accepted.
4.1.c Verify that the protocol is implemented to use only secure configurations, and
does not support insecure versions or configurations.
4.1.d Verify that the proper encryption strength is implemented for the encryption
methodology in use. (Check vendor recommendations/best practices.)
4.1.e For SSL/TLS implementations:
- Verify that HTTPS appears as a part of the browser Universal Record Locator (URL).
- Verify that no cardholder data is required when HTTPS does not appear in the URL.
C7.1 4.1.1 For wireless networks transmitting cardholder data or connected to the
C7.10 cardholder data environment, verify that industry best practices (for example, IEEE
802.11i) are used to implement strong encryption for authentication and
transmission.
NA 4.2.a Verify that PAN is rendered unreadable or secured with strong cryptography
whenever it is sent via end-user messaging technologies.
4.2.b Verify the existence of a policy stating that unprotected PANs are not to be sent
via end-user messaging technologies.
hentication protocols continue to be targets of malicious individuals who exploit these vulnerabilities to gain privileged access to cardholder data environ
Vaidation Instructions for QSA/ISA Priority A B C-VT

Identify all instances where cardholder data is transmitted or received over open, 2 1
public networks.
For each identified instance:
i. Describetheobservedsecurityprotocolsinuse.
ii. Describe how configurations were observed to use strong cryptography.
Identify the number and types of transactions sampled. 2 1

For each sampled transaction, describe how cardholder data was observed to be
encrypted
during transit
For all instances where cardholder data is transmitted or received over open, public 2 1
networks:
i. Describe the mechanisms used to ensure that only trusted keys and/or certificates
are
accepted.
ii. Describe how the mechanisms were observed to accept only trusted keys and/or
certificates.
For all instances where cardholder data is transmitted or received over open, public 2
networks: i. Describe how the observed protocol configuration and implementation
confirms that:
o The security protocols are implemented to use only secure configurations.
o The protocol implementation does not support insecure versions or configurations.
For each encryption methodology in use: 2

i. Identify vendor recommendations/ best practices for encryption strength.
ii. Identify the encryption strength observed to be implemented.
For all instances where SSL/TLS is used to encrypt cardholder data over open, public 2 1
networks: i. Describe how observed configurations and processes confirm that:
HTTPS appears as a part of the browser URL.
There is no cardholder data required when HTTPS does not appear in the URL.
Identify all wireless networks transmitting cardholder data or connected to the 2

cardholder data environment.
For each identified wireless network:
i. Identify the industry best practices used to implement:
o Strong encryption for authentication
o Strong encryption for transmission
ii. Describe how observed wireless configurations and processes confirm that
industry best
practices are implemented for:
o Strong encryption for authentication o Strong encryption for transmission
Identify all instances where PAN is sent via end-user messaging technologies. For 2
each identified instance:
i. Describe the method used for securing PAN or rendering it unreadable for each end-
user messaging technology used.
ii. Describe how the method was observed to be implemented whenever PAN is sent
via these technologies.
Identify the policy document which states that unprotected PANs must not be sent via 2 1 1
end-user messaging technologies.
18 0 1 5
ss to cardholder data environments.
C D In Place? Severity Proofs / Stage of implementation

Documentation links
1 1 N 2
1 1 Y 0
1 1 Y 0
1 1 N 2
1 1 N 2
1 1 N 2
1 1 N 2
1 N 2
1 1 N 2
8 9 Y 14
N
C
Requirement 5: Use and regularly update anti-virus software or programs
Malicious software, commonly referred to as malwareincluding viruses, worms, and Trojansenters the network during many busines
5.1 Deploy anti-virus software on all systems There is a constant stream of attacks using widely
commonly affected by malicious software published exploits, often "0 day" (published and
(particularly personal computers and servers). spread throughout networks within an hour of
discovery) against otherwise secured systems.
Without anti-virus software that is updated
regularly, these new forms of malicious software can
attack and disable your network.
Malicious software may be unknowingly
downloaded and/or installed from the internet, but
computers are also vulnerable when using
removable storage devices such as CDs and DVDs,
USB memory sticks and hard drives, digital cameras,
personal digital assistants (PDAs) and other
peripheral devices. Without anti-virus software
installed, these computers may become access
points into your network, and/or maliciously target
information within the network.
While systems that are commonly affected by

malicious software typically do not include
mainframes and most Unix systems (see more detail
below), each entity must have a process according
to PCI DSS Requirement 6.2 to identify and address
new security vulnerabilities and update their
configuration standards and processes accordingly. If
another type of solution addresses the identical
threats with a different methodology than a
signature-based approach, it may still be acceptable
to meet the requirement.
Trends in malicious software related to operating

systems an entity uses should be included in the
identification of new security vulnerabilities, and
methods to address new trends should be
incorporated into the company's configuration
standards and protection mechanisms as needed.
Typically, the following operating systems are not
commonly affected by malicious software:
mainframes, and certain Unix servers (such as AIX,
Solaris, and HP-Unix). However, industry trends for
malicious software can change quickly and each
5.1.1 Ensure that all anti-virus programs are It is important to protect against ALL types and
capable of detecting, removing, and protecting forms of malicious software.
against all known types of malicious software.
5.2 Ensure that all anti-virus mechanisms are The best anti-virus software is limited in
current, actively running, and generating audit logs. effectiveness if it does not have current anti- virus
signatures or if it isn't active in the network or on an
individual's computer.
Audit logs provide the ability to monitor virus

activity and anti-virus reactions. Thus, it is
imperative that anti-virus software be configured to
generate audit logs and that these logs be managed
in accordance with Requirement 10.
senters the network during many business approved activities including employee e-mail and use of the Internet, mobile computers, and storage dev
Major Observations from the 2011 Verizon PCI Compliance Report:

Requirement 5 (Use and regularly update anti-virus software or programs) dropped from 70 percent last

Top 20 Critical
Security Controls
C5.1 5.1 For a sample of system components including all operating system types commonly
affected by malicious software, verify that anti-virus software is deployed if applicable
anti-virus technology exists.
C5.1 5.1.1 For a sample of system components, verify that all anti-virus programs detect,
C5.2 remove, and protect against all known types of malicious software (for example,
C5.3 viruses, Trojans, worms, spyware, adware, and rootkits).
C5.4
C5.5
C5.2 5.2 Verify that all anti-virus software is current, actively running, and generating logs
by performing the following:
5.2.a Obtain and examine the policy and verify that it requires updating of anti-virus
software and definitions.
5.2.b Verify that the master installation of the software is enabled for automatic
updates and periodic scans.
5.2.c For a sample of system components including all operating system types
commonly affected by malicious software, verify that automatic updates and periodic
scans are enabled.
5.2.d For a sample of system components, verify that anti-virus software log
generation is enabled and that such logs are retained in accordance with PCI DSS
Requirement 10.7.
et, mobile computers, and storage devices, resulting in the exploitation of system vulnerabilities. Anti-virus software must be used on all systems commo
11 Verizon PCI Compliance Report:

ograms) dropped from 70 percent last year to 64 percent this year.
Validation Instructions for QSA/ISA Priority A B C-VT C D

Identify the sample of system components observed (include all operating system ### 1 1 1
types commonly affected by malicious software).
For each sampled system component, describe how anti-virus software was observed
to be deployed.
Identify the sample of system components observed. ### 1 1 1

For each sampled system component, describe how anti-virus programs were
observed to:
i. Detect all known types of malicious software. ii. Remove all known types of
malicious software. 2
iii. Protect against all known types of malicious software.
### 1 1 1
Identify the policy document that requires updating of anti-virus software and ### 1 1 1
definitions. 2
For i. ### 1 1
ii. iii. iv.
each master installation, describe how observed configurations and processes confirm
that: Anti-virus software is configured for automatic updates.
Anti-virus software is configured for periodic scans. 2
Automatic updates are performed.
Periodic scans are performed.
Identify the sample of system components observed (include all operating system ### 1 1 1
types commonly affected by malicious software).
For each sampled system component, describe how observed configurations and
processes confirm that:
i. Anti-virus software is configured for automatic updates.
ii. Anti-virus software is configured for periodic scans. 2
iii. Automatic updates are performed.
iv. Periodic scans are performed.
Identify the sample of system components observed ### 1 1 1

For each of these samples:
Describe how anti-vuris software log generation was observed to be enabled
Describe how antivirus logs were observed to be retained in accordance with PCI-DSS
10.7. 2
Audit logs are available for at least one year
Processes are in place to immediately restore at least the last three months'slogs for
analysis.
14 ###0 0 6 7 7
used on all systems commonly affected by malware to protect systems from current and evolving malicious software threats.
In Place? Severity Proofs / Documentation Stage of implementation

links
N 2
N 2
N 2
N 2
N 2
N 2
N 2
Y 14
N
C
ous software threats.

Requirement 6: Develop and maintain secure systems and applications
Unscrupulous individuals use security vulnerabilities to gain privileged access to systems. Many of these vulnerabilities are fixed by vendor
Note: Appropriate software patches are those patches that have been evaluated and tested sufficiently to determine that the patches do no

Requirement 6 (Develop and maintain secure systems and applications) is up from 48 percent overall compliance to 53 percent.
Patching itself is still an issue, as only 74 percent of businesses were able to make certain that all systems were properly patched at the tim
6.1 Ensure that all system components and software There are a considerable amount of attacks using
are protected from known vulnerabilities by having widely published exploits, often "0 day" (published
the latest vendor-supplied security patches installed. within the hour) against otherwise secured systems.
Install critical security patches within one month of Without implementing the most recent patches on
release. critical systems as soon as possible, a malicious
individual can use these exploits to attack and
Note: An organization may consider applying a risk- disable the network. Consider prioritizing changes
based approach to prioritize their patch installations. such that critical security patches on critical or at-
For example, by prioritizing critical infrastructure (for risk systems can be installed within 30 days, and
example, public-facing devices and systems, other less-risky changes are installed within 2-3
databases) higher than less-critical internal devices, months.
to ensure high-priority systems and devices are
addressed within one month, and addressing less
critical devices and systems within three months.
6.2 Establish a process to identify and assign a risk The intention of this requirement is that
ranking to newly discovered security vulnerabilities. organizations keep up-to-date with new
vulnerabilities that may impact their environment.
Notes:
- Risk rankings should be based on industry best While it is important to monitor vendor
practices. For example, criteria for ranking High announcements for news of vulnerabilities and
risk vulnerabilities may include a CVSS base score of patches related to their products, it is equally
4.0 or above, and/or a vendor-supplied patch important to monitor common industry vulnerability
classified by the vendor as critical, and/or a news groups and mailing lists for vulnerabilities and
vulnerability affecting a critical system component. potential workarounds that may not yet be known
- The ranking of vulnerabilities as defined in 6.2.a is or resolved by the vendor.
considered a best practice until June 30, 2012, after
which it becomes a requirement. Once an organization identifies a vulnerability that
could affect their environment, the risk that
vulnerability poses must be evaluated and ranked.
This implies that the organization has some method
in place to evaluate vulnerabilities and assign risk
rankings on a consistent basis. While each
organization will likely have different methods for
evaluating a vulnerability and assigning a risk rating
based on their unique CDE, it is possible to build
upon common industry accepted risk ranking
systems, for example CVSS. 2.0, NIST SP 800-30, etc.
- Risk rankings should be based on industry best While it is important to monitor vendor
practices. For example, criteria for ranking High announcements for news of vulnerabilities and
risk vulnerabilities may include a CVSS base score of patches related to their products, it is equally
4.0 or above, and/or a vendor-supplied patch important to monitor common industry vulnerability
classified by the vendor as critical, and/or a news groups and mailing lists for vulnerabilities and
vulnerability affecting a critical system component. potential workarounds that may not yet be known
- The ranking of vulnerabilities as defined in 6.2.a is or resolved by the vendor.
considered a best practice until June 30, 2012, after
which it becomes a requirement. Once an organization identifies a vulnerability that
could affect their environment, the risk that
vulnerability poses must be evaluated and ranked.
This implies that the organization has some method
in place to evaluate vulnerabilities and assign risk
rankings on a consistent basis. While each
organization will likely have different methods for
evaluating a vulnerability and assigning a risk rating
based on their unique CDE, it is possible to build
upon common industry accepted risk ranking
systems, for example CVSS. 2.0, NIST SP 800-30, etc.
Classifying the risks (for example, as high,

medium, or low) allows organizations to identify
and address high priority risk items more quickly,
and reduce the likelihood that vulnerabilities posing
the greatest risk will be exploited
6.3 Develop software applications (internal and Without the inclusion of security during the
external, and including webbased administrative requirements definition, design, analysis, and
access to applications) in accordance with PCI DSS testing phases of software development, security
(for example, secure authentication and logging), vulnerabilities can be inadvertently or maliciously
and based on industry best practices. Incorporate introduced into the production environment.
information security throughout the software
development life cycle. These processes must
include the following:
6.3.1 Removal of custom application accounts, Custom application accounts, user IDs, and
user IDs, and passwords before applications passwords should be removed from production
become active or are released to customers code before the application becomes active or
is released to customers, since these items
may give away information about the
functioning of the application. Possession of
such information could facilitate compromise
of the application and related cardholder data.
6.3.2 Review of custom code prior to release to Security vulnerabilities in custom code are
production or customers in order to identify any commonly exploited by malicious individuals to gain
potential coding vulnerability. access to a network and compromise cardholder
data.
Note: This requirement for code reviews applies to
all custom code (both internal and public-facing), Code reviews may be performed manually, or with
as part of the system development life cycle. Code the assistance of automated review tools.
reviews can be conducted by knowledgeable Automated review tools have functionality that
internal personnel or third parties. Web reviews code for common coding mistakes and
applications are also subject to additional vulnerabilities. While automated review is useful, it
controls, if they are public facing, to address should not generally be relied upon as the sole
ongoing threats and vulnerabilities after means of code review. An individual knowledgeable
implementation, as defined at PCI DSS and experienced in code review should be involved
Requirement 6.6. in the review process in order to identify code issues
that are difficult or even impossible for an
automated tool to identify. Assigning code reviews
to someone other than the developer of the code
allows an independent, objective review to be
performed.
6.4 Follow change control processes and procedures Without proper change controls, security features
for all changes to system components. The could be inadvertently or deliberately omitted or
processes must include the following: rendered inoperable, processing irregularities could
occur, or malicious code could be introduced.
6.4.1 Separate development/test and production Due to the constantly changing state of
environments development and test environments, they tend to
be less secure than the production environment.
Without adequate separation between
environments it may be possible for the production
environment, and cardholder data, to be
compromised due to vulnerabilities in a test or
development environment.
6.4.2 Separation of duties between Reducing the number of personnel with access to
development/test and production environments the production environment and cardholder data
minimizes risk and helps ensure that access is
limited to those individuals with a business need
to know.
The intent of this requirement is to ensure that

development/test functions are separated from
production functions. For example, a developer
may use an administrator-level account with
elevated privileges for use in the development
environment, and have a separate account with
user-level access to the production environment.
In environments where one individual performs

multiple roles (for example application
development and implementing updates to
production systems), duties should be assigned
such that no one individual has end-to-end
control of a process without an independent
checkpoint. For example, assign responsibility for
development, authorization and monitoring to
separate individuals.
6.4.3 Production data (live PANs) are not used for Security controls are usually not as stringent in
testing or development the development environment. Use of production
data provides malicious individuals with the
opportunity to gain unauthorized access to
production data (cardholder data).
Payment card brands and many acquires are able
to provide account numbers suitable for testing in
the event that you need realistic PANs to test
system functionality prior to release.
6.4.4 Removal of test data and accounts before Test data and accounts should be removed from
production systems become active production code before the application becomes
active, since these items may give away
information about the functioning of the
application. Possession of such information could
facilitate compromise of the application and
related cardholder data.
6.4.5 Change control procedures for the Without proper change controls, security features
implementation of security patches and software could be inadvertently or deliberately omitted or
modifications. Procedures must include the rendered inoperable, processing irregularities could
following: occur, or malicious code could be introduced.
Likewise, a change may negatively affect security
functionality of a system necessitating the change to
be backed out.
6.4.5.1 Documentation of impact. The impact of the change should be documented
so that all affected parties will be able to plan
appropriately for any processing changes.
6.4.5.2 Documented change approval by Approval by authorized parties indicates that the
authorized parties. change is a legitimate and approved change
sanctioned by the organization.
6.4.5.3 Functionality testing to verify that the Thorough testing should be performed to verify that
change does not adversely impact the security of the security of the environment is not reduced by
the system. implementing a change. Testing should validate that
all existing security controls remain in place, are
replaced with equally strong controls, or are
strengthened after any change to the environment.
For custom code changes, testing includes verifying
that no coding vulnerabilities have been introduced
by the change.
6.4.5.4 Back-out procedures. For each change, there should be back-out

procedures in case the change fails, to allow for
restoring back to the previous state.
6.5 Develop applications based on secure coding The application layer is high-risk and may be
guidelines. Prevent common coding vulnerabilities targeted by both internal and external threats.
in software development processes, to include the Without proper security, cardholder data and other
following: confidential company information can be exposed,
resulting in harm to a company, its customers, and
Note: The vulnerabilities listed at 6.5.1 through 6.5.9 its reputation.
were current with industry best practices when this
version of PCI DSS was published. However, as As with all PCI DSS requirements, Requirements
industry best practices for vulnerability management 6.5.1 through 6.5.5 and 6.5.7 through 6.5.9 are the
are updated (for example, the OWASP Guide, SANS minimum controls that should be in place. This list is
CWE Top 25, CERT Secure Coding, etc.), the current composed of the most common, accepted secure
best practices must be used for these coding practices at the time that this version of the
requirements. PCI DSS was published. As industry accepted secure
coding practices change, organizational coding
practices should likewise be updated to match.
The examples of secure coding resources provided

(SANS, CERT, and OWASP) are suggested sources of
reference and have been included for guidance only.
An organization should incorporate the relevant
secure coding practices as applicable to the
particular technology in their environment.
industry best practices for vulnerability management 6.5.1 through 6.5.5 and 6.5.7 through 6.5.9 are the
are updated (for example, the OWASP Guide, SANS minimum controls that should be in place. This list is
CWE Top 25, CERT Secure Coding, etc.), the current composed of the most common, accepted secure
best practices must be used for these coding practices at the time that this version of the
requirements. PCI DSS was published. As industry accepted secure
coding practices change, organizational coding
practices should likewise be updated to match.
The examples of secure coding resources provided

(SANS, CERT, and OWASP) are suggested sources of
reference and have been included for guidance only.
An organization should incorporate the relevant
secure coding practices as applicable to the
particular technology in their environment.
6.5.1 Injection flaws, particularly SQL injection. Validate input to verify user data cannot modify
Also consider OS Command Injection, LDAP and meaning of commands and queries. Injection
XPath injection flaws as well as other injection flaws, particularly SQL injection, are a commonly
flaws. used method for compromising applications.
Injection occurs when user-supplied data is sent
to an interpreter as part of a command or query.
The attacker's hostile data tricks the interpreter
into executing unintended commands or changing
data, and allows the attacker to attack
components inside the network through the
application, to initiate attacks such as buffer
overflows, or to reveal both confidential
information and server application functionality.
This is also a popular way to conduct fraudulent
transactions on commerce-enabled web sites.
Information from requests should be validated
before being sent to the application for
example, by checking for all alpha characters, mix
of alpha and numeric characters, etc.
6.5.2 Buffer overflow Ensure that applications are not vulnerable to

buffer overflow attacks. Buffer overflows happen
when an application does not have appropriate
bounds checking on its buffer space. To exploit a
buffer overflow vulnerability, an attacker would
send an application a larger amount of
information than one of its particular buffers is
able to handle. This can cause the information in
the buffer to be pushed out of the buffers
memory space and into executable memory
space. When this occurs, the attacker has the
ability to insert malicious code at the end of the
buffer and then push that malicious code into
executable memory space by overflowing the
buffer. The malicious code is then executed and
often enables the attacker remote access to the
application and/or infected system.
6.5.3 Insecure cryptographic storage Prevent cryptographic flaws. Applications that do
not utilize strong cryptographic functions properly
to store data are at increased risk of being
compromised and exposing cardholder data. If an
attacker is able to exploit weak cryptographic
processes, they may be able to gain clear-text
access to encrypted data.
6.5.4 Insecure communications Properly encrypt all authenticated and sensitive

communications. Applications that fail to
adequately encrypt network traffic using strong
cryptography are at increased risk of being
compromised and exposing cardholder data. If an
attacker is able to exploit weak cryptographic
processes, they may be able to gain control of an
application or even gain clear-text access to
encrypted data.
6.5.5 Improper error handling Do not leak information via error messages or
other means. Applications can unintentionally
leak information about their configuration,
internal workings, or violate privacy through a
variety of application problems. Attackers use this
weakness to steal sensitive data, or conduct more
serious attacks. Also, incorrect error handling
provides information that helps a malicious
individual compromise the system. If a malicious
individual can create errors that the application
does not handle properly, they can gain detailed
system information, create denial-of- service
interruptions, cause security to fail, or crash the
server. For example, the message "incorrect
password provided" tells them the user ID
provided was accurate and that they should focus
their efforts only on the password. Use more
generic error messages, like "data could not be
verified."
6.5.6 All High vulnerabilities identified in the Any high vulnerabilities noted per Requirement
vulnerability identification process (as defined in 6.2 that could affect the application should be
PCI DSS Requirement 6.2). accounted for during the development phase. For
example, a vulnerability identified in a shared
Note: This requirement is considered a best library or in the underlying operating system
practice until June 30, 2012, after which it should be evaluated and addressed prior to the
becomes a requirement. application being released to production.
6.5.7 Cross-site scripting (XSS) All parameters should be validated before

inclusion. XSS flaws occur whenever an
application takes user supplied data and sends it
to a web browser without first validating or
encoding that content. XSS allows attackers to
execute script in the victim's browser which can
hijack user sessions, deface web sites, possibly
introduce worms, etc.
6.5.8 Improper Access Control (such as insecure Do not expose internal object references to users.
direct object references, failure to restrict URL A direct object reference occurs when a
access, and directory traversal) developer exposes a reference to an internal
implementation object, such as a file, directory,
database record, or key, as a URL or form
parameter. Attackers can manipulate those
references to access other objects without
authorization.
Consistently enforce access control in
presentation layer and business logic for all URLs.
Frequently, the only way an application protects
sensitive functionality is by preventing the display
of links or URLs to unauthorized users. Attackers
can use this weakness to access and perform
unauthorized operations by accessing those URLs
directly.
Protect against directory traversal. An attacker
may be able to enumerate and navigate the
directory structure of a website thus gaining
access to unauthorized information as well as
gaining further insight into the workings of the
site for later exploitation.
6.5.9 Cross-site request forgery (CSRF) Do not reply on authorization credentials and
tokens automatically submitted by browsers. A
CSRF attack forces a logged-on victim's browser to
send a pre- authenticated request to a vulnerable
web application, which then forces the victim's
browser to perform a hostile action to the benefit
of the attacker. CSRF can be as powerful as the
web application that it attacks.
6.6 For public-facing web applications, address new Attacks on web-facing applications are common and
threats and vulnerabilities on an ongoing basis and often successful, and are allowed by poor coding
ensure these applications are protected against practices. This requirement for reviewing
known attacks by either of the following methods: applications or installing web-application firewalls is
intended to greatly reduce the number of
- Reviewing public-facing web applications via compromises on public-facing web applications that
manual or automated application vulnerability result in breaches of cardholder data.
security assessment tools or methods, at least
annually and after any changes Manual or automated vulnerability security
- Installing a web-application firewall in front of assessment tools or methods that review and/or
public-facing web applications scan for application vulnerabilities can be used to
satisfy this requirement
Web-application firewalls filter and block non-

essential traffic at the application layer. Used in
conjunction with a network-based firewall, a
properly configured web-application firewall
prevents application-layer attacks if applications are
improperly coded or configured.
y of these vulnerabilities are fixed by vendorprovided security patches, which must be installed by the entities that manage the systems. All critical system
fficiently to determine that the patches do not conflict with existing security configurations. For in-house developed applications, numerous vulnerabilities
overall compliance to 53 percent.

all systems were properly patched at the time of the IROC.

Top 20 Critical
Security Controls
C3.7 6.1.a For a sample of system components and related software, compare the list of
C4.1.1 security patches installed on each system to the most recent vendor security patch list,
to verify that current vendor patches are installed.
6.1.b Examine policies related to security patch installation to verify they require
installation of all critical new security patches within one month.
C4.5 6.2.a Interview responsible personnel to verify that processes are implemented to
identify new security vulnerabilities, and that a risk ranking is assigned to such
vulnerabilities. (At minimum, the most critical, highest risk vulnerabilities should be
ranked as High.)
6.2.b Verify that processes to identify new security vulnerabilities include using
outside sources for security vulnerability information.
C6.6 6.3.a Obtain and examine written software development processes to verify that the
C19.4 processes are based on industry standards and/or best practices.
6.3.b Examine written software development processes to verify that information

security is included throughout the life cycle.
6.3.c Examine written software development processes to verify that software

applications are developed in accordance with PCI DSS.
6.3.d From an examination of written software development processes, and interviews

of software developers, verify that:
C3.3 6.3.1 Custom application accounts, user IDs and/or passwords are removed before
system goes into production or is released to customers.
C6.3 6.3.2.a Obtain and review policies to confirm that all custom application code
changes must be reviewed (using either manual or automated processes) as follows:
- Code changes are reviewed by individuals other than the originating code author,
and by individuals who are knowledgeable in code review techniques and secure
coding practices.
- Code reviews ensure code is developed according to secure coding guidelines (see
PCI DSS Requirement 6.5).
- Appropriate corrections are implemented prior to release.
- Code review results are reviewed and approved by management prior to release.
6.3.2.b Select a sample of recent custom application changes and verify that custom
application code is reviewed according to 6.3.2.a, above.
6.4 From an examination of change control processes, interviews with system and
network administrators, and examination of relevant data (network configuration
documentation, production and test data, etc.), verify the following:
C20.7 6.4.1 The development/test environments are separate from the production
environment, with access control in place to enforce the separation.
NC 6.4.2 There is a separation of duties between personnel assigned to the
development/test environments and those assigned to the production environment.
NC 6.4.3 Production data (live PANs) are not used for testing or development.
NC 6.4.4 Test data and accounts are removed before a production system becomes
active.
NC 6.4.5.a Verify that change-control procedures related to implementing security

patches and software modifications are documented and require items 6.4.5.1
6.4.5.4 below.
6.4.5.b For a sample of system components and recent changes/security patches,
trace those changes back to related change control documentation. For each change
examined, perform the following:
NC 6.4.5.1 Verify that documentation of impact is included in the change control

documentation for each sampled change.
NC 6.4.5.2 Verify that documented approval by authorized parties is present for each
sampled change.
C6.3 6.4.5.3.a For each sampled change, verify that functionality testing is performed to
verify that the change does not adversely impact the security of the system.
6.4.5.3.b For custom code changes, verify that all updates are tested for compliance
with PCI DSS Requirement 6.5 before being deployed into production.
NC 6.4.5.4 Verify that back-out procedures are prepared for each sampled change.
C6.7 6.5.a Obtain and review software development processes. Verify that processes
require training in secure coding techniques for developers, based on industry best
practices and guidance.
6.5.b Interview a sample of developers and obtain evidence that they are
knowledgeable in secure coding techniques.
6.5.c. Verify that processes are in place to ensure that applications are not vulnerable
to, at a minimum, the following:
C6.1 6.5.1 Injection flaws, particularly SQL injection. (Validate input to verify user data
cannot modify meaning of commands and queries, utilize parameterized queries,
etc.)
NC 6.5.2 Buffer overflow (Validate buffer boundaries and truncate input strings.)
NC 6.5.3 Insecure cryptographic storage (Prevent cryptographic flaws)
6.5.4 Insecure communications (Properly encrypt all authenticated and sensitive

communications)
NC 6.5.5 Improper error handling (Do not leak information via error messages)
NA 6.5.6 All High vulnerabilities as identified in PCI DSS Requirement 6.2.
C6.1 6.5.7 Cross-site scripting (XSS) (Validate all parameters before inclusion, utilize
context-sensitive escaping, etc.)
NC 6.5.8 Improper Access Control, such as insecure direct object references, failure to
restrict URL access, and directory traversal (Properly authenticate users and sanitize
input. Do not expose internal object references to users.)
C6.1 6.5.9 Cross-site request forgery (CSRF). (Do not reply on authorization credentials
and tokens automatically submitted by browsers.)
C13.12 6.6 For public-facing web applications, ensure that either one of the following
C6.1 methods are in place as follows:
C6.3
C11.6 - Verify that public-facing web applications are reviewed (using either manual or
automated vulnerability security assessment tools or methods), as follows:
- At least annually
- After any changes
- By an organization that specializes in application security
- That all vulnerabilities are corrected
- That the application is re-evaluated after the corrections
- Verify that a web-application firewall is in place in front of public-facing web
applications to detect and prevent web-based attacks.
Note: An organization that specializes in application security can be either a third-

party company or an internal organization, as long as the reviewers specialize in
application security and can demonstrate independence from the development team.
t manage the systems. All critical systems must have the most recently released, appropriate software patches to protect against exploitation and compr
applications, numerous vulnerabilities can be avoided by using standard system development processes and secure coding techniques.

Identify the sample of system components observed. 1

Identify the related software observed on each system component. For each item
in the sample:
i. Identify the vendor security patch list reviewed.
ii. Describe how current vendor security patches for the system component and/or 3
related
software were observed to be installed.
Identify the document requiring that all critical new security patches are installed 1
within one month.
Identify the responsible personnel interviewed who confirm:

i. That processes are in place to identify new security vulnerabilities
ii. Whether a risk ranking is assigned to such vulnerabilities
If risk ranking is assigned to new vulnerabilities, briefly describe the observed
process for 3
assigning a risk ranking, including how critical, highest risk vulnerabilities are ranked as
High* (Note: The ranking of vulnerabilities is considered a best practice until June 30,
2012, after which it
becomes a requirement.)
Identify the document requiring that outside sources are used to identify new security
vulnerabilities.
Identify the outside sources used.
Describe how processes were observed to use outside sources to identify new
security
vulnerabilities.
Identify the document that defines software development processes based on industry
standards and/or best practice.
Identify the industry standards and/or best practices used. 3
Identify the documented software development processes that include information

security throughout the software development life cycle. 3
Identify the documented software development processes that specify how software
applications are developed in accordance with PCI DSS. 3
Identify the document requiring removal of custom application accounts, user IDs
and/or passwords before the system goes into production or is released to
customers.
Identify the responsible personnel interviewed who confirm that custom
application accounts, user IDs and/or passwords are removed before the system 3
goes into production or is released to customers.
Identify the policy document requiring that all custom application code changes
must be reviewed.
Describe the documented processes used for reviewing custom application code
changes (for example, manual or automated, or a combination of both).
Identify the documents which define processes for custom application code
reviews, and confirm the documented processes require the following:
i. All custom application code changes are reviewed.
ii. Code changes are reviewed by individuals other than the original author.
iii. Code changes are reviewed by individuals who are knowledgeable in code review
techniques.
iv. Code changes are reviewed by individuals who are knowledgeable in secure
coding practices.
v. Code reviews ensure secure coding guidelines have been followed. 3
vi. Any corrections identified during the code review are implemented prior to
release.
vii. Code review results are reviewed by management prior to release.
viii. Code review results are approved by management prior to release.
Identify the sample of custom application changes.

For each sampled application change, describe how the following code review
processes were
observed to be implemented:
i. All custom application code changes are reviewed.
ii. Code changes are reviewed by individuals other than the original author.
iii. Code changes are reviewed by individuals who are knowledgeable in code review
techniques.
iv. Code changes are reviewed by individuals who are knowledgeable in secure
coding practices. 3
v. Code reviews ensure secure coding guidelines have been followed.
vi. Any corrections identified during the code review are implemented prior to
release.
vii. Code-review results are reviewed by management prior to release.
viii. Code review results are approved by management prior to release.
Identify the document that defines and/or illustrates:

How the development/test environment is separated from the production
environment
Access control to enforce separation
Identifify the system and /or network asministrators interviewed to confirm the 3
above.
Describe how the development/test environmentwas observed separated from the
production environement and how the access controls were observed to enforced
separation
Identify the document that defines separation of duties between personnel
assigned to the development/test environment and those assigned to the
production environment.
Briefly describe how separation of duties is implemented.
Identify the personnel assigned to the development/test environments and those
assigned to the production environment who were interviewed to confirm that
separation of duties is in place.
Describe how separation of duties was observed to be implemented
Identify the document that defines processes for ensuring:

i. Live PANs are not used for testing.
ii. Live PANs are not used for development.
Identify the development, test and/or production personnel interviewed who
confirm:
ii. Live PANs are not used for development. 3
Describe how it was observed that:
ii. Live PANs are not used for development.
Identify the documentthat defines processes for:

Removing test data and test account before a production system becomes active
Identify the development/test and/or production personnel interviewed to confirm
the above. 3
Describe the processes obervsedto be implementedfor the above.
Identify the document that defines change control procedures for implementation
of security patches and software modifications.
Confirm that the documented procedures require the following for all changes:
i. Documentation of impact
ii. Documented approval by authorized parties
iii. Testing of functionality to ensure the change does not adversely impact the
security of the
system 6
iv. Testing of all custom code updates for compliance with PCI DSS Requirement 6.5
(to
address the vulnerabilities identified in 6.5.1 6.5.9)
v. Back-out procedures
6
Identify the sample of: i. System components

ii. Recent changes/security patches
For each sampled change, describe how documentation of the impact of the 6
change is included in the change control documentation.
Identify the sample of:

i. System components
For each sampled change, describe how documented approval by authorized 6
parties is included in the change control documentation.

ii. Recent changes/security patches For each sampled change:
i. Describe how details of functionality testing are included in the change control
documentation.
ii. Describe how the functionality testing performed verifies that the change does 6
not adversely impact the security of the system.

ii. Recent custom code changes/updates
For each sampled custom code change:
i. Describe how details of testing for compliance with PCI DSS Requirement 6.5 (to
address the vulnerabilities defined in 6.5.1 6.5.9) are included in the change
control documentation. 6
ii. Describe how the testing performed verifies that all updates are compliant with
PCI DSS Requirement 6.5 (6.5.1 6.5.9) before being deployed into production.

For each sampled change:
Describe how details of back-out procedures are included in the change control 6
documentation.
Describe how the back-out procedures were observed to be prepared for each
change.
Identify the document requiring that developers are trained in secure coding
techniques. Identify the industry best practices and guidance that training is based
on.
3
Identify the sample of developers interviewed.

Describe how the interviewed personnel demonstrated they are knowledgeable in
secure
coding techniques. 3
3
Identify the document that defines the process for ensuring all applications are not
vulnerable to injection flaws, particularly SQL injection.
Describe the processes observed to be in place for ensuring that all applications
are not vulnerable to injection flaws, particularly SQL injection.
vulnerable to buffer overflow.
are not vulnerable to buffer overflow.
3
vulnerable to insecure cryptographic storage.
are not vulnerable to insecure cryptographic storage.
3
vulnerable to insecure communications.
are not vulnerable to insecure communications.
3
vulnerable to improper error handling.
Describe the processes observed to be in place for ensuring that all applications are
not vulnerable to improper error handling.
Identify whether a process is in place to ensure all applications are not vulnerable to
High vulnerabilities as identified in PCI DSS Requirement 6.2.
If there is a process in place:
i. Identify the document that defines the process for ensuring that all applications
are not 3
vulnerable to High vulnerabilities as identified in PCI DSS Requirement 6.2.
ii. Describe the processes observed to be in place for ensuring that applications are
not vulnerable to all High vulnerabilities, as identified in PCI DSS Requirement 6.2.
Identify the document that defines the process for ensuring web applications and
application interfaces are not vulnerable to cross-site scripting (XSS).
Describe the processes observed to be in place for ensuring that web applications
and application interfaces are not vulnerable to cross-site scripting (XSS). 3
application interfaces are not vulnerable to improper access control.
and
application interfaces are not vulnerable to improper access control.
application interfaces are not vulnerable to cross-site request forgery.
and application interfaces are not vulnerable to cross-site request forgery.
3
For each public-facing web application:
i. Identify which of the two methods are implemented (web application vulnerability
security assessments, web application firewalls, or both).
If application vulnerability security assessments are performed:

i. Describe the tools and/or methods used (manual or automated, or a combination of
both).
ii. Describe how it was observed that assessments are performed: o At least annually
o After any changes
iii. Identify the organization(s) performing the assessments.
iv. Identify the responsible personnel interviewed, and describe how those reviewing
the
applications were confirmed to:
o Specialize in application security
o Demonstrate independence from the development team
v. Describe the observed process which confirm that:
o All identified vulnerabilities are corrected.
o Applications are re-evaluated after the corrections are applied. 3
If a web-application firewall(s) is used:

i. Describe how the web-application firewall was observed to be placed in front of all
public-
facing web applications.
ii. Describe the observed web-application firewall configurations for:
o Detecting web-based attacks
o Preventing web-based attacks
iii. Describe how the web-application firewall was observed to:
o Detect web-based attacks o Prevent web-based attacks
129 0 0 2
against exploitation and compromise of cardholder data by malicious individuals and malicious software.
g techniques.

Documentation links
1 1 N 3
1 1 N 3
1 N 3
1 N 3
1 N 3
1 N 3
1 N 3
1 N 3
1 N 3
1 N 3
1 N 3
1 N 3
1 N 3
1 N 3
1 N 3
1 N 3
1 N 6
1 N 6
1 N 6
1 N 6
1 N 6
1 N 6
1 N 6
1 N 3
1 N 3
1 N 3
1 N 3
1 N 3
1 N 3
1 N 3
1 N 3
1 N 3
1 N 3
1 N 3
1 N 3
1 N 3
2 36 Y 129
N
C
Requirement 7: Restrict access to cardholder data by business need to know
To ensure critical data can only be accessed by authorized personnel, systems and processes must be in place to limit access based on need
Need to know is when access rights are granted to only the least amount of data and privileges needed to perform a job.
Most organizations fail to
7.1 Limit access to system components and The more people who have access to cardholder
cardholder data to only those individuals whose job data, the more risk there is that a users account will
requires such access. Access limitations must be used maliciously. Limiting access to those with a
include the following: strong business reason for the access helps your
organization prevent mishandling of cardholder data
through inexperience or malice. When access rights
are granted only to the least amount of data and
privileges needed to perform a job, this is a called
least privilege and need to know, and when
privileges are assigned to individuals based on job
classification and function, this is called role-based
access control or RBAC. Role based access control
enforcement is not limited to an application layer or
any specific authorization solution. For example,
technology including but not limited to directory
services such as Active Directory or LDAP, Access
Control Lists (ACLs), and TACACS are viable solutions
as long as they are appropriately configured to
enforce the principles of least privilege and need to
know.
Organizations should create a clear policy and
processes for data access control based on need to
know and using role-based access control, to define
how and to whom access is granted, including
appropriate management authorization processes.
7.1.1 Restriction of access rights to privileged user

IDs to least privileges necessary to perform job
responsibilities
7.1.2 Assignment of privileges is based on

individual personnels job classification and
function
7.1.3 Requirement for a documented approval by
authorized parties specifying required privileges.
7.1.4 Implementation of an automated access

control system
7.2 Establish an access control system for systems Without a mechanism to restrict access based on
components with multiple users that restricts access users need to know, a user may unknowingly be
based on a users need to know, and is set to deny granted access to cardholder data. Use of an
all unless specifically allowed. automated access control system or mechanism is
This access control system must include the essential to manage multiple users. This system
following: should be established in accordance with your
organizations access control policy and processes
(including need to know and role-based access
control), should manage access to all system
components, and should have a default deny-all
setting to ensure no one is granted access until and
unless a rule is established specifically granting such
access.
7.2.1 Coverage of all system components
7.2.2 Assignment of privileges to individuals

based on job classification and function
7.2.3 Default deny-all setting
Note: Some access control systems are set by

default to allow-all, thereby permitting access
unless/until a rule is written to specifically deny it.
ust be in place to limit access based on need to know and according to job responsibilities.
ges needed to perform a job.
Major Observations 2011 Verizon PCI Compliance Report:

The percentage of organizations fully meeting Requirement 7 at time of IROC was 75 percent, an eight perc
Organizations met an average of 87 percent of tests in Requirement 7 at time of IROCthe highe
Most organizations fail to meet it in full due to lack of a documented and enforced access control policy as well as fail to automate the
When implementing access controls, several organizations are still focusing too much on

Top 20 Critical
Security Controls
C12.1.1 7.1 Obtain and examine written policy for data control, and verify that the policy
incorporates the following:
C12.6 7.1.1 Confirm that access rights for privileged user IDs are restricted to least
C12.7 privileges necessary to perform job responsibilities.
NC 7.1.2 Confirm that privileges are assigned to individuals based on job classification
and function (also called role-based access control or RBAC).
C12.1.1 7.1.3 Confirm that documented approval by authorized parties is required (in
writing or electronically) for all access, and that it must specify required privileges.
NC 7.1.4 Confirm that access controls are implemented via an automated access control
system.
C12.14 7.2 Examine system settings and vendor documentation to verify that an access
C15.3 control system is implemented as follows:
NC 7.2.1 Confirm that access control systems are in place on all system components.
C12.14 7.2.2 Confirm that access control systems are configured to enforce privileges
assigned to individuals based on job classification and function.
NC 7.2.3 Confirm that the access control systems have a default deny-all setting.
s 2011 Verizon PCI Compliance Report:
time of IROC was 75 percent, an eight percent increase over the 2010 report results.
Requirement 7 at time of IROCthe highest among all twelve key controls.
ntrol policy as well as fail to automate the process of identifying and maintaining a list of authorized personnel.
rganizations are still focusing too much on the network perimeter.
Validation Instructions for QSA/ISA Priority A B

4 ### 1
Identify the data control policy document which requires that access rights for 4 ### 1
privileged user IDs are restricted to the least privileges necessary to perform job
responsibilities.
Identify the data control policy document requiring that privileges are assigned to 4 ### 1
individuals based on job classification and function.
Identify the data control policy document that requires the following: 4 ###
i. Documented approval by authorized parties for all access.
ii. That documented approval must specify the required privileges.
Identify the data control policy document requiring that access controls are 4 ###
implemented using an automated access control system
4 ###
Describe the access control systems in use. 4 ###

Describe how access control systems were observed to be in place on all system
components.
For each access control system in use: 4 ###

i. Identify the documents that describe:
o Job classifications and functions
o The associated privilege assignments
ii. Describe how the access control systems were observed to enforce privileges
assigned to individuals based on job classification and function.
For each access control system in use: 4 ###

i. Describe how the access control system was observed to have a default deny-all
setting.
36 ###0 3
C-VT C D In place? Severity Proofs / Stage of implementation
Documentation links
1 1 1 N 4
1 1 1 N 4
1 1 1 N 4
1 N 4
1 N 4
1 N 4
1 N 4
1 N 4
1 N 4
3 3 9 Y 36
N
C
Remediation plan Estimated date for completion Comments
Owner
Requirement 8: Assign a unique ID to each person with computer access
Assigning a unique identification (ID) to each person with access ensures that each individual is uniquely accountabl
Of all the
Sub-requirement 8.3 (Ensure proper user authentication and password management for non-consumer users and administrators on al
Sub-requirements 8.4 (Render all passwords unreadable during transmission and s
Most organizations do comm
8.1 Assign all users a unique ID before allowing By ensuring each user is uniquely identified
them to access system components or cardholder instead of using one ID for several employeesan
data. organization can maintain individual responsibility
for actions and an effective audit trail per employee.
This will help speed issue resolution and
containment when misuse or malicious intent
occurs.
8.2 In addition to assigning a unique ID, employ at These authentication items, when used in addition
least one of the following methods to authenticate to unique IDs, help protect users unique IDs from
all users: being compromised (since the one attempting the
compromise needs to know both the unique ID and
- Something you know, such as a password or the password or other authentication item).
passphrase
- Something you have, such as a token device or A digital certificate is a valid option as a form of the
smart card authentication type something you have as long
- Something you are, such as a biometric as it is unique.
8.3 Incorporate two-factor authentication for Two-factor authentication requires two forms of
remote access (network-level access originating authentication for higher-risk accesses, such as
from outside the network) to the network by those originating from outside your network. For
employees, administrators, and third parties. (For additional security, your organization can also
example, remote authentication and dialin service consider using two-factor authentication when
(RADIUS) with tokens; terminal access controller accessing networks of higher security from networks
access control system (TACACS) with tokens; or of lower securityfor example, from corporate
other technologies that facilitate two-factor desktops (lower security) to production
authentication.) servers/databases with cardholder data (high
security).
Note: Two-factor authentication requires that two of
the three authentication methods (see Requirement This requirement is intended to apply to users that
8.2 for descriptions of authentication methods) be have remote access to the network, where that
used for authentication. Using one factor twice (for remote access could lead to access to the
example, using two separate passwords) is not cardholder data environment.
considered two-factor authentication.
n this context, remote access refers to network-level
access originating from outside an entitys own
network, either from the Internet or from an
untrusted network or system, such as a third party
or an employee accessing the entitys network using
his/her mobile computer. Internal LAN-to-LAN
access (for example, between two offices via secure
VPN) is not considered remote access for the
purposes of this requirement.
If remote access is to an entitys network that has

appropriate segmentation, such that remote users
cannot access or impact the cardholder data
environment, two- factor authentication for remote
access to that network would not required by PCI
DSS. However, two-factor authentication is required
for any remote access to networks with access to
the cardholder data environment, and is
recommended for all remote access to the entitys
networks.
8.4 Render all passwords unreadable during Many network devices and applications transmit the
transmission and storage on all system components user ID and unencrypted password across the
using strong cryptography. network and/or also store the passwords without
encryption. A malicious individual can easily
intercept the unencrypted or readable user ID and
password during transmission using a sniffer, or
directly access the user IDs and unencrypted
passwords in files where they are stored, and use
this stolen data to gain unauthorized access. During
transmission, the user credentials can be encrypted
or the tunnel can be encrypted
8.5 Ensure proper user identification and Since one of the first steps a malicious
authentication management for nonconsumer users individual will take to compromise a system is
and administrators on all system components as to exploit weak or nonexistent passwords, it is
follows: important to implement good processes for
user identification and authentication
8.5.1 Control addition, deletion, and modification management.
To ensure users added to your systems are all valid
of user IDs, credentials, and other identifier and recognized users, the addition, deletion, and
objects. modification of user IDs should be managed and
controlled by a small group with specific authority.
The ability to manage these user IDs should be
limited to only this small group.
8.5.2 Verify user identity before performing Many malicious individuals use "social
password resets. engineeringfor example, calling a help desk and
acting as a legitimate userto have a password
changed so they can utilize a user ID. Consider use
of a secret question that only the proper user can
answer to help administrators identify the user prior
to re-setting passwords. Ensure such questions are
secured properly and not shared.
8.5.3 Set passwords for first-time use and resets If the same password is used for every new user set
to a unique value for each user and change up, an internal user, former employee, or malicious
immediately after the first use. individual may know or easily discover this
password, and use it to gain access to accounts.
8.5.4 Immediately revoke access for any If an employee has left the company, and still has
terminated users. access to the network via their user account,
unnecessary or malicious access to cardholder
data could occur. This access could happen from
the former employee or from a malicious user
who exploits the older and/or unused account.
Consider implementing a process with Human
Resources for immediate notification when an
employee is terminated so that the user account
can be quickly deactivated.
8.5.5 Remove/disable inactive user accounts at Existence of inactive accounts allows an
least every 90 days. unauthorized user exploit the unused account to
potentially access cardholder data.
8.5.6 Enable accounts used by vendors for remote Allowing vendors (like POS vendors) to have 24/7
access only during the time period needed. access into your network in case they need to
Monitor vendor remote access accounts when in support your systems increases the chances of
use. unauthorized access, either from a user in the
vendors environment or from a malicious individual
who finds and uses this always-ready external entry
point into your network.
Monitoring of vendor access to the cardholder data
environment applies in the same way as it does for
other users, such as organizational personnel. This
includes monitoring and logging of activities as
required by PCI DSS Requirements 10.1 and 10.2,
and verifying that usage of vendor remote accounts
is in accordance with the policy as defined in
Requirements 12.3.8 and 12.3.9.
8.5.7 Communicate authentication procedures Communicating password/authentication

and policies to all users who have access to procedures to all users helps those users understand
cardholder data. and abide by the policies, and to be alert for any
malicious individuals who may attempt to exploit
their passwords to gain access to cardholder data
(for example, by calling an employee and asking for
their password so the caller can troubleshoot a
problem).
8.5.8 Do not use group, shared, or generic If multiple users share the same authentication
accounts and passwords, or other authentication credentials (for example, user account and
methods. password), it becomes impossible to assign
accountability for, or to have effective logging of, an
individuals actions, since a given action could have
been performed by anyone in the group that has
knowledge of the authentication credentials.
This requirement for unique IDs and complex

passwords is often met within administrative
functions by using, for example, sudo or SSH such
that the administrator initially logs on with their
own unique ID and password, and then connects to
the administrator account via sudo or SSH. Often
direct root logins are disabled to prevent use of this
shared administrative account. This way, individual
accountability and audit trails are maintained.
However, even with use of tools such as sudo and
SSH, the actual administrator IDs and passwords
should also meet PCI DSS requirements (if such
accounts are not disabled) to prevent them from
being misused.
8.5.9 Change user passwords at least every 90 Strong passwords are the first line of defense into a
days. network since a malicious individual will often first
try to find accounts with weak or non-existent
passwords. There is more time for a malicious
individual to find these weak accounts, and
compromise a network under the guise of a valid
user ID, if passwords are short, simple to guess, or
valid for a long time without a change. Strong
passwords can be enforced and maintained per
these requirements by enabling the password and
account security features that come with your
operating system (for example, Windows), networks,
databases and other platforms.
8.5.10 Require a minimum password length of at

least seven characters.
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 he or she has used.
8.5.13 Limit repeated access attempts by locking Without account-lockout mechanisms in place, an
out the user ID after not more than six attempts. attacker can continually attempt to guess a
password through manual or automated tools (for
example, password cracking), until they achieve
success and gain access to a users account.
8.5.14 Set the lockout duration to a minimum of If an account is locked out due to someone
30 minutes or until administrator enables the continually trying to guess a password, controls to
user ID. delay reactivation of these locked accounts stops
the malicious individual from continually guessing
the password (they will have to stop for a minimum
of 30 minutes until the account is reactivated).
Additionally, if reactivation must be requested, the
admin or help desk can validate that the account
owner is the cause (from typing errors) of the
lockout.
8.5.15 If a session has been idle for more than 15 When users walk away from an open machine with
minutes, require the user to re-authenticate to re- access to critical network or cardholder data, that
activate the terminal or session. machine may be used by others in the users
absence, resulting in unauthorized account access
and/or account misuse.
8.5.16 Authenticate all access to any database Without user authentication for access to databases
containing cardholder data. This includes access and applications, the potential for unauthorized or
by applications, administrators, and all other malicious access increases, and such access cannot
users. Restrict user direct access or queries to be logged since the user has not been authenticated
databases to database administrators. and is therefore not known to the system. Also,
database access should be granted through
programmatic methods only (for example, through
stored procedures), rather than via direct access to
the database by end users (except for DBAs, who
can have direct access to the database for their
administrative duties).
ach individual is uniquely accountable for his or her actions. When such accountability is in place, actions taken on critical data
Major Observations from the 2011 Verizon PCI Compliance report:
More than half of organizations failed to meet Requirement 8 at time of the IROC.
Of all the compliance validation tests for Requirement 8, organizations met an average of 77 percent at the time of IR
on-consumer users and administrators on all system components) and 8.5.7 (Communicate password procedures and policies to all users who have acce
words unreadable during transmission and storage on all system components using strong cryptography) and 8.5.10 (Require a minimum password leng
Most organizations do communicate their password policies and standards internally, but still experience difficulty enforcing them across

Top 20 Critical Security
Controls
C12.7 8.1 Verify that all users are assigned a unique ID for access to system components or
cardholder data.
C12.7 8.2 To verify that users are authenticated using unique ID and additional
authentication (for example, a password) for access to the cardholder data
environment, perform the following:
- Obtain and examine documentation describing the authentication method(s) used.

- For each type of authentication method used and for each type of system
component, observe an authentication to verify authentication is functioning
consistent with documented
authentication method(s).
C10.6 8.3 To verify that two-factor authentication is implemented for all remote network
C13.7 access, observe an employee (for example, an administrator) connecting remotely to
the network and verify that two of the three authentication methods are used.
C12.5 8.4.a For a sample of system components, examine password files to verify that
passwords are unreadable during transmission and storage.
8.4.b For service providers only, observe password files to verify that customer
passwords are encrypted.
8.5 Review procedures and interview personnel to verify that procedures are
implemented for user identification and authentication management, by performing
the following:
C16.9 8.5.1 Select a sample of user IDs, including both administrators and general users.
Verify that each user is authorized to use the system according to policy by
performing the following:
- Obtain and examine an authorization form for each ID.

- Verify that the sampled user IDs are implemented in accordance with the
authorization form (including with privileges as specified and all signatures
obtained), by tracing information from the authorization form to the system.
NC 8.5.2 Examine password/authentication procedures and observe security personnel

to verify that, if a user requests a password reset by phone, e-mail, web, or other
non-face-to-face method, the users identity is verified before the password is reset.
NC 8.5.3 Examine password procedures and observe security personnel to verify that
first-time passwords for new users, and reset passwords for existing users, are set to
a unique value for each user and changed after first use.
C16.3 8.5.4 Select a sample of users terminated in the past six months, and review current
user access lists to verify that their IDs have been deactivated or removed.
C16.5 8.5.5 Verify that inactive accounts over 90 days old are either removed or disabled.
C16.4 8.5.6.a Verify that any accounts used by vendors to access, support and maintain
system components are disabled, and enabled only when needed by the vendor.
8.5.6.b Verify that vendor remote access accounts are monitored while being used.
NC 8.5.7 Interview the users from a sample of user IDs, to verify that they are familiar
with authentication procedures and policies.
NC 8.5.8.a For a sample of system components, examine user ID lists to verify the
following:
- Generic user IDs and accounts are disabled or removed

- Shared user IDs for system administration activities and other critical functions do
not exist
- Shared and generic user IDs are not used to administer any system components
8.5.8.b Examine authentication policies/procedures to verify that group and shared
passwords or other authentication methods are explicitly prohibited.
8.5.8.c Interview system administrators to verify that group and shared passwords
or other authentication methods are not distributed, even if requested.
C12.3 8.5.9.a For a sample of system components, obtain and inspect system configuration
C16.7.2 settings to verify that user password parameters are set to require users to change
passwords at least every 90 days.
8.5.9.b For service providers only, review internal processes and customer/user
documentation to verify that non-consumer user passwords are required to change
periodically and that nonconsumer users are given guidance as to when, and under
what circumstances, passwords must change.
C12.1.2 8.5.10.a For a sample of system components, obtain and inspect system
C16.7 configuration settings to verify that password parameters are set to require
passwords to be at least seven characters long.
documentation to verify that that non-consumer user passwords are required to
meet minimum length requirements.
C16.7.1 8.5.11.a For a sample of system components, obtain and inspect system
configuration settings to verify that password parameters are set to require
passwords to contain both numeric and alphabetic characters.
documentation to verify that non-consumer user passwords are required to contain
both numeric and alphabetic characters.
C12.8 8.5.12.a For a sample of system components, obtain and inspect system
C1.7.3 configuration settings to verify that password parameters are set to require that new
passwords cannot be the same as the four previously used passwords.
documentation to verify that new non-consumer user passwords cannot be the
same as the previous four passwords.
C16.8 8.5.13.a For a sample of system components, obtain and inspect system
configuration settings to verify that authentication parameters are set to require
that a users account be locked out after not more than six invalid logon attempts.
documentation to verify that non-consumer user accounts are temporarily locked-
out after not more than six invalid access attempts.
C16.8.1 8.5.14 For a sample of system components, obtain and inspect system configuration
settings to verify that password parameters are set to require that once a user
account is locked out, it remains locked for a minimum of 30 minutes or until a
system administrator resets the account.
C16.4 8.5.15 For a sample of system components, obtain and inspect system configuration
settings to verify that system/session idle time out features have been set to 15
minutes or less.
NC 8.5.16.a Review database and application configuration settings and verify that all
users are authenticated prior to access.
8.5.16.b Verify that database and application configuration settings ensure that all
user access to, user queries of, and user actions on (for example, move, copy,
delete), the database are through programmatic methods only (for example,
through stored procedures).
8.5.16.c Verify that database and application configuration settings restrict user
direct access or queries to databases to database administrators.
8.5.16.d Review database applications and the related application IDs to verify that
application IDs can only be used by the applications (and not by individual users or
other processes).
e, actions taken on critical data and systems are performed by, and can be traced to, known and authorized users.
iance report:
8 at time of the IROC.
erage of 77 percent at the time of IROC.
nd policies to all users who have access to cardholder data) rate among the best implemented compliance test procedures within the main compliance r
0 (Require a minimum password length of at least seven characters) were the least compliant at the time of IROC.
ence difficulty enforcing them across all computing devices.

Identify the document requiring that the users are assigned a unique userId before 4
beingallowed to access system components or cardholder data
Describe how implemented access control systems were observed to assign unique Ids
for access to system components and cardholder data
Descibe how IDs with access to system components anc cardholder data were
observed be unique.
Identify the document describing the authentication method(s) used, and confirm that 4
the methods require users to be authenticated using a unique ID and additional
authentication for access to the cardholder data environment.
Describe the authentication methods used (for example, a password or passphrase, a
token device or smart card, a biometric, etc.), for each type of system component.
For each type of authentication method used and for each type of system component:
i. Describe how the authentication method was observed to be used for access to the
cardholder data environment.
ii. Describe how the authentication method was observed to be functioning consistent
with the documented authentication method(s).
Identify the document that requires two-factor authentication for remote access by: 4
i. Employees (users)
ii. Administrators
iii. Third parties
Describe the two-factor authentication technologies implemented for remote access
to the network.
For each identified technology:
Identify the personnel (for example, an administrator) observed connecting remotely
to the network.
Describe how two-factor authentication was observed to be required for remote
access to the network.
Identify which two factors are used:
Something you know, Something you are, Something you have.

For each sampled system component, describe how the observed password files
verify that
passwords are unreadable during:
i. Transmission
ii.Storage
For each sampled system component, describe how the observed system configuration
settings verify that strong cryptography is used for passwords during:
I.Transmission
ii. Storage
If the entity being assessed is a service provider: 4

Describe how observed customer password files verify that customer passwords are
encrypted during:
i. Transmission ii. Storage
Describe how observed system configuration settings confirm that customer passwords
are rendered unreadable using strong cryptography during:
i. Transmission ii. Storage
4
Identify the samples of: Administrator and General userIDs 4

For each sampled administrator user ID, describe how the observed authorization
forms andsystem settings confirm that:
The adminitrator userId is implemented in accordance with the authorization form
and with the privileges specified on this form with all appropriated signatures
otained.
For each sample general USerID describe how the authorization form and system
settings confirm that:
The userId is implemented in accordance with the authorization form and with the
privileges specified on this form with all appropriated signatures otained.
Describe the non-face-to-face methods used for requesting password resets. For 4
each of these method:
Identify therelated documented procedures and confirmthe procedures requires
the userId's identity to be verified before the password is reset.
Describe how security personnel responsible for resetting passwords were observed
to verify user identities beforesetting the passwords.
Identify the documented procedures for issuing first-time passwords for new users, 4
and confirm the procedures require:
i. First-time passwords must be set to a unique value for each user.
ii. First-time passwords must be changed after the first use.
Describe how security personnel responsible for assigning first-time passwords were
observed to:
i. Set first-time passwords to a unique value for each new user.
ii. Set first-time passwords to be changed after first use.
Identify the documented procedures for resetting passwords for existing users,
and confirm the procedures require:
Reset passwords must be set to a unique value for each user.
ii. Reset passwords must be changed after the first use.
Describe how security personnel responsible for resetting passwords were observed
to:
i. Set reset passwords to a unique value for each existing user.
ii. Set reset passwords to be changed after first use.
Identify the document requiring that access be immediately revoked for any 4
terminated users. Identify the sample of users terminated in the past six months.
For each sampled user, describe how the user account was observed to be
deactivated or removed from user access lists.
Identify the document requiringthat inactive user accounts over 90 daysold are 4
either removed or disabled.
Describe how user accounts inactive over 90 days old were observed to be disabled
or removed.
dentify the document requiring that accounts used by vendors to access, support 4
and maintain system components are:
i. Disabled when not being used
ii. Enabled only when needed
Briefly describe the implemented processes for:
i. Disabling vendor accounts when not being used.
ii. Enabling vendor accounts only when needed.
Describe how vendor accounts were observed to be enabled or disabled according
to the documented processes.
Identify the document requiring that accounts used by vendors are monitored while 4
being used. Describe how vendor accounts were observed to be monitored while
being used.
Identify the sample of user IDs. 4
For each user ID in the sample, describe how the interviewed users demonstrated
that they are familiar with authentication procedures and policies.

For each sampled system component, describe how observed user ID lists verify
that:
i. Generic user IDs and accounts are disabled or removed.
ii. Shared user IDs for system administration activities and other critical functions do
not exist.
For each sampled system component, identify personnel with administrator IDs who
were interviewed, and who confirm that:
i. Shared user IDs are not used to administer any system components.
ii. Generic user IDs are not used to administer any system components.
Identify the documented policies/procedures which explicitly prohibit: 4
Group and shared password or other authentication methods
Identify the system administrators interviewed who verify that the following are 4
never distributed, even if requested:
i. Group passwords or other authentication methods
ii. Shared passwords or other authentication methods
Identify the sample of system components observed. For each sampled system 4
component:
i. Describe the system configuration settings inspected.
ii. Identify how often users are required to change their passwords, as observed in
the system
configuration settings.

Identify the customer/user documentation that provide the following guidance to
non-consumer users:
When to change their passwords and under what circumstances passwords must be
changed
Describe how the documented guidance was observed
Describe how the service provider processesuser passwords were observed to
include:
periodic password changes, details whenand under which circumstances passwords
must be change;
component:
ii. Identify the required minimum password length observed in the system
configuration
settings.
Identify the customer/user documentation that requires non-consumer user
passwords to meet minimum length requirements.
Describe how the observed processes confirm that non-consumer user passwords
meet minimum password-length requirements.
component:
ii. Identify the types of characters required for passwords, as observed in the system
configuration settings.

passwords to use both numeric and alphabetic characters.
contain both numeric and alphabetic characters.
Identify the sample of system components observed. For each sampled system 4 ###
component:
Describe the system configuration settings inspected.
Identify the number of previously used passwords that cannot be the same as a new
password, as observed in the system configuration settings.

Identify the customer/user documentation that requires new non-consumer user
passwords to not be the same as the previous four passwords.
Describe how the observed processes confirm that new non-consumer user
passwords cannot be the same as the previous four passwords.
component:
ii. Identify the number of invalid logon attempts that result in user accounts being
locked out, as observed in the system configuration settings.

passwords to be temporarily locked out after not more than six invalid access
attempts.
are temporarily locked out after no more than six invalid access attempts.
component:
Identify which of the following was observed to be required once a user account is
locked out:
The user account remains locked for a minimum of 30 minutes; or
The user account remains locked until a system administrator resets the account.
component:
i. Describe the system configuration settings which were inspected.
ii. Identify to what time (in minutes) that system and/or session idle time-out
features are set,
as observed in the system configuration settings.
iii. Describe how the system and/or session idle time-out features were observed to
require
the user to re-authenticate to re-activate the terminal or session.
Identify all databases containing cardholder data. For each database containing 4 ###
cardholder data:
i. Describe how authentication is managed (for example, via application and/or
database interfaces).
ii. Describe how database and/or application configuration settings were observed
to authenticate all users prior to access.
For each database containing cardholder data: 4 ###

i. Describe how the observed database and application configuration settings ensure
that only programmatic methods are used for:
o All user access to the database
o All user queries of the database
o All user actions on the database (for example, move, copy, delete)
ii. Describe how it was observed that only programmatic methods are used for: o All
user access to the database
o All user queries of the database
o All user actions on the database (for example, move, copy, delete)
For each database containing cardholder data, describe how database and 4 ###
application configuration settings were observed to restrict the following to only
database administrators:
i.User direct access to the database
ii.User direct queries to the database
For each database containing cardholder data: 4 ###

i. Identify applications with access to the database.
ii. Describe the implemented methods for ensuring that application IDs can only be
used by the applications, and not by:
o Individual users
o Other processes
iii. Describe how the methods were observed to ensure that application IDs cannot
be used by:
o Individual users
o Other processes
132 ###0 0 0
ed users.
thin the main compliance requirements.

Documentation links
1 N 4
1 N 4
1 1 N 4
1 N 4
1 N 4
1 N 4
1 N 4
1 N 4
1 N 4
1 N 4
1 N 4
1 1 N 4
1 1 N 4
1 N 4
1 N 4
1 N 4
1 N 4
1 N 4
1 N 4
1 N 4
1 N 4
1 N 4
1 N 4
1 N 4
1 N 4
1 N 4
1 N 4
1 N 4
1 N 4
1 N 4
1 N 4
1 N 4
1 N 4
3 33 Y 132
N
C
Requirement 9: Restrict physical access to cardholder data
Any physical access to data or systems that house cardholder data provides the opportunity for individuals to access
personnel, service workers, or anyone who needs to enter the facility for a short duration, usually not more than on
Sub-requirements 9.3, 9.4 (employe
Only
On average, 84 percent of
The most challenging sub-control, a
9.1 Use appropriate facility entry controls to limit Without physical access controls, unauthorized
and monitor physical access to systems in the persons could potentially gain access to the building
cardholder data environment. and to sensitive information, and could alter system
configurations, introduce vulnerabilities into the
network, or destroy or steal equipment.
9.1.1 Use video cameras and/or access control When investigating physical breaches, these controls
mechanisms to monitor individual physical access can help identify individuals that physically access
to sensitive areas. Review collected data and those sensitive areas storing cardholder data.
correlate with other entries. Store for at least Examples of sensitive areas include corporate
three months, unless otherwise restricted by law. database server rooms, back-end server room of a
retail location that stores cardholder data, and
Note: Sensitive areas refers to any data center, storage areas for large quantities of cardholder data,
server room or any area that houses systems that
store, process, or transmit cardholder data. This
excludes the areas where only point-of-sale
terminals are present, such as the cashier areas in
a retail store.
9.1.2 Restrict physical access to publicly Restricting access to network jacks will prevent
accessible network jacks. For example, areas malicious individuals from plugging into readily
accessible to visitors should not have network available network jacks that may allow them access
ports enabled unless network access is explicitly into internal network resources. Consider turning off
authorized. network jacks while not in use, and reactivating
them only while needed. In public areas such as
conference rooms, establish private networks to
allow vendors and visitors to access Internet only so
that they are not on your internal network.
9.1.3 Restrict physical access to wireless access Without security over access to wireless
points, gateways, handheld devices, components and devices, malicious users could use
networking/communications hardware, and your organizations unattended wireless devices to
telecommunication lines. access your network resources, or even connect
their own devices to your wireless network to gain
unauthorized access. Additionally, securing
networking and communications hardware prevents
malicious users from intercepting network traffic or
physically connecting their own devices to your
wired network resources.
Consider placing wireless access points, gateways

and networking/ communications hardware in
secure storage areas, such as within locked closets
or server rooms. For wireless networks, ensure
strong encryption is enabled. Also consider enabling
automatic device lockout on wireless handheld
devices after a long idle period, and set your devices
to require a password when powering on.
9.2 Develop procedures to easily distinguish Without badge systems and door controls,
between onsite personnel and visitors, especially in unauthorized and malicious users can easily gain
areas where cardholder data is accessible. access to your facility to steal, disable, disrupt, or
destroy critical systems and cardholder data. For
optimum control, consider implementing badge or
card access system in and out of work areas that
contain cardholder data.
Identifying authorized visitors so they are easily
distinguished from onsite personnel prevents
unauthorized visitors from being granted access to
areas containing cardholder data.
9.3 Make sure all visitors are handled as follows: Visitor controls are important to reduce the ability
of unauthorized and malicious persons to gain
access to your facilities (and potentially, to
cardholder data).
9.3.1 Authorized before entering areas where Visitor controls are important to ensure visitors only
cardholder data is processed or maintained. enter areas they are authorized to enter, that they
are identifiable as visitors so personnel can monitor
their activities, and that their access is restricted to
just the duration of their legitimate visit.
9.3.2 Given a physical token (for example, a badge

or access device) that expires and that identifies
the visitors as not onsite personnel.
9.3.3 Asked to surrender the physical token

before leaving the facility or at the date of
expiration.
9.4 Use a visitor log to maintain a physical audit trail A visitor log documenting minimum information on
of visitor activity. Document the visitors name, the the visitor is easy and inexpensive to maintain and
firm represented, and the onsite personnel will assist, during a potential data breach
authorizing physical access on the log. Retain this investigation, in identifying physical access to a
log for a minimum of three months, unless building or room, and potential access to cardholder
otherwise restricted by law. data. Consider implementing logs at the entry to
facilities and especially into zones where cardholder
data is present.
9.5 Store media back-ups in a secure location, If stored in a non-secured facility, backups that
preferably an off-site facility, such as an alternate or contain cardholder data may easily be lost, stolen,
back-up site, or a commercial storage facility. Review or copied for malicious intent. For secure storage,
the locations security at least annually. consider contracting with a commercial data storage
company OR, for a smaller entity, using a safe-
deposit box at a bank.
9.6 Physically secure all media. Cardholder data is susceptible to unauthorized

viewing, copying, or scanning if it is unprotected
while it is on removable or portable media, printed
out, or left on someones desk.
9.7 Maintain strict control over the internal or Procedures and processes help protect cardholder
external distribution of any kind of media, including data on media distributed to internal and/or
the following: external users. Without such procedures data can be
lost or stolen and used for fraudulent purposes.
9.7.1 Classify media so the sensitivity of the data It is important that media be identified such that its
can be determined. classification status can be easily discernable. Media
not identified as confidential may not be adequately
protected or may be lost or stolen
9.7.2 Send the media by secured courier or other

delivery method that can be accurately tracked. Media may be lost or stolen if sent via a non-
trackable method such as regular postal mail. Use
the services of a secure courier to deliver any
media that contains cardholder data, so that you
can use their tracking systems to maintain
inventory and location of shipments.
9.8 Ensure management approves any and all media Cardholder data leaving secure areas without a
that is moved from a secured area (especially when process approved by management can lead to lost
media is distributed to individuals). or stolen data. Without a firm process, media
locations are not tracked, nor is there a process for
where the data goes or how it is protected.
9.9 Maintain strict control over the storage and Without careful inventory methods and storage
accessibility of media. controls, stolen or missing media could go
unnoticed for an indefinite amount of time.
9.9.1 Properly maintain inventory logs of all If media is not inventoried, stolen or lost media
media and conduct media inventories at least may not be noticed for a long time or at all.
annually.
9.10 Destroy media when it is no longer needed for If steps are not taken to destroy information
business or legal reasons as follows: contained on hard disks, portable drives, CD/DVDs,
or paper prior to disposal, malicious individuals may
be able to retrieve information from the disposed
media, leading to a data compromise. For example,
malicious individuals may use a technique known as
dumpster diving, where they search through trash
cans and recycle bins looking for information they
can use to launch an attack.
Examples of methods for securely destroying

electronic media include secure wiping, degaussing,
or physical destruction (such as grinding or
shredding hard disks).
9.10.1 Shred, incinerate, or pulp hardcopy

materials so that cardholder data cannot be
reconstructed.
9.10.2 Render cardholder data on electronic
media unrecoverable so that cardholder data
cannot be reconstructed.
opportunity for individuals to access devices or data and to remove systems or hardcopies, and should be appropriately restric
rt duration, usually not more than one day. Media refers to all
Major Observations paper
from andVerizon
the 2011 electronic mediaReport:
Compliance containing cardholder data
Sub-requirements 9.3, 9.4 (employee/visitor controls), and 9.6 (secure physical delivery) rate among the best implemented compliance test pro
Only about half (55 percent) of organizations fully met Requirement 9 at the time of IROC.
On average, 84 percent of tests were fully met in Requirement 9 at the time of IROC, a seven percent reduction from our 2010 results.
The most challenging sub-control, at time of IROC, is 9.9.1: Properly maintain inventory logs of all media and conduct media inventories at least

Top 20 Critical
Security Controls
NC Verify the existence of physical security controls for each computer room, data center,
and other physical areas with systems in the cardholder data environment.
- Verify that access is controlled with badge readers or other devices including
authorized badges and lock and key.
- Observe a system administrators attempt to log into consoles for randomly selected
systems in the cardholder environment and verify that they are locked to prevent
unauthorized use.
NC 9.1.1.a Verify that video cameras and/or access control mechanisms are in place to
monitor the entry/exit points to sensitive areas.
9.1.1.b Verify that video cameras and/or access control mechanisms are protected
from tampering or disabling.
9.1.1.c Verify that video cameras and/or access control mechanisms are monitored
and that data from cameras or other mechanisms is stored for at least three
months.
NC 9.1.2 Verify by interviewing network administrators and by observation that network

jacks are enabled only when needed by authorized onsite personnel. Alternatively,
verify that visitors are escorted at all times in areas with active network jacks.
NC 9.1.3 Verify that physical access to wireless access points, gateways, handheld
devices, networking/communications hardware, and telecommunication lines is
appropriately restricted.
NC 9.2.a Review processes and procedures for assigning badges to onsite personnel and
visitors, and verify these processes include the following:
- Granting new badges,

- Changing access requirements, and
- Revoking terminated onsite personnel and expired visitor badges
9.2.b Verify that access to the badge system is limited to authorized personnel.
9.2.c Examine badges in use to verify that they clearly identify visitors and it is easy to
distinguish between onsite personnel and visitors.
9.3 Verify that visitor controls are in place as follows:
NC 9.3.1 Observe the use of visitor ID badges to verify that a visitor ID badge does not
permit unescorted access to physical areas that store cardholder data.
NC 9.3.2.a Observe people within the facility to verify the use of visitor ID badges, and
that visitors are easily distinguishable from onsite personnel.
9.3.2.b Verify that visitor badges expire.

NC 9.3.3 Observe visitors leaving the facility to verify visitors are asked to surrender
their ID badge upon departure or expiration.
NC 9.4.a Verify that a visitor log is in use to record physical access to the facility as well as
for computer rooms and data centers where cardholder data is stored or transmitted.
9.4.b Verify that the log contains the visitors name, the firm represented, and the
onsite personnel authorizing physical access, and is retained for at least three months.
C8.4 9.5.a Observe the storage locations physical security to confirm that backup media
storage is secure.
9.5.b Verify that the storage location security is reviewed at least annually.
C8.4 9.6 Verify that procedures for protecting cardholder data include controls for physically
securing all media (including but not limited to computers, removable electronic
media, paper receipts, paper reports, and faxes).
NC 9.7 Verify that a policy exists to control distribution of media, and that the policy
covers all distributed media including that distributed to individuals.
NC 9.7.1 Verify that all media is classified so the sensitivity of the data can be
determined.
NC 9.7.2 Verify that all media sent outside the facility is logged and authorized by
management and sent via secured courier or other delivery method that can be
tracked.
NC 9.8 Select a recent sample of several days of offsite tracking logs for all media, and
verify the presence in the logs of tracking details and proper management
authorization.
NC 9.9 Obtain and examine the policy for controlling storage and maintenance of all
media and verify that the policy requires periodic media inventories.
NC 9.9.1 Obtain and review the media inventory log to verify that periodic media
inventories are performed at least annually.
NC 9.10 Obtain and examine the periodic media destruction policy and verify that it
covers all media, and confirm the following:
NC 9.10.1.a Verify that hard-copy materials are crosscut shredded, incinerated, or

pulped such that there is reasonable assurance the hard-copy materials cannot be
reconstructed.
9.10.1.b Examine storage containers used for information to be destroyed to verify

that the containers are secured. For example, verify that a to-be-shredded
container has a lock preventing access to its contents.
NC 9.10.2 Verify that cardholder data on electronic media is rendered unrecoverable via
a secure wipe program in accordance with industry-accepted standards for secure
deletion, or otherwise physically destroying the media (for example, degaussing).
and should be appropriately restricted. For the purposes of Requirement 9, onsite personnel refers to full-time and part-time e
containing
eport: cardholder data
he best implemented compliance test procedures.
t the time of IROC.
percent reduction from our 2010 results.
ia and conduct media inventories at least annually.

Identify and briefly describe all computer rooms, data centers and other physical areas
with systems in the cardholder data environment.
For each area identified:
Describe the physical security controls observed.
Describe how access was observed to be controlled with badge readers or other
devices, including authorized badges and lock and key.
Identify the number of randomly selected systems in the cardholder environment for 2
which a system administrator login attempt was observed.
Describe how consoles for the randomlys elected systems were observed to be
"locked.
Identify and briefly describe all sensitive areas. For each identified sensitive area:
i. Describe the video cameras and/or access control mechanisms observed to
monitor the entry/exit points.
ii. Describe how the video cameras and/or access control mechanisms were 2
observed to monitor individual physical access to the sensitive area.
Describe how the video cameras and/or access control mechanisms were observed
to be protected from:
i. Tampering ii. Disabling 2
Describe how the video cameras and/or access control mechanisms were observed
to be monitored.
Describe how data from cameras and/or other mechanisms was observed to be
reviewed and correlated with other entries.
Describe how data from the cameras and/or access control mechanisms was 2
observed to be stored for at least three months.
Identify the network administrator interviewed who confirm that either:

Publicly accessible network jacks are enabled when needed by authorized personnel
Visitors are excorted at all times in areas with actibe jacks.
Describe how the here above processes were observed.
2
Describe how physical access was observed to be restricted to:
i. Wireless access points
ii. Wireless gateways
iii. Wireless handheld devices
iv. Network/communications hardware
v. Telecommunication lines
Identify the documented processes and procedures for assigning badges to onsite 5
personnel, and verify the processes include:
i. Granting new badges
ii. Changing access requirements
iii. Revoking badges for terminated onsite personnel
Describe how the documented procedures for assigning badges to onsite personnel
were observed to be implemented, including:
iii. Revoking badges for terminated onsite personnel
Identify the documented processes and procedures for assigning badges to visitors,
and verify the processes include:
iii. Expiration of visitor badges
Describe how the documented procedures for assigning badges to visitors were
observed to be implemented, including:
iii. Expiration of visitor badges
Identify the document which identifies personnel who are authorized to access the 5
badge system.
Describe how access to the badge system was observed to be restricted to
authorized personnel.
Briefly describe the badges observed for onsite personnel and visitors. Describe how 5
badges clearly identify visitors.
Describe how badges distinguish onsite personnel from visitors.
5
Describe how the use of visitor badges was observed to verify that the visitor ID 5
badge does not permit unescorted access to physical areas that store cardholder
data.
Describe how people within the facility were observed to use visitor ID badges. 5
Describe how observed visitors within the facility are easily distinguished from
onsite personnel.
Describe how visitor badges were observed to expire. 5

Describe how observed visitors were asked to surrender their ID badge upon 5
departure or expiration.
Describe how a visitor log was observed to be in use to record physical access to: 5
The facility
Computer rooms and data centers where cardholder data is stored or transmitted
Describe how the visitor log was observed to contain: i. Visitor name 5
ii. Firm represented
iii. Onsite personnel authorizing physical access
Identify the defined retention period for visitor logs.
Describe how visitor logs were observed to be retained for at least three months.
Identify all locations where backup media is stored. 5

Describe how the observed physical security of each storage area ensures that
backup media is
stored securely.
Identify the document that defines the process for reviewing the security of each 5
storage location at least annually.
Describe how it was observed that reviews of the security of each storage location
are performed at least annually.
Identify the documented procedures for protecting cardholder data, and confirm that 5 1 1
the procedures include controls for physically securing all media.
For each type of media used:
i. Briefly describe the controls for physically securing the media.
ii. Describe how the documented controls were observed to be implemented
Identify the policy document that defines controls for distribution of media. Describe 5 1 1
how the policy covers all distributed media.
Describe how the policy covers media distributed to individuals.
Identify the document that defines how media are classified 5 1 1
Briefly describe how media is classiffied to determined sensitivity of the data
Describe how the classification were observed.
Describe how it was observed that all media sent outside the facility is: i. Logged 5 1 1
ii. Authorized by management
iii. Sent via secured courier or other delivery method that can be accurately tracked.
Identify the sample of offsite tracking logs for all media. 5 1 1

For each item in the sample, describe how the logs were observed to include:
i. Tracking details
ii. Proper management authorization
Identify the policy document that defines requirements for: i. Controlling storage of all 5 1 1
media
ii. Controlling maintenance of all media iii. Periodic inventories for all media
Describe how the policy requirements were observed to be implemented for:
i. Controlling storage of all media
ii. Controlling maintenance of all media
iii. Performing periodic inventories for all media
Identify the document that describes the process for conducting media inventories 5
at least annually.
Describe how media inventory logs of all media were observed to be maintained.
Describe how it was observed that media inventories are performed at least
annually.
Identify the policy document that defines media destruction requirements. Confirm 1 1
that the policy covers all media.
Describe the documented process for destruction of hardcopy materials. 1 1

Describe how the observed process provides reasonable assurance that hardcopy 1
materials cannot be reconstructed.
Describe how the containers used for storing information to be destroyed were 1 1
observed to be secured.
1
Describe the documented process for destruction of electronic media, including
details of methods used for:
i. Secure wiping of media, and/or
ii. Physical destruction of media
Describe how the observed processes ensure that data is rendered unrecoverable. 1
If data is rendered unrecoverable via secure deletion or a secure wipe program,
identify the industry-accepted standards used.
111 9 9
full-time and part-time employees, temporary employees, contractors and consultants who are physically present on the entity
C-VT C D In Place? I Severity Proofs /

n Documentation links
t
e
1 N N
r 2
m
e
d
i
a
r
y
C
o
n
1 N tN 2
r
o
l
1 N N 2
1 N N 2
1 N N 2
1 N N 2
1 N N 5
1 N N 5
1 N N 5
1 N N 5
1 N N 5
1 N N 5
1 N N 5
1 N N 5
1 N N 5
1 N N 5
1 N N 5
1 N N 5
1 1 1 N N 5
1 1 1 N N 5
1 1 1 N N 5
1 1 1 N N 5
1 1 1 N N 5
1 1 1 N N 5
1 N N 5
1 1 1 N N 1
1 1 1 N N 1
1 1 1 N N 1
1 N N 1
9 9 29 Y 111
N
C
sultants who are physically present on the entitys premises. A visitor refers to a vendor, guest of any onsite
Stage of implementation Remediation plan Estimated date for completion

Comment Owner
s
Requirement 10: Track and monitor all access to network resources and cardholder data
Logging mechanisms and the ability to track user activities are critical in preventing, detecting, or minimizing the impact of a data comprom

Requirement 10 is historically one of the most challenging key controls to meet.
52 percent of organizations fully met Requirement 10 at the time of IROC, representing a 13 percent increase from last years data set.
On average, organizations met 70 percent of tests in Requirement 10 at time of IROC, a five percent decrease from 2010.
The most challenging sub-control appears to be 10.5.5: Use file-integrity monitoring or change-detection software on logs to ensure that e
Other pitfalls towards compliance with Requirement 10 are the failure or inability to invest in a capable automated tool (log aggregator) to
10.1 Establish a process for linking all access to It is critical to have a process or system that links
system components (especially access done with user access to system components accessed, and in
administrative privileges such as root) to each particular, for those users with administrative
individual user. privileges. This system generates audit logs and
provides the ability to trace back suspicious activity
to a specific user. Post-incident forensic teams
heavily depend on these logs to initiate the
investigation.
10.2 Implement automated audit trails for all system Generating audit trails of suspect activities alerts the
components to reconstruct the following events: system administrator, sends data to other
monitoring mechanisms (like intrusion detection
systems), and provides a history trail for post-
incident follow-up. Logging of the following events
enables an organization to identify and trace
potentially malicious activities.
10.2.1 All individual accesses to cardholder data Malicious individuals could obtain knowledge of a
user account with access to systems in the CDE,
or they could create a new, unauthorized account
in order to access cardholder data. A record of all
individual accesses to cardholder data can
identify which accounts may have been
compromised or misused.
10.2.2 All actions taken by any individual with Accounts with increased privileges, such as the
root or administrative privileges administrator or root account, have the
potential to greatly impact the security or
operational functionality of a system. Without a
log of the activities performed, an organization is
unable to trace any issues resulting from an
administrative mistake or misuse of privilege back
to the specific action and individual.
10.2.3 Access to all audit trails Malicious users often attempt to alter audit logs
to hide their actions, and a record of access
allows an organization to trace any
inconsistencies or potential tampering of the logs
to an individual account,
10.2.4 Invalid logical access attempts Malicious individuals will often perform multiple
access attempts on targeted systems. Multiple
invalid login attempts may be an indication of an
unauthorized users attempts to brute force or
guess a password.
10.2.5 Use of identification and authentication Without knowing who was logged on at the time
mechanisms of an incident, it is impossible to identify the
accounts which may be used. Additionally,
malicious users may attempt to manipulate the
authentication controls with the intent of
bypassing them or impersonating a valid account.
Activities including, but not limited to, escalation
of privilege or changes to access permissions may
indicate unauthorized use of a systems
authentication mechanisms.
10.2.6 Initialization of the audit logs Turning the audit logs off prior to performing
illicit activities is a common goal for malicious
users wishing to avoid detection. Initialization of
audit logs could indicate that the log function was
disabled by a user to hide their actions.
10.2.7 Creation and deletion of system-level Malicious software, such as malware, often
objects creates or replaces system level objects on the
target system in order to control a particular
function or operation on that system.
Please refer to the PCI DSS and PA-DSS Glossary of
Terms, Abbreviations, and Acronyms for
definitions of system-level objects.
10.3 Record at least the following audit trail entries By recording these details for the auditable events
for all system components for each event: at 10.2, a potential compromise can be quickly
identified, and with sufficient detail to know who,
what, where, when, and how.
10.3.1 User identification
10.3.2 Type of event

10.3.3 Date and time
10.3.4 Success or failure indication
10.3.5 Origination of event
10.3.6 Identity or name of affected data, system

component, or resource.
10.4 Using time-synchronization technology, Time synchronization technology is used to

synchronize all critical system clocks and times and synchronize clocks on multiple systems. When
ensure that the following is implemented for properly deployed, this technology can synchronize
acquiring, distributing, and storing time. clocks on large numbers of systems to within a
fraction of a second of each other. Some problems
Note: One example of time synchronization that can occur when clocks are not properly
technology is Network Time Protocol (NTP). synchronized include but are not limited to, making
it difficult if not impossible to compare log files from
different systems and establish an exact sequence of
event (crucial for forensic analysis in the event of a
breach), and preventing cryptographic protocols
such as SSH that rely on absolute time from
functioning properly. For post-incident forensics
teams, the accuracy and consistency of time across
all systems and the time of each activity is critical in
determining how the systems were compromised.
Note: One
example of time synchronization technology is
Network Time Protocol (NTP).
If a malicious individual has entered the network,
they will often attempt to change the time stamps of
their actions within the audit logs to prevent
detection of their activity. A malicious individual
may also try to directly change the clock on a system
component to hide their presence for example, by
changing the system clock to an earlier time. For
these reasons, it is important that time is accurate
on all systems and that time data is protected
against unauthorized access and changes. Time data
includes the parameters and methods used to set
each systems clock.
More information on NTP can be found at

www.ntp.org, including information about time,
time standards, and servers.
www.ntp.org, including information about time,
time standards, and servers.
10.4.1 Critical systems have the correct and

consistent time.
10.4.2 Time data is protected.

10.4.3 Time settings are received from industry-
accepted time sources.
10.5 Secure audit trails so they cannot be altered. Often a malicious individual who has entered the
network will attempt to edit the audit logs in order
to hide their activity. Without adequate protection
of audit logs, their completeness, accuracy, and
integrity cannot be guaranteed, and the audit logs
can be rendered useless as an investigation tool
after a compromise.
10.5.1 Limit viewing of audit trails to those with a Adequate protection of the audit logs includes
job-related need. strong access control (limit access to logs based on
need to know only) and use of internal
segregation (to make the logs harder to find and
modify). By writing logs from external-facing
technologies such as wireless, firewalls, DNS, and
mail servers, the risk of those logs being lost or
altered is lowered, as they are more secure within
technologies such as wireless, firewalls, DNS, and
mail servers, the risk of those logs being lost or
altered is lowered, as they are more secure within
10.5.2 Protect audit trail files from unauthorized

modifications.
10.5.3 Promptly back up audit trail files to a

centralized log server or media
that is difficult to alter.
10.5.4 Write logs for external-facing technologies

onto a log server on the internal LAN.
10.5.5 Use file-integrity monitoring or change- File-integrity monitoring systems check for
detection software on logs to ensure that existing changes to critical files, and notify when such
log data cannot be changed without generating changes are noted. For file-integrity monitoring
alerts (although new data being added purposes, an entity usually monitors files that
should not cause an alert). dont regularly change, but when changed
indicate a possible compromise. For log files
(which do change frequently) what should be
monitored are, for example, when a log file is
deleted, suddenly grows or shrinks significantly,
and any other indicators that a malicious
individual has tampered with a log file. There are
both off-the-shelf and open source tools available
for file-integrity monitoring.
10.6 Review logs for all system components at least Many breaches occur over days or months before
daily. Log reviews must include those servers that being detected. Checking logs daily minimizes the
perform security functions like intrusion-detection amount of time and exposure of a potential breach.
system (IDS) and authentication, authorization, and The log- review process does not have to be manual.
accounting protocol (AAA) servers (for example, Especially for those entities with a large number of
RADIUS). servers, consider use of log harvesting, parsing, and
alerting tools.
Note: Log harvesting, parsing, and alerting tools
may be used to meet compliance with Requirement
10.6.
10.7 Retain audit trail history for at least one year, Retaining logs for at least a year allows for the fact
with a minimum of three months immediately that it often takes a while to notice that a
available for analysis (for example, online, archived, compromise has occurred or is occurring, and allows
or restorable from back-up). investigators sufficient log history to better
determine the length of time of a potential breach
and potential system(s) impacted. By having three
months of logs immediately available, an entity can
quickly identify and minimize impact of a data
breach. Storing back-up tapes off-site may result in
longer time frames to restore data, perform
analysis, and identify impacted systems or data.
older data
or minimizing the impact of a data compromise. The presence of logs in all environments allows thorough tracking, alerting, and analysis when somethi
ercent increase from last years data set.

rcent decrease from 2010.
-detection software on logs to ensure that existing log data cannot be changed without generating alerts. File- integrity monitoring can be extremely com
capable automated tool (log aggregator) to monitor logs on a daily basis, not maintaining security procedures to trigger a response to an exception rep

Top 20 Critical
Security Controls
C17.2 10.1 Verify through observation and interviewing the system administrator, that audit
trails are enabled and active for system components.
C14.1 10.2 Through interviews, examination of audit logs, and examination of audit log
C14.6 settings, perform the following:
C.14.3 10.2.1 Verify all individual access to cardholder data is logged.
C12.9 10.2.2 Verify actions taken by any individual with root or administrative privileges
C12.10 are logged.
NC 10.2.3 Verify access to all audit trails is logged.
C14.3 10.2.4 Verify invalid logical access attempts are logged.
NC 10.2.5 Verify use of identification and authentication mechanisms is logged.
NC 10.2.6 Verify initialization of audit logs is logged.
C.14.3 10.2.7 Verify creation and deletion of system level objects are logged.
C14.1 10.3 Through interviews and observation, for each auditable event (from 10.2),
perform the following:
NC 10.3.1 Verify user identification is included in log entries.
NC 10.3.2 Verify type of event is included in log entries.

NC 10.3.3 Verify date and time stamp is included in log entries.
C14.3 10.3.4 Verify success or failure indication is included in log entries.
NC 10.3.5 Verify origination of event is included in log entries.
NC 10.3.6 Verify identity or name of affected data, system component, or resources is

included in log entries.
C.14.5 10.4.a Verify that time-synchronization technology is implemented and kept current
per PCI DSS Requirements 6.1 and 6.2.
10.4.b Obtain and review the process for acquiring, distributing and storing the correct
time within the organization, and review the time-related system-parameter settings
for a sample of system components. Verify the following is included in the process and
implemented:
C6.5 10.4.1.a Verify that only designated central time servers receive time signals from
external sources, and time signals from external sources are based on International
Atomic Time or UTC.
10.4.1.b Verify that the designated central time servers peer

with each other to keep accurate time, and other internal servers receive time only
from the central time servers.
NC 10.4.2.a Review system configurations and time-synchronization settings to verify

that access to time data is restricted to only personnel with a business need to
access time data.
10.4.2.b Review system configurations and time synchronization settings and
processes to verify that any changes to time
settings on critical systems are logged, monitored, and reviewed.
C14.5 10.4.3 Verify that the time servers accept time updates from specific, industry-
accepted external sources (to prevent a malicious individual 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 time updates (to prevent unauthorized use of internal time
servers).
C14.2.1 10.5 Interview system administrator and examine permissions to verify that audit trails
C14.7 are secured so that they cannot be altered as follows:
NC 10.5.1 Verify that only individuals who have a job-related need can view audit trail
files.
C14.7 10.5.2 Verify that current audit trail files are protected from unauthorized
modifications via access control mechanisms, physical segregation, and/or network
segregation.
C14.2.1 10.5.3 Verify that current audit trail files are promptly backed up to a centralized log
server or media that is difficult to alter.
C14.7 10.5.4 Verify that logs for external-facing technologies (for example, wireless,
firewalls, DNS, mail) are offloaded or copied onto a secure centralized internal log
server or media.
NC 10.5.5 Verify the use of file-integrity monitoring or change- detection software for
logs by examining system settings and monitored files and results from monitoring
activities.
C14.4 10.6.a Obtain and examine security policies and procedures to verify that they include
C14.6 procedures to review security logs at least daily and that follow-up to exceptions is
required.
10.6.b Through observation and interviews, verify that regular log reviews are
performed for all system components.
NC 10.7.a Obtain and examine security policies and procedures and verify that they
include audit log retention policies and require audit log retention for at least one year.
10.7.b Verify that audit logs are available for at least one year and processes are in
place to immediately restore at least the last
three months logs for analysis.
ng, alerting, and analysis when something does go wrong. Determining the cause of a compromise is very difficult, if not impossible, without system acti
tegrity monitoring can be extremely complex and expensive to implement.

trigger a response to an exception report, and the inability to test implementations of log archival

Identify the system administrator(s) interviewed who confirm that audit trails are ###
enabled and active for system components.
Describe how audit trails were observed to be enabled and active.
###
Identify the responsible personnel interviewed who confirm that all individual ###
access to cardholder data is logged.
Describe how configuration settings were observed to log all individual access to
cardholder data.
Describe how observed audit logs include all individual access to cardholder data. 4
Identify the responsible personnel interviewed who confirm that actions taken by ###
any individual with root or administrative privileges are logged.
Describe how configuration settings were observed to log all actions taken by any
individual with root or administrative privileges.
Describe how observed audit logs include all actions taken by any individual with
root or administrative privileges. 4
Identify the responsible personnel interviewed who confirm that access to all audit ###
trails is logged.
Describe how configuration settings were observed to log access to all audit trails. 4
Describe how observed audit logs include access to all audit trails.
Identify the responsible personnel interviewed who confirm that invalid logical ###
access attempts are logged.
Describe how configuration settings were observed to log invalid logical access
attempts. Describe how observed audit logs include invalid logical access attempts. 4
Identify the responsible personnel interviewed who confirm that the use of ###
identification and authentication mechanisms is logged.
Describe how configuration settings were observed to log the use of identification
and authentication mechanisms.
Describe how observed audit logs include use of identification and authentication
mechanisms.
4
Identify the responsible personnel interviewed who confirm that the initialization of ###
audit logs is logged.
Describe how configuration settings were observed to log the initialization of audit
logs. Describe how observed audit logs include initialization of audit logs. 4
Identify the responsible personnel interviewed who confirm that the following are ###
logged:
i. Creation of system level objects
ii. Deletion of system level objects
Describe how configuration settings were observed to log:
i. Creation of system level objects 4
ii. Deletion of system level objects
Describe how observed audit logs include:
Creation of system level objects and Deletion of system level objects
###
For each auditable event from 10.2.1 10.2.7: ###

Identify the responsible personnel interviewed who confirm that user identification
is included in log entries. 4
Describe how audit logs were observed to include user identification.

dentify the responsible personnel interviewed who confirm that the type of event is
included in log entries. 4
Describe how audit logs were observed to include the type of event.
dentify the responsible personnel interviewed who confirm that the date and time is
included in log entries.
Describe how audit logs were observed to include the date and time. 4

Identify the responsible personnel interviewed who confirm that success or failure
I.indication is included in log entries. 4
ii. Describe how audit logs were observed to include success or failure indication.

Identify the responsible personnel interviewed who confirm that origination of the
event is included in log entries. 4
ii. Describe how audit logs were observed to include the origination of the event.

Identify the responsible personnel interviewed who confirm that the identity or
name of
affected data, system component, or resource is included in log entries. 4
ii. Describe how audit logs were observed to include the identity or name of
affected data,
system component, or resource.
Identify the time synchronization technologies in use. ###
Identify the document that defines processes for ensuring the time synchronization
technologies are kept current per PCI DSS Requirements 6.1 and 6.2.
Describe how time synchronization technologies were observed to be:
i. Implemented
i. Kept current per the documented process
4
###
Identify the document that defines processes for acquiring, distributing, and storing ###
the correct time within the organization, and confirm the processes require that:
i. Only designated central time servers receive time signals from external sources.
ii. Time signals from external sources are based on International Atomic Time or
UTC.
Describe how configuration settings observed on the sampled system components 4
confirm that:
i. Only designated central time servers receive time signals from external sources.
ii. Time signals from external sources are based on International Atomic Time or
UTC.
Describe how time synchronization processes were observed to verify:
Only designated central time servers receive time signals from external sources.
Identify the document
Time signals requiring
from external that:
sources are based on International Atomic Time or UTC. ###
the designated central time servers peer each other to keep accurate time
Other internal time servers received time from central time servers
Identify the sample of system components observed
Describe how configuration settingsobserved on the sample system components 4
confirm the above.
Describe how time synchronization processes were observed to verify the above.
Identify the document that: ###

i. Requires that access to time data is restricted to only personnel with a business
need to
access time data.
ii. Defines which personnel have a business need to access time data.
Identify the authorized personnel interviewed who confirm that personnel with
access to time data have a business need to access time data.
Describe how configuration settings on the sampled system components were
observed to restrict access to time data to only personnel with a documented
business need.
Identify the document that requires: ###
i. Changes to time settings on critical systems are logged
ii. Changes to time settings on critical systems are monitored
iii. Changes to time settings on critical systems are reviewed
Describe how configuration settings on the sampled system components were
observed to log
any changes to time settings on critical systems.
Describe how time synchronization processes were observed to verify: 4
Changes to time settings on critical systems are logged Changes to time settings on
critical systems are monitored Changes to time settings on critical systems are
reviewed
Identify the document that defines how time settings are received from industry- ###
accepted time sources
Describe how configuration settings on time servers were observed to receive time
updates from specific, industry-accepted external sources.
Describe how time synchronization processes were observed to verify that the
time servers receive time updates from specific, industry-accepted external sources.
Optionnally:
Identify the document that defines how time updates are encrypted with a
symmetric key, and access control lists specify the IP addresses of client machines to
be provided with the time updates.
Describe how configuration settings on time servers were observed to encrypt
time updates with a symmetric key.
Describe how access control lists were observed to specify the IP addresses of 4
client machines to be provided with the time updates.
Describe how time synchronization processes were observed to verify that time
updates are encrypted with a symmetric key, and access control lists are
implemented to specify the IP addresses of client machines.
###
Identify the document defining which personnel have a job-related need to view ###
audit trail files. Identify the authorized personnel interviewed who confirm that all
personnel with access to
view audit trail files have a business need to do so.
Describe how observed system and audit log permission settings restrict viewing 4
of audit trail files to only individuals who have a documented job-related need.
Describe how observed access to audit logs confirms that only individuals with a
job-related need can view the audit trail files.
Describe the methods used to protect audit trail files from unauthorized ###
modifications (e.g., via access control mechanisms, physical segregation, and/or
network segregation).
Describe how system configurations and audit log settings were observed to protect
audit trail files from unauthorized modifications. 4
Describe how observed access to audit logs confirms that audit trail files are
protected from unauthorized modifications.
Identify and briefly describe: ###

i. The centralized log server or media that audit trail files are backed up to
ii. How frequently the audit trail files are backed up, and how the frequency Is
appropriate
iii. How the centralized log server or media is difficult to alter
Identify the responsible personnel interviewed who confirm:
i. That current audit trail files are promptly backed up to the centralized log server or
media. 4
ii. The frequency that audit trail files are backed up
iii. That the centralized log server or media is difficult to alter.
Describe how observed system and audit log settings are configured to promptly
back up audit trail files to the centralized log server or media.
Describe how audit logs were observed to be promptly backed up to the
centralized log server or media.
Describe how logs for external-facing technologies (for example, wireless, firewalls, ###
DNS, mail) are offloaded or copied onto a secure centralized internal log server or
media.
Identify the responsible personnel interviewed who confirm that logs for external-
facing technologies are offloaded or copied onto a secure, centralized internal log
server or media.
Describe how observed external-facing system and audit log settings are 4
configured to offload or copy logs onto a secure centralized internal log server or
media.
Describe how logs for external-facing technologies were observed to be located on
the centralized internal log server or media.
Identify the file-integrity monitoring (FIM) or change-detection software in use. ###

Identify the personnel responsible for monitoring FIM and/or change detection
software, who
were interviewed to confirm that audit log files are monitored.
Describe how system settings were observed to monitor logs to ensure that
existing log data cannot be changed without generating alerts.
Describe how observed results from monitoring activities confirm that log data
cannot be changed without generating alerts.
4
Identify the security policy document which requires: ###
i. Review of logs for all system components, including those that perform security
functions,
at least daily
ii. Follow-up to exceptions
Identify the documented procedures for:
i. Reviewing logs for all system components at least daily
ii. Following up exceptions 4
Describe the implemented procedures for:
i. Reviewing logs for all system components at least daily
ii. Following up exceptions
Identify the responsible personnel interviewed who confirm that: ###

i. Log reviews are performed for all system components at least daily
ii. Log reviews include follow-up to exceptions
Describe how observed evidence from log reviews confirms that:
Log reviews are performed for all system components 4
Log reviews include follow-up to exceptions
Identify the security policy document that: ###

i. Defines audit log retention policies
ii. Requires audit log retention for at least one year.
Identify the document which defines procedures for audit log retention. 4
Describe how the implemented procedures ensure audit log retention for at least one
year.
Identify the document that defines the process to immediate restore at least the last ###
three months logs for analysis.
Describe the implemented processes.
Describe how audit logs and restore processes were observed to confirm that:
i. ii.
Audit logs are available for at least one year. 4
At least the last three months logs can be immediately restored for analysis.
132 ###0 0 0
possible, without system activity logs.
C D In Place? I Severity Proofs / Stage of implementation

t
e
1 N N
r 4
m
e
d
i
a
r
y
C
o
1 N N 4
n
t
r
o
l
1 N N 4
1 N N 4
1 N N 4
1 N N 4
1 N N 4
1 N N 4
1 N N 4
1 N N 4
1 N N 4
1 N N 4
1 N N 4
1 N N 4
1 N N 4
1 N N 4
1 N N 4
1 N N 4
1 N N 4
1 N N 4
1 N N 4
1 N N 4
1 N N 4
1 N N 4
1 N N 4
1 N N 4
1 N N 4
1 N N 4
1 N N 4
1 N N 4
1 N N 4
1 N N 4
1 N N 4
0 33 Y 132
N
C
Requirement 11: Regularly test security systems and processes.
Vulnerabilities are being discovered continually by malicious individuals and researchers, and being introduced by new software. System co
Only 37 percent of organizations fully met Requirement 11 at the time of IROC
It is the least compliant key control of the PCI DSS standard
Organizations met an average of 65 percent of tests in Requirement 11 at time of IROC, a five percent drop, from 2010.
Organizations continue to have difficulty meeting the sub-requirements regarding network vulnerability scanning (11.2), penetration testin
67 percent of organizations met the testing requirements of 11.2.
The difficulties reside into the frequency (quarterly) combined with the expectation that findings are remediated and re- tested.
Time and resource constraints hindered some in our sample from being able to present four passing external and internal scans.
53 percent of organizations perform external and internal penetration testing at least once a year and after any significant infrastructure or
11.1 Test for the presence of wireless access points Implementation and/or exploitation of wireless
and detect unauthorized wireless access points on a technology within a network is one of the most
quarterly basis. common paths for malicious users to gain access to
the network and cardholder data. If a wireless
Note: Methods that may be used in the process device or network is installed without a companys
include but are not limited to wireless network knowledge, it can allow an attacker to easily and
scans, physical/logical inspections of system invisibly enter the network.
components and infrastructure, network access
control (NAC), or wireless IDS/IPS. Whichever Unauthorized wireless devices may be hidden within
methods are used, they must be sufficient to detect or attached to a computer or other system
and identify any unauthorized devices. component, or be attached directly to a network
port or network device, such as a switch or router.
Any such unauthorized device could result in an
unauthorized access point into the environment.
Due to the ease with which a wireless access point

can be attached to a network, the difficulty in
detecting their presence, and the increased risk
presented by unauthorized wireless devices, these
processes must be performed even when a policy
exists prohibiting the use of wireless technology.
The size and complexity of a particular environment

will dictate the appropriate tools and processes to
be used to provide sufficient assurance that a rogue
wireless access point has not been installed in the
environment.
For example: In the case of a single standalone retail
kiosk in a shopping mall, where all communication
components are contained within tamper-resistant
and tamper-evident casings, performing a detailed
physical inspection of the kiosk itself may be
sufficient to provide assurance that a rogue wireless
access point has not been attached or installed.
However, in an environment with multiple nodes
(such as in a large retail store, call centre, server
room or data center), it becomes more difficult to
perform a detailed physical inspection due to the
number of system components and network points
where a rogue wireless access device could be
installed or hidden. In this case, multiple methods
may be combined to meet the requirement, such as
performing physical system inspections in
conjunction with the results of a wireless analyzer.
Network access control (NAC) solutions can perform

device authentication and configuration
management to prevent unauthorized systems
connecting to the network, or unauthorized devices
connecting to authorized systems on the network.
An organization should have, as part of its incident
(such as in a large retail store, call centre, server
room or data center), it becomes more difficult to
perform a detailed physical inspection due to the
number of system components and network points
where a rogue wireless access device could be
installed or hidden. In this case, multiple methods
may be combined to meet the requirement, such as
performing physical system inspections in
conjunction with the results of a wireless analyzer.
Network access control (NAC) solutions can perform

device authentication and configuration
management to prevent unauthorized systems
connecting to the network, or unauthorized devices
connecting to authorized systems on the network.
An organization should have, as part of its incident
response plan, documented procedures to follow in
the event an unauthorized wireless access point is
detected. A wireless IDS/IPS should be configured to
automatically generate an alert, but the plan must
also document response procedures if an
unauthorized device is detected during a manual
wireless scan.
11.2 Run internal and external network vulnerability A vulnerability scan is an automated tool run against
scans at least quarterly and after any significant external and internal network devices and servers,
change in the network (such as new system designed to expose potential vulnerabilities in
component installations, changes in network networks that could be found and exploited by
topology, firewall rule modifications, product malicious individuals. Once these weaknesses are
upgrades). identified, the entity corrects them, and repeats the
scan to verify the vulnerabilities have been
Note: It is not required that four passing quarterly corrected.
scans must be completed for initial PCI DSS
compliance if the assessor verifies 1) the most recent At the time of an entitys initial PCI DSS assessment,
scan result was a passing scan, 2) the entity has it is possible that four quarterly scans have not yet
documented policies and procedures requiring been performed. If the most recent scan result
quarterly scanning, and 3) vulnerabilities noted in meets the criteria for a passing scan, and there are
the scan results have been corrected as shown in a policies and procedures in place for future quarterly
rescan. For subsequent years after the initial PCI scans, the intent of this requirement is met. It is not
DSS review, four passing quarterly scans must have necessary to delay an in place assessment for this
occurred. requirement due to a lack of four scans if these
conditions are satisfied.
11.2.1 Perform quarterly internal vulnerability An established process for identifying vulnerabilities
scans. on internal systems within the CDE requires that
vulnerability scans be conducted quarterly.
Identifying and addressing vulnerabilities in a timely
manner reduces the likelihood of a vulnerability
being exploited and potential compromise of a
system component or cardholder data.
Vulnerabilities posing the greatest risk to the

environment (for example, ranked High per
Requirement 6.2) should be resolved with the
highest priority.
As internal networks may be constantly changing

during the year, it is possible that an entity may not
have consistently clean internal vulnerability scans.
The intent is for an entity to have a robust
vulnerability management program in place to
resolve noted vulnerabilities in a reasonable
timeframe. At minimum, High vulnerabilities must
be addressed in a timely fashion.
Internal vulnerability scans can be performed by

qualified, internal staff that are reasonably
independent of the system component(s) being
scanned (for example, a firewall administrator
should not be responsible for scanning the firewall),
or an entity may choose to have internal
vulnerability scans performed by a PCI SSC Approved
Scanning Vendor (ASV), QSA or other firm
specializing in vulnerability scanning.
11.2.2 Perform quarterly external vulnerability scans As external networks are at greater risk of compromise, quarterly external vulnerabil
via an Approved Scanning Vendor (ASV), approved
by the Payment Card Industry Security Standards
Council (PCI SSC).
Note: Quarterly external vulnerability scans must be

performed by an Approved Scanning Vendor (ASV),
approved by the Payment Card Industry Security
Standards Council (PCI SSC). Scans conducted after
network changes may be performed by internal staff.
11.2.3 Perform internal and external scans after Scanning an environment after any significant
any significant change. changes are made ensures that changes were
completed appropriately such that the security of
Note: Scans conducted after changes may be the environment was not compromised as a result
performed by internal staff. of the change. It may not be necessary to scan the
entire environment after a change. However, all
system components affected by the change will
need to be scanned.
11.3 Perform external and internal penetration The intent of a penetration test is to simulate a real
testing at least once a year and after any significant world attack situation with a goal of identifying how
infrastructure or application upgrade or far an attacker would be able to penetrate into an
modification (such as an operating system upgrade, environment. This allows an entity to gain a better
a sub- network added to the environment, or a web understanding of their potential exposure and
server added to the environment). These develop a strategy to defend against attacks.
penetration tests must include the following: A penetration test differs from a vulnerability scan,
as a penetration test is an active process which may
include exploiting identified vulnerabilities. Often,
performing a vulnerability scan is one of the first
steps a penetration tester will perform in order to
comprise a strategy of attack, although it is not the
only step. Even if a vulnerability scan does not
detect any known vulnerabilities, the penetration
tester will often gain enough knowledge about the
system to identify possible security gaps.
Penetration testing is generally a highly manual

process. While some automated tools may be used,
the tester must utilize their knowledge of systems to
penetrate into an environment. Often the tester will
chain several types of exploits together with a goal
of breaking through layers of defenses. For example,
if the tester finds a means to gain access to an
application server, they will then use the
compromised server as a point to stage a new attack
based on the resources the server has access to. In
this way a tester is able to simulate the methods
performed by an attacker in order to identify any
areas of potential weakness in the environment that
need to be addressed.
11.3.1 Network-layer penetration tests
11.3.2 Application-layer penetration tests

11.4 Use intrusion-detection systems, and/or Intrusion detection and/or intrusion prevention
intrusion-prevention systems to monitor all traffic at systems (IDS/IPS) compare the traffic coming into
the perimeter of the cardholder data environment the network with known signatures and/or
as well as at critical points inside of the cardholder behaviors of thousands of compromise types
data environment, and alert personnel to suspected (hacker tools, Trojans and other malware), and send
compromises. alerts and/or stop the attempt as it happens.
Keep all intrusion-detection and prevention engines, Without a proactive approach to unauthorized
baselines, and signatures up-to-date. activity detection via these tools, attacks on (or
misuse of) computer resources could go unnoticed
in real time. Security alerts generated by these tools
should be monitored, so that the attempted
intrusions can be stopped.
IDS/IPS devices should be implemented such that

they monitor inbound and outbound traffic at the
perimeter of the CDE as well as at critical points
within the CDE. Critical points inside the CDE may
include database servers storing cardholder data,
cryptographic key storage locations, processing
networks, or other sensitive system components, as
determined by an entitys environment and as
documented in their risk assessment.
While many IDS/IPS devices today are able to
monitor multiple points inside of the CDE via one
device, it is important to remember the increased
exposure that may occur as a result of a failure in
that single device. Thus, it is important to
incorporate appropriate redundancy in the IDS/IPS
infrastructure.
There are thousands of compromise types, with

more being discovered on a daily basis. Stale
signatures and scanning engines on IDS/IPS devices
will not have the ability to identify new
vulnerabilities that could lead to an undetected
breach. Vendors of these products provide frequent,
often daily, updates that should be evaluated and
applied on a regular basis.
11.5 Deploy file-integrity monitoring tools to alert File-integrity monitoring (FIM) tools check for
personnel to unauthorized modification of critical changes to critical files, and notify when such
system files, configuration files, or content files; and changes are detected. There are both off-the-shelf
configure the software to perform critical file and open source tools available for file integrity
comparisons at least weekly. monitoring. If not implemented properly and the
output of the FIM monitored, a malicious individual
Note: For file-integrity monitoring purposes, critical could alter configuration file contents, operating
files are usually those that do not regularly change, system programs, or application executables. Such
but the modification of which could indicate a unauthorized changes, if undetected, could render
system compromise or risk of compromise. File- existing security controls ineffective and/or result in
integrity monitoring products usually come pre- cardholder data being stolen with no perceptible
configured with critical files for the related operating impact to normal processing.
system. Other critical files, such as those for custom
applications, must be evaluated and defined by the
entity (that is, the merchant or service provider).
eing introduced by new software. System components, processes, and custom software should be tested frequently to ensure security controls continue
percent drop, from 2010.

nerability scanning (11.2), penetration testing (11.3), and file integrity monitoring (11.5).
ngs are remediated and re- tested.

assing external and internal scans.
ear and after any significant infrastructure or application upgrade or modification (Requirement 11.3).

Top 20 Critical
Security Controls
C1.2 11.1.a Verify that the entity has a documented process to detect and identify wireless
C13.9 access points on a quarterly basis.
C7.1
C7.3
C7.9
11.1.b Verify that the methodology is adequate to detect and identify any
unauthorized wireless access points, including at least the following:
- WLAN cards inserted into system components

- Portable wireless devices connected to system components (for example, by USB,
etc.)
- Wireless devices attached to a network port or network device
11.1.c Verify that the documented process to identify unauthorized wireless access
points is performed at least quarterly for all system components and facilities.
11.1.d If automated monitoring is utilized (for example, wireless IDS/IPS, NAC, etc.),
verify the configuration will generate alerts to personnel.
11.1.e Verify the organizations incident response plan (Requirement 12.9) includes a
response in the event unauthorized wireless devices are detected.
C1.2 11.2 Verify that internal and external vulnerability scans are performed as follows:
C13.9
C6.4
C4.1
C11.2
C4.1 11.2.1.a Review the scan reports and verify that four quarterly internal scans
C11.2 occurred in the most recent 12-month period.
11.2.1.b Review the scan reports and verify that the scan process includes rescans
until passing results are obtained, or all High vulnerabilities as defined in PCI DSS
Requirement 6.2 are resolved.
11.2.1.c Validate that the scan was performed by a qualified internal resource(s) or
qualified external third party, and if applicable, organizational independence of the
tester exists (not required to be a QSA or ASV).
C4.1 11.2.2.a Review output from the four most recent quarters of external vulnerability
scans and verify that four quarterly scans occurred in the most recent 12-month
period.
11.2.2.b Review the results of each quarterly scan to ensure that they satisfy the
ASV Program Guide requirements (for example, no vulnerabilities rated higher than
a 4.0 by the CVSS and no automatic failures).
11.2.2.c Review the scan reports to verify that the scans were completed by an
Approved Scanning Vendor (ASV), approved by the PCI SSC.
C6.4 11.2.3.a Inspect change control documentation and scan reports to verify that
C4.1 system components subject to any significant change were scanned.
C11.2
11.2.3.b Review scan reports and verify that the scan process includes rescans until:
- For external scans, no vulnerabilities exist that are scored greater than a 4.0 by the
CVSS,
- For internal scans, a passing result is obtained or all High vulnerabilities as
defined in PCI DSS Requirement 6.2 are resolved.
11.2.3.c Validate that the scan was performed by a qualified internal resource(s) or
qualified external third party, and if applicable, organizational independence of the
tester exists (not required to be a QSA or ASV).
C13.9 11.3.a Obtain and examine the results from the most recent penetration test to verify
C20.1 that penetration testing is performed at least annually and after any significant
changes to the environment.
11.3.b Verify that noted exploitable vulnerabilities were corrected and testing
repeated.
(SANS C17.3)
11.3.c Verify that the test was performed by a qualified internal resource or qualified
external third party, and if applicable, organizational independence of the tester exists
(not required to be a QSA or ASV).
C20.1 11.3.1 Verify that the penetration test includes network-layer penetration tests.
These tests should include components that support network functions as well as
operating systems.
C20.4 11.3.2 Verify that the penetration test includes application-layer penetration tests.
The tests should include, at a minimum, the vulnerabilities listed in Requirement
6.5.
C13.2 11.4.a Verify the use of intrusion-detection systems and/or intrusion-prevention
C13.3 systems and that all traffic at the perimeter of the cardholder data environment as well
C5.1.2 as at critical points in the cardholder data environment is monitored.
11.4.b Confirm IDS and/or IPS are configured to alert personnel of suspected
compromises.
11.4.c Examine IDS/IPS configurations and confirm IDS/IPS devices are configured,
maintained, and updated per vendor instructions to ensure optimal protection.
C3.9 11.5.a Verify the use of file-integrity monitoring tools within the cardholder data
environment by observing system settings and monitored files, as well as reviewing
results from monitoring activities. Examples of files that should be monitored:
- System executables
- Application executables
- Configuration and parameter files
- Centrally stored, historical or archived, log and audit files
11.5.b Verify the tools are configured to alert personnel to unauthorized modification
of critical files, and to perform critical file comparisons at least weekly.
uently to ensure security controls continue to reflect a changing environment
Validation Instructions for QSA/ISA Priotity A B C-VT

Identify the document that defines the methods and processes to: 4 ###
i. Detect wireless access points.
ii. Identify unauthorized wireless access points.
iii. Perform the process (at least) on a quarterly basis.
Describe the documented methodology for detection and identification of 4 ###
unauthorized wireless access points, including:
i. WLAN cards inserted into system components
ii. Portable wireless devices connected to system components
iii. Wireless devices attached to a network port or network device
iv. Any other unauthorized wireless access points
Describe how the methodology/processes were observed to be adequate to detect
and identify unauthorized wireless access points, including:
i. WLAN cards inserted into system components
ii. Portable wireless devices connected to system components
iii. Wireless devices attached to a network port or network device
iv. Any other unauthorized wireless access points
Identify the personnel who perform the process who were interviewed to confirm 4 ###
that:
i. The process is performed at least quarterly
ii. The process covers all system components
iii. The process covers all facilities
Describe how observed results of previously performed processes confirm that:
The process is performed at least quarterly
The process covers all system components
The process covers all facilities
Identify and describe any automated monitoring technologies in use (for example, 4 ###
wireless IDS/IPS, NAC, etc.)
For each automated monitoring technology in use:
i. Describe how the observed technology is configured to generate alerts to personnel.
ii. Describe how alerts to personnel were observed to be generated.
iii. Identify the personnel responsible for receiving the alerts, who were interviewed to
confirm that the generated alerts are received as intended.
Identify the Incident Response Plan document that defines response procedures in the 4 ###
event unauthorized wireless devices are detected.
Identify the responsible personnel interviewed who confirm that, in the event
unauthorized wireless devices are detected, the documented response is followed.
###
Identify the internal scan report documents that verify four quarterly internal scans ###
occurred in the most recent 12-month period.
For each of the four internal quarterly scans performed in the most recent 12-
month period, identify the following:
i. Date quarterly scan was performed
ii. Result of scan
2
Identify the document that defines the process for performing rescans as part of the ###
quarterly internal scan process.
Identify personnel interviewed who confirm that the documented rescan process
is followed for quarterly internal scans.
For each of the four internal quarterly scans identified in 11.2.1.a, identify the
following:
i. Whether a rescan was required 2
ii. Details of how rescans were performed until either:
o Passing results are obtained, or
o All High vulnerabilities as defined in PCI DSS Requirement 6.2 are resolved.
From the scan reports, indetify whether internal and/or external resources perform ###
internal scans
Indetify the interviwed personnel who performed the scans, and describe how the
personnel demonstrated they are qualified to perform the scans 2
Describe how organizational independence of the tester was observed to exist.
Identify the external scan report documents that verify four quarterly external scans ###
occurred in the most recent 12-month period.
Describe how the external scan reports verify that the scans satisfy the ASV Program ###
Guide
requirements (for example, no vulnerabilities rated higher than a 4.0 by the CVSS 2
and no
automatic failures).
Describe how the external scan reports verify that the scans were completed by a ###
PCI SSC- Approved Scanning Vendor (ASV).
2
Identify the document that defines the process for performing internal and external ###
scans after any significant change.
Identify whether any significant changes were made to internal and/or external
system components during the past 12 months.
Identify change control documentation containing details of the identified
changes. 2
Describe how the change control documentation and scan reports confirm that all
system
components subject to significant change were scanned after the change.
For all scans reviewed in 11.2.3.a, identify the following: ###

i. Whether a rescan was required
ii. Details of how rescans were performed until:
o For external scans No vulnerabilities with a CVSS score greater than 4.0 exist.
o For internal scans Either passing results were obtained, or all High
vulnerabilities 2
as defined in PCI DSS Requirement 6.2 were resolved.
Identify personnel interviewed to confirm that the process for performing scans
after significant changes includes rescans as defined.
From the scan reports, identify whether internal and/or external resources perform ###
the scans. Identify the interviewed personnel who perform the scans, and describe
how the personnel
demonstrated they are qualified to perform the scans. 2
Describe how organizational independence of the tester was observed to exist.
Identify the documented penetration test results which confirm: ###

i. Internal penetration tests are performed annually.
ii. External penetration tests are performed annually.
Identify whether any significant infrastructure or application upgrade or modification
occurred during the past 12 months.
Identify the documented penetration test results confirming that penetration tests
are performed after:
i. Significant internal infrastructure or application upgrade. ii. Significant external
infrastructure or application upgrade.
Identify whether any exploitable vulnerabilities were noted in the most recent: ###
i. Internal penetration test results
ii. External penetration test results
Identify the interviewed personnel who confirm that all noted exploitable
vulnerabilities were corrected.
Identify the documented penetration test results confirming that: 2
i. Testing was repeated.
ii. All noted exploitable vulnerabilities were corrected.
Indetify wheter internal or external resources performed the penetration tests ###
Indentify the interviewed personnel who performed the tests and describehow the
personnel demonstrated that they are qualified for such tests 2
Describe how organizational independence is ensured.
Identify the documented results from the most recent penetration tests confirming ###
that: i. Internal penetration testing includes network-layer penetration tests.
ii. External penetration testing includes network-layer penetration tests.
iii. The network-layer penetration tests include:
o Components that support network functions o Operating systems
i. Internal penetration testing includes network-layer penetration tests. 2
ii. External penetration testing includes network-layer penetration tests.
iii. The network-layer penetration tests include:
o Components that support network functions o Operating systems
Identify the documented results from the most recent penetration tests confirming ###
that:
i. ii.
Internal penetration testing includes application-layer penetration tests. External
penetration testing includes application-layer penetration tests.
The application-layer tests include, at a minimum, the vulnerabilities listed in PCI
DSS Requirement 6.5.
2
Internal penetration testing includes application-layer penetration tests.
External penetration testing includes application-layer penetration tests.
The application-layer tests include, at a minimum, the vulnerabilities listed in PCI
DSS Requirement 6.5.
Describe the intrusion-detection and/or intrusion-prevention systems (IDS/IPS) that ###
are implemented.
Describe how IDS/IPS were observed to be positioned within the environment to
ensure that all traffic is monitored:
i. At the perimeter of the cardholder data environment
ii. At critical points within the cardholder data environment
Describe how observed IDS/IPS configurations confirm that all traffic is monitored: i.
At the perimeter of the cardholder data environment
ii. At critical points within the cardholder data environment
Describe how observed IDS/IPS are configured to alert personnel of suspected ###
compromises.
Describe how alerts to personnel were observed to be generated. 2
Identify the personnel responsible for receiving the alerts, who were interviewed to
confirm that the generated alerts are received as intended.
Identify the document that defines vendor instructions for: ###
i. Configuring IDS/IPS devices
ii. Maintaining IDS/IPS devices
iii. Updating IDS/IPS devices
Describe how observed IDS/IPS settings and configurations confirm that vendor
instructions are followed for:
Configuring IDS/IPS devices 2
Maintaining IDS/IPS devices
Updating IDS/IPS devices
Describe the file-integrity monitoring (FIM) tools deployed. 4 ###
Describe how FIM settings and configurations were observed to monitor changes to:
i. Critical system files
ii. Critical configuration files
iii. Critical content files
Describe how observed results from monitoring activities confirm that changes to the
following files are monitored:
i. Critical system files
ii. Critical configuration files
iii. Critical content files
Describe how observed FIM settings are configured to: 4 ###

Alert personnel to unauthorized modification of critical files
Perform Critical file comparisons at least weekly
Describe how results and alerts from monitoring activities were observed to confirm
the above
Identify the responsible personnel who were interviewed to confirm the above.
64 ###0 0 0
C D In Place? Severity Proofs /
Documentation links
1 1 N 4
1 1 N 4
1 1 N 4
1 1 N 4
1 1 N 4
1 1 N 2
1 1 N 2
1 1 N 2
1 1 N 2
1 1 N 2
1 1 N 2
1 1 N 2
1 1 N 2
1 1 N 2
1 1 N 2
1 N 2
1 N 2
1 N 2
1 N 2
1 N 2
1 N 2
1 N 2
1 N 2
1 N 4
1 N 4
15 25 Y 64
N
C
Stage of implementation Remediation plan Estimated date for Comments
completion
Owner
Requirement 12: Maintain a policy that addresses information security for all personnel.
A strong security policy sets the security tone for the whole entity and informs personnel what is expected of them. All personnel should b

39 percent of organizations fully met Requirement 12 at the time of IROC. This is a five percent drop in comparison to the 2010 report find
Organizations met an average of 79 percent of tests in Requirement 12 at the time of IROC.
Policies are written without completing prerequisite work; thus they lack critical content, and fail to identify the information assets that mu
The most compliant sub-control for Requirement 12 at the time of the IROC is 12.4
The most challenging sub-requirements under Requirement 12 are 12.8.2 and 12.8.4.
Requirement 12.8.2, formally obtaining acknowledgement from service providers of their commitment to maintain proper security of card
Lack of interpretation of sub-control 12.8.4 (Maintain a program to monitor service providers PCI DSS compliance status) contributed towa
12.1 Establish, publish, maintain, and disseminate a A company's information security policy creates the
security policy that accomplishes the following: roadmap for implementing security measures to
protect its most valuable assets. A strong security
policy sets the security tone for the whole company,
and lets personnel know what is expected of them.
All personnel should be aware of the sensitivity of
data and their responsibilities for protecting it.
12.1.1 Addresses all PCI DSS requirements.

12.1.2 Includes an annual process that identifies A risk assessment enables an organization to
threats, and vulnerabilities, and results in a formal identify threats and the associated vulnerabilities
risk assessment. which have the potential to negatively impact their
(Examples of risk assessment methodologies business. Resources can then be effectively allocated
include but are not limited to OCTAVE, ISO 27005 to implement controls that reduce the likelihood
and NIST SP 800-30.) and/or the potential impact of the threat being
realized.
Performing risk assessments at least annually allows
the organization to keep up to date with
organizational changes and evolving threats, trends
and technologies,
12.1.3 Includes a review at least annually and Security threats and protection methods evolve
updates when the environment changes. rapidly throughout the year. Without updating
the security policy to reflect relevant changes,
new protection measures to fight against these
threats are not addressed.
12.2 Develop daily operational security procedures Daily operational security procedures act as desk
that are consistent with requirements in this instructions for personnel to use in their day-to-day
specification (for example, user account system administrative and maintenance activities.
maintenance procedures, and log review Undocumented operational security procedures will
procedures). lead to personnel who are not aware of the full
scope of their tasks, processes that cannot be
repeated easily by new workers, and potential gaps
in these processes that may allow a malicious
individual to gain access to critical systems and
resources.
12.3 Develop usage policies for critical technologies Personnel usage policies can either prohibit use of
(for example, remote- access technologies, wireless certain devices and other technologies if that is
technologies, removable electronic media, laptops, company policy, or provide guidance for personnel
tablets, personal data/digital assistants (PDAs), e- as to correct usage and implementation. If usage
mail usage and Internet usage) and define proper policies are not in place, personnel may use the
use of these technologies. Ensure these usage technologies in violation of company policy, thereby
policies require the following: allowing malicious individuals to gain access to
critical systems and cardholder data. An example
can be unknowingly setting up wireless networks
with no security. To ensure that company standards
are followed and only approved technologies are
implemented, consider confining implementation to
operations teams only and not allowing
unspecialized/general personnel install these
technologies.
12.3.1 Explicit approval by authorized parties Without requiring proper approval for
implementation of these technologies, individual
personnel may innocently implement a solution to a
perceived business need, but also open a huge hole
that subjects critical systems and data to malicious
individuals.
12.3.2 Authentication for use of the technology If technology is implemented without proper
authentication (user IDs and passwords, tokens,
VPNs, etc.), malicious individuals may easily use this
unprotected technology to access critical systems
and cardholder data.
12.3.3 A list of all such devices and personnel Malicious individuals may breach physical security
with access and place their own devices on the network as a
back door. Personnel may also bypass procedures
and install devices. An accurate inventory with
proper device labeling allows for quick identification
of non-approved installations. Consider establishing
an official naming convention for devices, and label
and log all devices in concert with established
inventory controls. Also, logical labeling may be
employed with information such as codes that can
correlate the device to its owner, contact
information and purpose.
of non-approved installations. Consider establishing
an official naming convention for devices, and label
and log all devices in concert with established
inventory controls. Also, logical labeling may be
employed with information such as codes that can
correlate the device to its owner, contact
12.3.4 Labeling of devices to determine owner, information and purpose.
contact information and purpose
12.3.5 Acceptable uses of the technology By defining acceptable business use and location of
company-approved devices and technology, the
company is better able to manage and control gaps
in configurations and operational controls, to ensure
a back door is not opened for a malicious
individual to gain access to critical systems and
12.3.6 Acceptable network locations for the cardholder data.
technologies
12.3.7 List of company-approved products
12.3.8 Automatic disconnect of sessions for Remote-access technologies are frequent "back
remote-access technologies after a specific period doors" to critical resources and cardholder data. By
of inactivity disconnecting remote-access technologies when not
in use (for example, those used to support your
systems by your POS vendor, other vendors, or
business partner), access and risk to networks is
minimized. Consider using controls to disconnect
devices after 15 minutes of inactivity. Please also
see Requirement 8.5.6 for more on this topic.
12.3.9 Activation of remote-access technologies
for vendors and business partners only when
needed by vendors and business partners, with
immediate deactivation after use
12.3.10 For personnel accessing cardholder data To ensure all personnel are aware of their
via remote-access technologies, prohibit copy, responsibilities to not store or copy cardholder data
move, and storage of cardholder data onto local onto their local personal computer or other media,
hard drives and removable electronic media, your policy should clearly prohibit such activities
unless explicitly authorized for a defined business except for personnel that have been explicitly
need. authorized to do so. Any such authorized personnel
are responsible for ensuring that cardholder data in
their possession is handled in accordance with all
PCI DSS requirements, as that remote personnels
environment is now considered a part of the
organizations cardholder data environment.
12.4 Ensure that the security policy and procedures Without clearly defined security roles and
clearly define information security responsibilities responsibilities assigned, there could be inconsistent
for all personnel. interaction with the security group, leading to
unsecured implementation of technologies or use of
outdated or unsecured technologies.
12.5 Assign to an individual or team the following Each person or team with responsibilities for
information security management responsibilities: information security management should be clearly
aware of their responsibilities and related tasks,
through specific policy. Without this accountability,
gaps in processes may open access into critical
resources or cardholder data.
12.5.1 Establish, document, and distribute

security policies and procedures.
12.5.2 Monitor and analyze security alerts and
information, and distribute to appropriate
personnel.
12.5.3 Establish, document, and distribute

security incident response and escalation
procedures to ensure timely and effective
handling of all situations.
12.5.4 Administer user accounts, including

additions, deletions, and modifications
12.5.5 Monitor and control all access to data.
12.6 Implement a formal security awareness If personnel are not educated about their security
program to make all personnel aware of the responsibilities, security safeguards and processes
importance of cardholder data security. that have been implemented may become
ineffective through errors or intentional actions.
12.6.1 Educate personnel upon hire and at least If the security awareness program does not include
annually. periodic refresher sessions, key security processes
and procedures may be forgotten or bypassed,
Note: Methods can vary depending on the role of resulting in exposed critical resources and
the personnel and their level of access to the cardholder data. The focus and depth of the initial
cardholder data. and refresher training can vary depending on the
role of the personnel, and should be tailored as
appropriate for the particular audience. For
example, sessions for database administrators may
be focused on specific technical controls and
processes, while training for retail cashiers may
focus on secure transaction procedures
Consider including ongoing awareness updates to

keep employees up to date with current policies and
procedures. The method of delivery may also vary to
suit the particular audience or training being
delivered. For example, initial and annual training
may be delivered via a formal hands-on or
computer-based training session, while ongoing
periodic updates may be delivered via e-mails,
posters, newsletters, etc.
12.6.1 Educate personnel upon hire and at least If the security awareness program does not include
annually. periodic refresher sessions, key security processes
and procedures may be forgotten or bypassed,
Note: Methods can vary depending on the role of resulting in exposed critical resources and
the personnel and their level of access to the cardholder data. The focus and depth of the initial
cardholder data. and refresher training can vary depending on the
role of the personnel, and should be tailored as
appropriate for the particular audience. For
example, sessions for database administrators may
be focused on specific technical controls and
processes, while training for retail cashiers may
focus on secure transaction procedures
Consider including ongoing awareness updates to

keep employees up to date with current policies and
procedures. The method of delivery may also vary to
suit the particular audience or training being
delivered. For example, initial and annual training
may be delivered via a formal hands-on or
computer-based training session, while ongoing
periodic updates may be delivered via e-mails,
posters, newsletters, etc.
12.6.2 Require personnel to acknowledge at least Requiring an acknowledgement by personnel in

annually that they have read and understood the writing or electronically helps ensure that they have
security policy and procedures. read and understood the security
policies/procedures, and that they have made and
will continue to make a commitment to comply with
these policies.
12.7 Screen potential personnel prior to hire to Performing thorough background investigations
minimize the risk of attacks from internal sources. prior to hiring potential personnel who are expected
(Examples of background checks include previous to be given access to cardholder data reduces the
employment history, criminal record, credit history, risk of unauthorized use of PANs and other
and reference checks.) cardholder data by individuals with questionable or
criminal backgrounds. It is expected that a company
Note: For those potential personnel to be hired for would have a policy and process for background
certain positions such as store cashiers who only checks, including their own decision process for
have access to one card number at a time when which background check results would have an
facilitating a transaction, this requirement is a impact on their hiring decisions (and what that
recommendation only. impact would be).
To be effective, the level of background checking

should be appropriate for the particular position.
For example, positions requiring greater
responsibility or that have administrative access to
critical data or systems may warrant more detailed
background checks than positions with less
responsibility and access. It may also be appropriate
for the process to cover internal transfers, where
personnel in lower risk positions, and who have not
already undergone a detailed background check, are
promoted or transferred to positions of greater
responsibility or access.
12.8 If cardholder data is shared with service If a merchant or service provider shares cardholder
providers, maintain and implement policies and data with a service provider, then certain
procedures to manage service providers, to include requirements apply to ensure continued protection
the following: of this data will be enforced by such service
providers.
12.8.1 Maintain a list of service providers. Keeping track of all service providers identifies
where potential risk extends to outside of the
organization.
12.8.2 Maintain a written agreement that The acknowledgement of the service providers
includes an acknowledgement that the service evidences their commitment to maintaining
providers are responsible for the security of proper security of cardholder data that it obtains
cardholder data the service providers possess. from its clients, and thus holds them accountable.
12.8.3 Ensure there is an established process for The process ensures that any engagement of a
engaging service providers including proper due service provider is thoroughly vetted internally by
diligence prior to engagement. an organization, which should include a risk
analysis prior to establishing a formal relationship
with the service provider.
12.8.4 Maintain a program to monitor service Knowing your service providers PCI DSS
providers PCI DSS compliance status at least compliance status provides assurance that they
annually. comply with the same requirements that your
organization is subject to.
If the service provider offers a variety of services,
this requirement applies only to those services
actually delivered to the client, and only those
services in scope for the clients PCI DSS
assessment. For example, if a provider offers
firewall/IDS and ISP services, a client who utilizes
only the firewall/IDS service would only include
that service in the scope of their PCI DSS
assessment.
12.9 Implement an incident response plan. Be Without a thorough security incident response plan
prepared to respond immediately to a system that is properly disseminated, read, and understood
breach. by the parties responsible, confusion and lack of a
unified response could create further downtime for
the business, unnecessary public media exposure, as
well as new legal liabilities.
12.9.1 Create the incident response plan to be The incident response plan should be thorough and
implemented in the event of system breach. contain all the key elements to allow your company
Ensure the plan addresses the following, at a to respond effectively in the event of a breach that
minimum: could impact cardholder data.
- Roles, responsibilities, and communication and

contact strategies in the event of a compromise
including notification of the payment brands, at a
minimum
- Analysis of legal requirements for reporting
compromises
- Coverage and responses of all critical system
components
- Reference or inclusion of incident response
procedures from the payment brands
12.9.2 Test the plan at least annually. Without proper testing, key steps may be missed
which could result in increased exposure during
an incident.
If within the last year the incident response plan
was activated in its entirety, covering all
components of the plan, a detailed review of the
actual incident and its response may be sufficient
to provide a suitable test. If only some
components of the plan were recently activated,
the remaining components would still need to be
tested. If no components of the plan were
activated in the last 12 months, the annual test
would need to encompass all components of the
plan.
12.9.3 Designate specific personnel to be Without proper testing, key steps may be missed
available on a 24/7 basis to respond to alerts. which could result in increased exposure during an
incident.
If within the last year the incident response plan
was activated in its entirety, covering all
components of the plan, a detailed review of the
actual incident and its response may be sufficient to
provide a suitable test. If only some components of
the plan were recently activated, the remaining
components would still need to be tested. If no
components of the plan were activated in the last
12 months, the annual test would need to
encompass all components of the plan.
12.9.4 Provide appropriate training to staff with
security breach response responsibilities.
12.9.5 Include alerts from intrusion- detection, These monitoring systems are designed to focus
intrusion-prevention, and file- integrity on potential risk to data, are critical in taking
monitoring systems. quick action to prevent a breach, and must be
included in the incident-response processes.
12.9.6 Develop a process to modify and evolve Incorporating lessons learned into the incident
the incident response plan according to lessons response plan after an incident helps keep the
learned and to incorporate industry plan current and able to react to emerging threats
developments. and security trends.
personnel.
is expected of them. All personnel should be aware of the sensitivity of data and their responsibilities for protecting it. For the purposes of Requiremen
drop in comparison to the 2010 report findings.
ail to identify the information assets that must be protected.
mitment to maintain proper security of cardholder data obtained from clientsand accepting accountability for the protection of that data remains a
PCI DSS compliance status) contributed towards its low compliance rating.

Top 20 Critical
Security Controls
NC 12.1 Examine the information security policy and verify that the policy is published
and disseminated to all relevant personnel (including vendors and business partners).
NA 12.1.1 Verify that the policy addresses all PCI DSS requirements.
NC 12.1.2.a Verify that an annual risk assessment process is documented that identifies
threats, vulnerabilities, and results in a formal risk assessment.
12.1.2.b Review risk assessment documentation to verify that the risk assessment
process is performed at least annually.
NC 12.1.3 Verify that the information security policy is reviewed at least annually and
updated as needed to reflect changes to business objectives or the risk
environment.
C16.9 12.2 Examine the daily operational security procedures. Verify that they are consistent
with this specification, and include administrative and technical procedures for each of
the requirements.
NC 12.3 Obtain and examine the usage policies for critical technologies and perform the
following:
NC 12.3.1 Verify that the usage policies require explicit approval from authorized parties
to use the technologies.
NC 12.3.2 Verify that the usage policies require that all technology use be authenticated
with user ID and password or other authentication item (for example, token).
NC 12.3.3 Verify that the usage policies require a list of all devices and personnel
authorized to use the devices.
NC 12.3.4 Verify that the usage policies require labeling of devices with information
that can be correlated to owner, contact information and purpose.
NC 12.3.5 Verify that the usage policies require acceptable uses for the technology.
NC 12.3.6 Verify that the usage policies require acceptable network locations for the
technology.
NC 12.3.7 Verify that the usage policies require a list of company- approved products.
NC 12.3.8 Verify that the usage policies require automatic disconnect of sessions for
remote-access technologies after a specific period of inactivity.
NC 12.3.9 Verify that the usage policies require activation of remote- access
technologies used by vendors and business partners only when needed by vendors
and business partners, with immediate deactivation after use.
NC 12.3.10.a Verify that the usage policies prohibit copying, moving, or storing of
cardholder data onto local hard drives and removable electronic media when
accessing such data via remote-access technologies.
12.3.10.b For personnel with proper authorization, verify that usage policies require
the protection of cardholder data in accordance with PCI DSS Requirements.
NC 12.4 Verify that information security policies clearly define information security
responsibilities for all personnel.
NC 12.5 Verify the formal assignment of information security to a Chief Security Officer or
other security-knowledgeable member of management.
Obtain and examine information security policies and procedures to verify that the
following information security responsibilities are specifically and formally assigned:
NC 12.5.1 Verify that responsibility for creating and distributing security policies and
procedures is formally assigned.
NC 12.5.2 Verify that responsibility for monitoring and analyzing security alerts and
distributing information to appropriate information security and business unit
management personnel is formally assigned.
C18.1 12.5.3 Verify that responsibility for creating and distributing security incident
response and escalation procedures is formally assigned.
NC 12.5.4 Verify that responsibility for administering user account and authentication
management is formally assigned.
NC 12.5.5 Verify that responsibility for monitoring and controlling all access to data is
formally assigned.
C9.1 12.6.a Verify the existence of a formal security awareness program for all personnel.
C9.2
12.6.b Obtain and examine security awareness program procedures and

documentation and perform the following:
NC 12.6.1.a Verify that the security awareness program provides multiple methods of
communicating awareness and educating personnel (for example, posters, letters,
memos, web based training, meetings, and promotions).
12.6.1.b Verify that personnel attend awareness training upon hire and at least
annually.
NC 12.6.2 Verify that the security awareness program requires personnel to

acknowledge, in writing or electronically, at least annually that they have read and
understand the information security policy.
NC 12.7 Inquire with Human Resource department management and verify that
background checks are conducted (within the constraints of local laws) on potential
personnel prior to hire who will have access to cardholder data or the cardholder data
environment.
12.8 If the entity shares cardholder data with service providers (for example, back-up
tape storage facilities, managed service providers such as Web hosting companies or
security service providers, or those that receive data for fraud modeling purposes),
through observation, review of policies and procedures, and review of supporting
documentation, perform the following:
NC 12.8.1 Verify that a list of service providers is maintained.
C12.13 12.8.2 Verify that the written agreement includes an acknowledgement by the
service providers of their responsibility for securing cardholder data.
NC 12.8.3 Verify that policies and procedures are documented and were followed
including proper due diligence prior to engaging any service provider.
NA 12.8.4 Verify that the entity maintains a program to monitor its service providers
PCI DSS compliance status at least annually.
C18.1 12.9 Obtain and examine the Incident Response Plan and related procedures and
perform the following:
C18.2 12.9.1.a Verify that the incident response plan includes:
C18.4
- Roles, responsibilities, and communication strategies in the event of a compromise
including notification of the payment brands, at a minimum:
- Analysis of legal requirements for reporting compromises (for example, California
Bill 1386 which requires notification of affected consumers in the event of an actual
or suspected compromise for any business with California residents in their
database)
- Coverage and responses for all critical system components
- Reference or inclusion of incident response procedures from the payment brands
12.9.1.b Review documentation from a previously reported incident or alert to

verify that the documented incident response plan and procedures were followed.
C18.2 12.9.2 Verify that the plan is tested at least annually.
NC 12.9.3 Verify through observation and review of policies, that designated personnel
are available for 24/7 incident response and monitoring coverage for any evidence
of unauthorized activity, detection of unauthorized wireless access points, critical
IDS alerts, and/or reports of unauthorized critical system or content file changes.
C18.5 12.9.4 Verify through observation and review of policies that staff with
C18.6 responsibilities for security breach response are periodically trained.
NC 12.9.5 Verify through observation and review of processes that monitoring and
responding to alerts from security systems including detection of unauthorized
wireless access points are covered in the Incident Response Plan.
NC 12.9.6 Verify through 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.
ng it. For the purposes of Requirement 12, personnel refers to full-time and part-time employees, temporary employees, contractors and consultants
he protection of that data remains a taxing compliance issue

(For In-place requirements)

Identify the documented information security policy. 6 ### 1

Describe how the documented policy was observed to be published and
disseminated to:
i. All relevant personnel
ii. All relevant vendors and business partners
Identify the relevant personnel who were interviewed to confirm that they received
the policy.
Describe how the policy addresses all applicable PCI DSS requirements. 6 ###
Identify the document that defines the annual risk assessment process. Describe 1 ###
how the documented process:

i. Identifies threats and
vulnerabilities
ii. Results in formal risk assessment
Describe how observed risk assessment results confirm that: 1 ###

i. The risk assessment process is performed at least annually.
ii. The documented risk assessment process was followed.
Indetify the document requiring that the information security polcy is: 6 ### 1
Reviewed at least annually and updated as neededto reflect changes to business
objectives or risk environment
Identify the personnel interviewd who confirmed the above
Describe how the above were observed.
Identify the documented daily operational security procedures. Describe how the 6 ###
documented procedures:
i. Are consistent with PCI DSS requirements
ii. Include administrative procedures for each requirement
iii. Include technical procedures for each requirement
Describe how the daily operational security procedures were observed to be
implemented including:
i. Administrative procedures for each requirement
ii. Technical procedures for each requirement
6 ###
Identify critical technologies in use. 6 ### 1

For each identified critical technology:
i. Identify the documented usage policies defining proper use of the technology.
ii. Describe how the documented policies require explicit approval from authorized
parties to use the technology.
iii. Describe how explicit approval for use of the technology was observed to be
implemented.
For each identified critical technology: 6 ###

i. Describe how the documented policies require that use of the technology be
authenticated
with user ID and password or other authentication item.
ii. Describe how the required authentication for use of the technology was observed
to be implemented.
For each identify critical technology: 6 ### 1

Describe how the documented policies require:
o A list of all devices
o A list of personnel authorized to use the devices Describe how the following was
observed to be implemented:
o A list of all devices
o A list of personnel authorized to use the devices
For each identify critical technology: 6 ###
Describe how the documented policies require labeling of devices with information
that can be correlated to:
o Owner
o Contact information o Purpose
Describe how labeling was observed to be implemented which correlates to: o
Owner
o Contact information
o Purpose
For each identify critical technology: 6 ### 1

Describe how the documented policies require acceptable uses for the technology.
Describe how requirements for acceptable uses of the technology were observed to
beimplemented.

Describe how the documented policies require acceptable uses for the technology.
Describe how requirements for acceptable network locations were observed to be
implemented.

Describe how the documented policies require a list of company-approved products.
Describe how the list of company-approved products was observed to be
implemented.
Identify the remote-access technologies used. 6 ###
For each remote-access technology:
Describe how the documented policies require automatic disconnect of sessions
after a specific period of inactivity.
Describe how automatic disconnect after a specific period of inactivity was observed
to be implemented.
Identify the remote-access technologies used by vendors and business partners. 6 ###
For each remote-access technology:
Describe how the documented policies require:
o Activation of the technology only when needed
o Immediate deactivation of the technology after use
The technology is activated only when needed.
The technology is immediately deactivated after use.
Describe how the documented policies prohibit the following for personnel 6 ###
accessing cardholder data via remote-access technologies:
i. Copying of cardholder data onto local hard drives and removable electronic media
ii. Moving of cardholder data onto local hard drives and removable electronic media
iii. Storage of cardholder data onto local hard drives and removable electronic media
Describe how it was observed that the following are implemented for personnel
accessing cardholder data via remote-access technologies:
Prohibit the copying of cardholder data onto local hard drives and removable
electronic media
Prohibit the moving of cardholder data onto local hard drives and removable
electronic media
Prohibit the storage of cardholder data onto local hard drives and removable
electronic media
Identify the documentation that defines whether any authorized business need for 6 ###
copying, moving, or storing cardholder data onto local hard drives or removable
electronic media via remote-access technologies exists.
For each defined business need:
Identify how explicit authorization was observed to be implemented for the copying,
moving, or storage of cardholder data onto local hard drives or removable electronic
media.
Describe how the documented policies require the protection of cardholder data in
accordance with PCI DSS Requirements, for all personnel with proper authorization.
Describe how the protection of cardholder data was observed to be implemented in
accordance with PCI DSS Requirements.
Describe how the security policy and procedures clearly define information security 6 ### 1
responsibilities for all personnel.
Describe how interviewed personnel demonstrated they are aware of their
information security responsibilities.
Identify the document that formally assigns responsibility for information security to a 6 ### 1
Chief Security Officer or other security-knowledgeable member of management.
Describe how the assignment of responsibility for information security was observed
to be implemented.
Identify the document that formally assigns responsibility for: 6 ###

i. Creating security policies and procedures
ii. Distributing security policies and procedures
Describe how assigned responsibilities were observed to be implemented for:
i. Creating security policies and procedures
ii. Distributing security policies and procedures
Identify the document that formally assigns responsibility for: 6 ###
Monitoring and analyzing security alerts
Distributing information to appropriate information security and business unit
management personnel
Describe how assigned responsibilities were observed to be implemented for:
i. Monitoring and analyzing security alerts
ii. Distributing information to appropriate information security and business unit
management personnel
Identify the document that formally assigns responsibility for: ### 1

Creating and distributing security incident response and escalation procedures
Describe how the above assigned responsibilities were observed to be 4
implemented.
Identify the document that formally assigns responsibility for administering user 6 ###
account and authentication management.
Describe how the assignment of responsibility for administering user account and
authentication management was observed to be implemented.
Identify the document which formally assigns responsibility for: 6 ###

i. Monitoring all access to data
ii. Controlling all access to data
Describe how the assignment of responsibilities were observed to be
implemented for:
i. Monitoring all access to data
ii. Controlling all access to data
Identify the document that defines a formal security awareness program for all 6 ### 1
personnel. Describe how a formal security awareness program was observed to be
implemented for all
personnel.
6 ###
Identify the document defining the methods of communicating awareness and 6 ###
educating personnel.
Identify the methods observed for communicating awareness and educating
personnel.
Identify the document requiring that all personnel attend awareness training: 6 ###
i. Upon hire
ii. At least annually
Describe how it was observed that all personnel attend awareness training:
Upon hire
At least annually
Identify the document that requires: 6 ###

i. All personnel to acknowledge that they have read and understand the information
security
policy.
ii. All personnel to provide an acknowledgement at least annually.
i. All personnel acknowledge that they have read and understand the information
security policy.
ii. All personnel provide an acknowledgement at least annually.
Identify the document requiring that backgroud checks be conducted: 6 ###

On potential personnel who wil have access to the cardholder data environment
Prior to hiring personnel
Identify the HR personnel who were interviewed to confirm the above
Describe how the above was observed.
### 1 1
Identify all service providers with whom cardholder data is shared. ### 1 1
Identify the document which includes a list of all service providers with whom
cardholder data
is shared.
Describe how the documented list of service providers was observed to be 2
maintained (kept up-to-date).
For each service provider with whom cardholder data is shared: ### 1 1
Identify the document that includes service provider acknowledgment of their
responsibility for securing cardholder data.
2
Identify the document that defines procedures for proper due diligence prior to ### 1 1
engaging any service provider.
Describe how the procedures for proper due diligence were observed to be
implemented.
2
Identify the document that: ### 1 1

i. Defines a program to monitor service providers PCI DSS compliance status
ii. Requires that service providers PCI DSS compliance status be monitored at least
annually
Describe how the program to monitor service providers PCI DSS compliance status
was observed to be implemented.
Describe how service providers PCI DSS compliance status was observed to be
monitored at least annually.
2
###
4
Identify the incident response plan and procedure document(s). Describe how the ###
document includes:
i. Roles and responsibilities
ii. Communication strategies
iii. Requirement for notification of the payment brands
iv. Specific incident response procedures
v. Business recovery and continuity procedures
vi. Data back-up processes
vii. Analysis of legal requirements for reporting compromises 4
viii. Coverage for all critical system components
ix. Responses for all critical system components
x. Reference or inclusion of incident response procedures from the payment brands
Identify documentation from a previously reported incident or alert. ###

Describe how the documentation verifies that the defined incident response plan 4
and
procedures were followed.
Identify the document that: ###
i. Defines procedures for testing the incident response plan
ii. Requires the plan be tested at least annually
Identify responsible personnel who were interviewed to confirm that:
i. The incident response plan is tested according to the defined procedures.
ii. The plan is tested at least annually.
Describe how it was observed that the incident response plan is:
i. Tested according to the defined procedures
ii. Tested at least annually
4
Identify the document that designates personnel to be available for: i. 24/7 incident ###
monitoring
ii. 24/7 incident response
Identify the document requiring 24/7 incident response and monitoring coverage
for:
i. Any evidence of unauthorized activity
ii. Detection of unauthorized wireless access points
iii. Critical IDS alerts
iv. Reports of unauthorized critical system or content file changes
Describe how it was observed that 24/7 incident response and monitoring
coverage is provided for: 4
i. Evidence of unauthorized activity
ii. Detection of unauthorized wireless access points
iii. Critical IDS alerts
iv. Reports of unauthorized critical system or content file changes
Identify the document requiring that staff with security breach responsibilities are ###
periodically trained.
Describe how it was observed that staff with security breach responsibilities are
periodically trained. 4
Identify the document that defines how the following are monitored: i. Alerts from ###
intrusion-detection/intrusion-prevention
ii. Alerts from file-integrity monitoring systems
iii. Detection of unauthorized wireless access points
Identify the document that defines how the following are responded to:
i. Alerts from intrusion-detection/intrusion-prevention
Describe how processes for monitoring the following were observed to be
implemented:
i. Alerts from intrusion-detection / intrusion-prevention
ii. Alerts from file-integrity monitoring systems.
iii. Detection of unauthorized wireless access points 4
Describe how processes for responding to the following were observed to be
implemented:
i. Alerts from intrusion-detection/intrusion-prevention
Identify the document which defines the processes to mofify ane evolve the ###
incident response plan:
According to lessons learned
To incorporate industry development 4
Describe how the above processes were observed to be implemented.
216 ### 5 14
contractors and consultants who are resident on the entitys site or otherwise have access to the cardholder data environment.
C-VT C D In Place? I Severity Proofs / Stage of implementation

t
e
1 1 1 rN 6
m
e
d
i
a
r
N y
1 C
N 6
N o
1 n
N 1
t
r
o
l
N
1 N 1
N
1 1 1 N 6
N
1 N 6
N
1 N 6
N
1 1 1 N 6
N
1 1 N 6
N
1 1 1 N 6
N
1 N 6
N
1 1 1 N 6
N
1 1 N 6
N
1 N 6
N
1 1 N 6
N
1 1 N 6
N
1 N 6
N
1 N 6
N
1 1 1 N 6
N
1 1 1 N 6
N
1 N 6
N
1 N 6
N
1 1 1 N 4
N
1 N 6
N
1 N 6
N
1 1 1 N 6
N
1 N 6
N
1 N 6
N
1 N 6
N
1 N 6
N
1 N 6
N
1 1 1 N 2
N
1 1 1 N 2
N
1 1 1 N 2
N
1 1 1 N 2
N
1 1 1 N 2
N
1 N 4
N
1 N 4
N
1 N 4
N
1 N 4
N
1 N 4
N
1 N 4
N
1 N 4
N
1 N 4
14 18 44 Y 216
N
C
vironment.

IT Types
Server
Firewall & Router
Switches
Mail
DNS
Database
Application
Web application
Web server
WAP
POS
Others
Criticality
High
Medium
Low

PCI Compliance Dashboard - v10

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

PCI Compliance Dashboard - v10

Transféré par

Droits d'auteur :

Formats disponibles

Table of content

Introduction and News

PCI Compliance Dashboard VERSION 10

Add an Executive Summary Tab Including # of requirements, % of compliance, December 2011

WHAT'S NEW IN THIS VERSION

Compliance Dashboard home page

PCI 30 Seconds Newsletters

Didier Godart (D@dgozone.com).

unprotect them at any time. No password

mediation, estimated, Comments and select

sating controls sheet

Swathy Anand About Swathy About Fuze Network

Tony Wilson About Tony About Indelible data

Dynamic Packet FilteringSee Stateful Inspection.

Host Main computer hardware on which computer software is resident.

Return to Table of content

Define your Card Data Environment (CDE)

Return to table of content

Includes a list of common security parameter settings 2.2.3

Policies, Procedures and standards documentation

Includes policy and procedures for changing of Vendor 2.1

Includes types of data retained (No sensitive data)

Includes a statement preventing storage of CVV and

Includes a statement enforcing masking of PAN when

Includes the selection process of key custodians 3.6.8

Tokenization Process Description of the processes and mechanisms used to Optional

Includes a statement enforcing review of Custom

Includes a statement enforcing separation of 6.4

Includes a statement enforcing separation of duties 6.4.2

Secure coding/Testing Software Development Secure Coding Guidelines and 6.5-6.5.9

Includes a statement enforcing execution of internal 11.2.3

Includes a statement restricting access rights for 7.1.1

Includes a statement enforcing assignment of privileges 7.1.2

Includes a statement enforcing assignment of a unique 8.1

Includes a statement enforcing removal or disabling of 8.5.5

Includes management of Vendor remote access (for 8.5.6

Includes a statement preventing Generic /Share and 8.5.8

Includes a statement enforcing a minimum password 8.5.10

Risk Assessment Process Risk assessment process 12.1

Annual Risk Assessment Annual risk assessment reports 12.1

Includes a statement requiring that all technology use 12.3.2

Includes a statement prohibiting copying, moving, or 12.3.10

Security Policy Security policy for employee and contractors 12.1

Includes assignment of responsibility for creating and 12.5.1

Written agreement that includes an acknowledgement 12.8.2

Roles, responsibilities, and communication strategies in

Includes Assignment of specific personnel to be 12.9.3

Compliance % per requirement

PCI Severity per requirements

Make a list of all cryptographic keys used within the scope.

Key Id Purpose Location Key custodians Status (date) Key Length

C1.7 In addition to an inventory of hardware, organizations should - N 0

C1.9 Network access control can be used to monitor authorized systems - N 0

C2 Critical Control 2: Inventory of Authorized and 0.00% 0

C2.4 Deploy application white listing technology that allows systems to - N 0

C2.5 Virtual machines and/or air-gapped systems should also be used to - N 0

C3 Critical Control 3: Secure Configurations for 45.45% 5

C3.6 The master images themselves must be stored on securely - N 0

C3.8 At least once a month, run assessment programs on a varying - N 0

C3.10 Implement and test an automated configuration monitoring system - N 0

C4 Critical Control 4: Continuous Vulnerability 20.00% 2

C5 Critical Control 5: Malware Defenses 37.50% 3

C5.4 Organizations should configure systems so that they conduct an - N 0