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
PCI Compliance Dashboard VER
Please feel free to use this compliance dashboard to sustain your PC

with your internal team, QSA and acquiring banks.
Comments, feedbacks and suggestions are welcome. Send them to Di
Some sheets are protected to prevent accidental changes. You may un

required.
V0.1
V0.2
V0.3
V0.4
V0.5
V0.6
V0.7
V0.8
V0.9
V10
Return to Table of content
PCI Compliance Dashboard VERSIO
Please feel free to use this compliance dashboard to sustain your PCI comp
with your internal team, QSA and acquiring banks.
Comments, feedbacks and suggestions are welcome. Send them to Didier Go
Some sheets are protected to prevent accidental changes. You may unprotec
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, e
owner responsible for actions)
7.In case of compensating controls provide the description within the associated compensating contro
8.Control your compliance status through the Excutive summary board (Executive sheet) and associat
Severity)
Version History
Requirements and testing procedures
Add merchant type for each requirements
Include Prioritized Approach milestones as defined by PCIco

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
Add a sheet" What is my merchant Type?" with the full description of the merchant
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
Add Guidance
for each
requirements from the "Navigating PCI DSS V2.0"
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,
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.
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.
1.Navigation:
Add Table of
contentthrough
and navigation
links summary" and " Charts"
4.View your compliance
progress
the "Executive
2.Rename
sheet "PCI Actor" to "PCI Team"
sheets.
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 Subcontrols 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)
Adapt SANS numerotation to new version (Version 3.1 October 3, 2011)
WHAT'S NEW IN THIS VERSION
Update the documentation sheet with the list of (required or optional) technical and
non-technical documents together with their associated PCI DSS requirements.
Update Scope sheet with Criticality, Patch level, Scan date and Scan report location
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
PCI
PCI
PCI
PCI
PCI
PCI
PCI
PCI
PCI
PCI
PCI
PCI
PCI
PCI
PCI
PCI
PCI
PCI
PCI
PCI
PCI
PCI
PCI
PCI
PCI
PCI
PCI
PCI
PCI
30
30
30
30
30
30
30
30
30
30
30
30
30
30
30
30
30
30
30
30
30
30
30
30
30
30
30
30
30
30
Seconds newsletter #1 - PCI what are you talking about?

seconds newsletter #2 - Payment processing terminology and workflow
seconds newsletter #3 - Distributing roles
seconds newsletter #4 - Merchant levels
seconds newsletter #5 - What is your type?
seconds newsletter #6 - PCI DSS in a nutshel
seconds newsletter #7 - Define the scope of an assessment
seconds newsletter #8 - certification program, striving for quality
seconds newsletter #9 - The validation toolbox
seconds newsletter #10 - Prioritized Approach
seconds newsletter #11 - Tokenization
seconds newsletter #12 - the gap analysis process
seconds newsletter #3 - Compensating controls, magic trick or mirage?
seconds newsletter #14 - The world is not perfect!
seconds newsletter #15 - Nice Look!
seconds newsletter #16 Is your organization behaving like a fashion victim or a clown?
seconds newsletter #17 Why are my scan reports so thick? - Impact of "potential" vulnerabili
seconds newsletter #18 What to do if compromised?
seconds newsletter #19 - Your PCI Logbook. What's required in terms of Log management?
seconds newsletter #20 PCI DSS and SANS Top 20 Critical Security Controls: The Sumo match
seconds newsletter #21 - "Qualified" internal scanning staff using "appropriate" scanning tools
seconds newsletter #22 - Don't get lost in translation with Executives. Get them listening.
seconds newsletter # 23 Introduction to Risk Assessment
second newsletter #24 - PCIco strengthens the scoping rules
seconds newsletter #25 - A New Standard is Born.
seconds newsletter #26 - PCIP is it worth it?
seconds newsletter #27 -Static versus Active Protection Systems. What Impact on Quarterly Sc
Seconds newsletter #28 - The PCI Library - What docs are required for compliance?
seconds newsletter #29 - Do all PCI DSS requirements apply?
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
d VERSION 10
ain your PCI compliance journey, to support the discussion

them to Didier Godart (D@dgozone.com).
You may unprotect them at any time. No password
e requirements
roof, Stage,remediation, estimated, Comments and select the
ated compensating controls sheet

cutive sheet) and associated charts (% of compliance and
Contributors
Jan-11
Feb 2011
Peter Hill
Didier Godart
Risk Product Manager Rapid7
+32 498787744
SkypeID Dgozone
didier_godart@rapid7.com
August 2011
Didier Godart
+32 498787744
SkypeID Dgozone
October 2011
Didier Godart
+32 498787744
SkypeID Dgozone
November 2011 Didier Godart

+32 498787744
SkypeID Dgozone
December 2011 Didier Godart
+32 498787744
SkypeID Dgozone
May 2012
Swathy Anand
Vice President - Project
Management
Fuze Network
swathyanand@gmail.com
Didier Godart
+32 498787744
SkypeID Dgozone
Tony Wilson
Managing Director
Indelible Data (a division of
Indelible Designs Limited)
tony@indelible-data.co.uk
July 2012
"Didier Godart
+32 498787744
SkypeID Dgozone
"
About Didier
About Didier
About Swathy
About Didier
About Tony
About Didier
April 2013
June 2013
"Didier Godart
+32 498787744
SkypeID Dgozone
"Didier Godart
Founder Dgozone
(www.dgozone.com)
"
+32 498787744
SkypeID Dgozone
d@dgozone.com
"
n victim or a clown?
of "potential" vulnerabilities
of Log management?
Controls: The Sumo match.
ppropriate" scanning tools - What does that mean?
. Get them listening.
at Impact on Quarterly Scans?

r compliance?
comply with PCI DSS
About Didier
About Didier
ernal scans?
About Rapid7
Join the community!
About Rapid7
Join the community!
About Fuze Network
About Rapid7
Join the community!
About Indelible data
About Rapid7
Join the community!
About Rapid7
Join the community!
About Rapid7
Join the community!

AAA
Access Control
Account Data
Account Number
Acquirer
Adware
AES
ANSI
Anti-Virus
Application
Audit Log
Audit Trail
ASV
Authentication
Authentication Credentials
Authorization
B
Backup
Bluetooth
C
Cardholder
Cardholder Data
Cardholder Data
Environment
Card Verification Code or

Value
CERT
CIS
Column-Level Database
Encryption
Compensating Controls
Compromise
Console
Consumer
Cryptography
D
Database
Database Administrator
Default Accounts
Default Password
Degaussing
Disk Encryption
DMZ
DNS
DSS
Dual Control
Dynamic Packet Filtering
ECC
Egress Filtering
Encryption
Encryption Algorithm
Entity
File Integrity Monitoring

File-Level Encryption
FIPS
Firewall
Forensics
FTP
G
GPRS
GSM
H
Hashing
Host
Hosting Provider
HTTP
HTTPS
Hypervisor
I
ID
IDS
IETF
Index Token
Information Security
Information System
Ingress Filtering
Insecure
Protocol/Service/Port
IP
IP Address
IP Address Spoofing
IPS
IPSEC
ISO
Issuer
Issuing services
K
Key
Key Management
L
LAN
LDAP
Log
LPAR
M
MAC
MAC Address
Magnetic-Stripe Data
Mainframe
Malicious Software /
Malware
Masking
Merchant
Monitoring
MPLS
NAT
Network
Network Administrator
Network Components
Network Security Scan
Network Segmentation
NIST
NMAP
Non-Consumer Users
NTP
O
Off-the-Shelf
Operating System / OS
OWASP
P
PA-QSA
PAN
Password / Passphrase
Pad
Parameterized Queries
PAT
Patch
Payment Application
Payment Cards
PCI
PDA
PED
Penetration Test
Personnel
Personally Identifiable
Information
PIN
PIN Block
POI
Policy
POS
Private Network
Procedure
Protocol
PTS
Public Network
PVV
Q
QSA
RADIUS
RBAC
Remote Access
Removable Electronic
Media
ROC
Report on Validation
Re-keying
Remote Lab Environment

Reseller / Integrator
RFC 1918
Risk Analysis / Risk
Assessment
Rootkit
Router
RSA
S
Salt
Sampling
SANS
Scoping
SDLC
Secure Coding
Secure Wipe
Security Officer
Security Policy
Security Protocols
SAQ
Sensitive Area
Sensitive Authentication
Data
Separation of Duties
Server
Service Code
Service Provider
SHA-1/SHA-2
Smart Card
SNMP
Spyware
SQL
SQL Injection
SSH
SSL
Stateful Inspection
Strong Cryptography
SysAdmin
System Components
System-level object
T
TACACS
TCP
TDES
TELNET
Threat
TLS
Token
Transaction Data
Trojan
Truncation
Trusted Network
Two-Factor Authentication
U
Untrusted Network
V
Virtualization
Virtual Machine Monitor

(VMM)
Virtual Machine
Virtual Appliance (VA)
Virtual Switch or Router
Virtual Terminal
VLAN
VPN
Vulnerability
W
WAN
Web Application
Web Server
WEP
Wireless Access Point

WLAN
WPA/WPA2
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.
Mechanisms that limit availability of information or information-processing resources only to authorized persons or
applications.
Account data consists of cardholder data plus sensitive authentication data. See Cardholder Data and Sensitive
Authentication Data
See Primary Account Number (PAN).
Also referred to as acquiring bank or acquiring financial institution. Entity that initiates and maintains
relationships with merchants for the acceptance of payment cards.
Type of malicious software that, when installed, forces a computer to automatically display or download
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).
Acronym for American National Standards Institute. Private, non-profit organization that administers and
coordinates the U.S. voluntary standardization and conformity assessment system.
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.
Includes all purchased and custom software programs or groups of programs, including both internal and external
(for example, web) applications.
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.
See Audit Log.
Acronym for Approved Scanning Vendor. Company approved by the PCI
SSC to conduct external vulnerability scanning services.
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
Combination of the user ID or account ID plus the authentication factor(s) used to authenticate an individual,
device, or process,
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
Duplicate copy of data made for archiving purposes or for protecting against damage or loss.
Wireless protocol using short-range communications technology to facilitate transmission of data over short
C
Non-consumer or consumer customer to whom a payment card is issued to or any individual authorized to use the
payment card.
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.
The people, processes and technology that store, process or transmit cardholder data or sensitive authentication
data, including any connected system components.
Also known as Card Validation Code or Value, or Card Security Code.

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)
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.
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.
Technique or technology (either software or hardware) for encrypting contents of a specific column in a database
versus the full contents of the entire database. Alternatively, see Disk Encryption or File-Level Encryption.
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.
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.
Screen and keyboard which permits access and control of a server, mainframe computer or other system type in a
networked environment.
Individual purchasing goods, services, or both.
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
Structured format for organizing and maintaining easily retrievable information. Simple database examples are
tables and spreadsheets.
Also referred to as DBA. Individual responsible for managing and administering databases.
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.
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.
Also called disk degaussing. Process or technique that demagnetizes the disk such that all data stored on the disk
is permanently destroyed.
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.
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.
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.
Acronym for Data Security Standard and also referred to as PCI DSS.
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.)
See Stateful Inspection.
Acronym for Elliptic Curve Cryptography. Approach to public-key cryptography based on elliptic curves over finite
fields. See Strong Cryptography.
Method of filtering outbound network traffic such that only explicitly allowed traffic is permitted to leave the
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.
A sequence of mathematical instructions used for transforming unencrypted text or data to encrypted text or data,
and back again. See Strong Cryptography.
Term used to represent the corporation, organization or business which is undergoing a PCI DSS review.
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.
Technique or technology (either software or hardware) for encrypting the full contents of specific files. Alternatively,
see Disk Encryption or Column-Level Database Encryption.
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.
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.
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.
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.
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 data,
such as e-mail and web browsing.
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.
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).
Main computer hardware on which computer software is resident.
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.
Acronym for hypertext transfer protocol. Open internet protocol to transfer or convey information on the World
Wide Web.
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 webbased logins.
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).
Identifier for a particular user or application.

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.
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.
A cryptographic token that replaces the PAN, based on a given index for an unpredictable value.
Protection of information to insure confidentiality, integrity, and availability.
Discrete set of structured data resources organized for collection, processing, maintenance, use, sharing,
dissemination, or disposition of information.
Method of filtering inbound network traffic such that only explicitly allowed traffic is permitted to enter the network.
A protocol, service, or port that introduces security concerns due to the lack of controls over confidentiality 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.
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.
Also referred to as internet protocol address. Numeric code that uniquely identifies a particular computer on the
Internet.
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.
Acronym for intrusion prevention system. Beyond an IDS, an IPS takes the additional step of blocking the
attempted intrusion.
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.
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.
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.
Examples of issuing services may include but are not limited to authorization and card personalization.
K
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.
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 communications
line, often in a building or group of buildings.
Acronym for Lightweight Directory Access Protocol. Authentication and authorization data repository utilized for
querying and modifying user permissions and granting access to protected resources.
See Audit Log.
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
Acronym for message authentication code. In cryptography, it is a small piece of information used to authenticate
a message. See Strong Cryptography.
Abbreviation for media access control address. Unique identifying value assigned by manufacturers to network
adapters and network interface cards.
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.
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.
Software designed to infiltrate or damage a computer system without the owner's knowledge or consent. Such
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.
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.
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.
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.
Acronym for multi protocol label switching. Network or telecommunications mechanism designed for connecting a
group of packet-switched networks.
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.
Two or more computers connected together via physical or wireless means.
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.
Include, but are not limited to firewalls, switches, routers, wireless access points, network appliances, and other
security appliances.
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. isolates system components that store, process, or transmit cardholder data from systems
Network segmentation
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.
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.
Security-scanning
software that maps networks and identifies open ports in network resources.
Individuals, excluding cardholders, who access system components, including but not limited to employees,
administrators, and third parties.
Acronym for Network Time Protocol. Protocol for synchronizing the clocks of computer systems, network devices
and other system components.
O
Description of products that are stock items not specifically customized or designed for a specific customer or user
and are readily available for use.
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.
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
Acronym for Payment Application Qualified Security Assessor, company approved by the PCI SSC to conduct
assessments on payment applications against the PA-DSS.
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.
A string of characters that serve as an authenticator of the user.
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
A means of structuring SQL queries to limit escaping and thus prevent injection attacks.
Acronym for port address translation and also referred to as network address port translation. Type of NAT that
also translates the port numbers.
Update to existing software to add functionality or to correct a defect.
Any application that stores, processes, or transmits cardholder data as part of authorization or settlement
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.
Acronym for Payment Card Industry.
Acronym for personal data assistant or personal digital assistant. Handheld mobile devices with capabilities
such as mobile phones, e-mail, or web browser.
PIN entry device
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.
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.
Information that can be utilized to identify an individual including but not limited to name, address, social security
number, phone number, etc.
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.
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.
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 payment transactions.
Organization-wide rules governing acceptable use of computing resources, security practices, and guiding
development of operational procedures
Acronym for point of sale. Hardware and/or software used to process payment card transactions at merchant
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.
Descriptive narrative for a policy. Procedure is the how to for a policy and describes how the policy is to be
implemented.
Agreed-upon method of communication used within networks. Specification describing rules and procedures that
computer products should follow to perform activities on a network.
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.
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
Acronym
fortechnologies.
PIN verification value. Discretionary value encoded in magnetic stripe of payment card.
Q
Acronym for Qualified Security Assessor, company approved by the PCI SSC to conduct PCI DSS on-site
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 their
job responsibilities.
Access to computer networks from a remote location, typically originating from outside the network. An example of
technology for remote access is VPN.
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.
Report on Compliance - Report containing details documenting an entitys compliance status with the PCI DSS.
Also referred to as ROV. Report containing details documenting a payment applications compliance with the PCI
Process of changing cryptographic keys. Periodic re-keying limits the amount of data encrypted by a single key.
A lab that is not maintained by the PA-QSA.
An entity that sells and/or integrates payment applications but does not develop them.
The standard identified by the Internet Engineering Task Force (IETF) that defines the usage and appropriate
address ranges for private (non-internet routable) networks.
Process that identifies valuable system resources and threats; quantifies loss exposures (that is, loss potential)
based on estimated frequencies and costs of occurrence; and (optionally) recommends how to allocate resources to
countermeasures so as to minimize total exposure.
Type of malicious software that when installed without authorization, is able to conceal its presence and gain
administrative control of a computer system.
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.
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
Random string that is concatenated with other data prior to being operated on by a hash function. See also Hash.
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.
Acronym for SysAdmin, Audit, Networking and Security, an institute that provides computer security training and
professional certification. (See www.sans.or
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.
Acronym for system development life cycle. Phases of the development of a software or computer system that
includes planning, analysis, design, testing, and implementation.
The process of creating and implementing applications that are resistant to tampering and/or compromise.
Also called secure delete, a program utility used to delete specific files permanently from a computer system.
Also called secure delete, a program utility used to delete specific files permanently from a computer system.
Set of laws, rules, and practices that regulate how an organization manages, protects, and distributes sensitive
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.
Acronym for Self-Assessment Questionnaire. Tool used by any entity to validate its own compliance with the PCI
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.
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.
Practice of dividing steps in a function among different individuals, so as to keep a single individual from being able
to subvert the process.
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.
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.
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.
Acronym for Secure Hash Algorithm. A family or set of related cryptographic hash functions including SHA-1 and
SHA-2. See Strong Cryptography.
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.
Acronym for Simple Network Management Protocol. Supports monitoring of network attached devices for any
conditions that warrant administrative attention.
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
relational database management systems.
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.
Abbreviation for Secure Shell. Protocol suite providing encryption for network services like remote login or remote
file transfer.
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.
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.
Cryptography based on industry-tested and accepted algorithms, along with strong key lengths and proper keymanagement 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.
Abbreviation for system administrator. Individual with elevated privileges who is responsible for managing a
computer system or network.
Any network component, server, or application included in or connected to the cardholder data environment.
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
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.
Acronym for Transmission Control Protocol. Basic communication language or protocol of the Internet.
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.
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.
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
Acronym
for Transport Layer Security. Designed with goal of providing data secrecy and data integrity between
two communicating applications. TLS is successor of SSL.
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.
Data related to electronic payment card transaction.
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.
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.
Network of an organization that is within the organizations ability to control or manage.
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
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 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.
The VMM is included with the hypervisor and is software that implements virtual machine hardware abstraction. It
manages the system's processor, memory, and other resources to allocate what each guest operating system
requires.
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.
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.
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.
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.
Abbreviation for virtual LAN or virtual local area network. Logical local area network that extends beyond a
single traditional physical local area network.
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.
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
computer system.
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.
Computer that contains a program that accepts HTTP requests from web clients and serves the HTTP responses
(usually web pages).
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.
Network that connects computers without a physical connection to wires.
Acronym for wireless local area network. Local area network that links two or more computers or devices without
Acronym 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
systems and segments that directly attach or support cardholder processing"
Define your Card Data Environment (CDE)
Perimeter
IP address/URL
Name
Type
Internal
IP address/URL
Name
Type
Scope Definition
older data or sensitive authentication data and those

dholder processing"
Purpose
Owner
System Admin
Criticality
Patch level
Last Scan date
Purpose
Owner
System Admin
Criticality
Patch level
last Scan date
Scope Definition
Scan report location
Last scan report
ORGANIZATION NAME:
Merchant Type:
PCI-DSS REQUIREMENTS
1
2
3
4
5
6
7
8
9
10
11
12
Click on above
requirements to
access the
associated sheet.
TYPE HERE YOUR COMPANY NAME
You MUST select in cell B3 your Merchant type (A, B, C, C-
% compliance # of Requirements # in Place # not in Place

75%
0%
5%
22%
0%
0%
0%
0%
0%
0%
0%
0%
28
26
37
9
7
36
9
33
29
33
25
44
21
0
2
2
0
0
0
0
0
0
0
0
7
26
35
7
7
36
9
33
29
33
25
44
#
Compensating
Controls
0
0
0
0
0
0
0
0
0
0
0
0
Severity
24
67
135
14
14
129
36
111
111
132
64
216
t type (A, B, C, C-
(See the merchant types)
Documentation
Return to table of content
Make the list of all your documentation related to your PCI project.
Techical documentation
Ref
Ref1
Ref2
Ref3
Title/Topic
Description
PCI DSS Req
Global network diagram
Global network diagram (Confidential)
1.1
Lightened network diagram

PCI Scope definition
Ref4
Firewall/router rule sets
Includes development/test and production environments 6.4

Non-confidential for external communication with third Optional
party. No internal IP's.
Document describing the PCI scope, network diagram,
1.1 + Scope
components, function, flow, card data storage,
processing, transmission
For each Firewall/router in scope:
Firewall F1 and F2 + Router
Ref5
Includes a list of secure and unsecure services,

protocols and ports together with business justification
for each FW and routers.
Includes a list of restricted connections between
untrusted networks and system components in the
cardholder data environment
Includes a description of inbound and outbound traffic
Includes a rule stating that Internal addresses cannot
pass from the Internet into the DMZ.
Includes a requirement for stateful inspection
Includes segregation of CDE (Ensure that system
components that store cardholder data are on an
internal network zone, segregated from the DMZ)
System Configuration/hardening for For each system components in scope:
all components in scope
Includes a list of services, protocols and daemons
enabled + business justification.
1.1.5
1.2
1.2.1
1.3.4
1.3.6
1.3.7
2.2
System Configuration/hardening for

Documentation
all components in scope
Ref6
Encryption / Transmission
Ref7
Ref8
Patch inventory
IDS/IPS config
Ref9
Includes a list of common security parameter settings

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

Ref
Title
Description
Role and responsibilities for

Description of Groups, Roles and Responsibilities for
network and security management Logical Management of Network Components.
Description of Groups, Roles and Responsibilities for
security management including key management.
PCI DSS Req

1.1.4
Documentation
Firewall/router configuration and
change management process
Formal process for testing and approval of all network

connections and changes to firewall and router
configurations
Includes a statement enforcing review of firewall and
router rule sets at least every six months.
Includes limitation of inbound and outbound traffic to
that which is necessary for the cardholder data
environment
Includes a statement preventing any disclosure of
private IP addresses and routing information to external
parties and exceptions
Includes enabling and activation of audit trails.
Configuration Standards (Windows, System configuration and hardening procedures for
SQL,)
each type of system component in scope.
Protection of Laptop/Desktop in
scope
Includes policy and procedures for changing of Vendor

Default Settings
Includes a statement enforcing one primary function per
system
Includes a statement enforcing that only necessary
services or protocols are enabled. + Justifiation
Includes a list of common security parameter settings
for the system components
Includes a statement enforcing removal of all
unnecessary functionality (for example, scripts, drivers,
features, subsystems, file systems, etc.)
Includes a statement enforcing encryption of nonconsole admin access.
Includes a statement ensuring removal/deactivation of
Telnet and other remote login commands for use
internally
Includes a statement enforcing audit trails activation
Description of technical measures, configuration and
associated processes protecting laptop and desktop.
Such as personal firewall and anti-virus.
1.1
1.1.6
1.2
1.3.8
10.1
2.2
2.1
2.2.1
2.2.2
2.2.3
2.2.4
2.3
2.3
10.1
1.4
Documentation
Data retention and disposal policy
and process
Formal data retention policy identifying what data needs 3.1/3.2.1/3.2.2

to be retained, and where that data resides so it can be /3.2.3
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
Data display protection
Key protection and management
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
Includes business justification for retention of
cardholder data
3.3
Primary Account Number (PAN) Policy and Procedures
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.
Policy and procedures associated to the generation and
protection of keys used for encryption of cardholder
data (PGP, )
Includes the selection process of key custodians
3.5/3.6
3.6.8
Documentation
Tokenization Process
Anti-virus
Security Patch Management
Software Development processes
Description of the processes and mechanisms used to

Optional
generate and protect the token, associated components
and data
Information about anti-virus technology in used and how 5.1
it is updated/managed.
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
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
development/test and production environments
6.4
Includes a statement enforcing separation of duties

between development/test and production
environments
6.4.2
Documentation
Secure coding/Testing
Software Development Secure Coding Guidelines and

Training Policy and Procedures
Includes a statement enforcing training of developers in
secure coding technique
Includes a description of the testing process used to
ensure apps are not vulnerable to coding mistake (SQL
Inj,)
Test procedures
Policy and procedures associated to the test of
Includes a statement preventing usage of Live PAN in
test environment
Includes a statement enforcing removal of Test data and
accounts before production
Change control procedures for
Procedures for the implementation of security patches
implementation of security patches and software modification
and software modifications
Includes statements enforcing:
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
Data control/
Access Control/
6.5-6.5.9
6.5
6.6
6.4.3
6.4.4
6.4.5
6.4.5
Includes a statement enforcing execution of internal and 11.2.3

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

privileged user IDs to least privileges necessary to
perform job responsibilities.
7.1.1
Data control/
Access Control/
Documentation
Proper Authentication & Password

Management
Includes a statement enforcing assignment of privileges

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

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

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

maintenance)
8.5.6
7.1.3
7.1.4
7.2.1
7.2.2
7.2.3
8.2
8.3
8.5
Documentation
Job Classification
Security classification
User access inventory
Physical access protection
Media Distribution, Classification

and destruction
Includes a statement preventing Generic /Share and

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

length of at least seven characters.
Includes a statement enforcing that passwords contain
both numeric and alphabetic characters.
Includes a statement prohibiting submition of a new
password identical to the last four passwords.
Includes a statement enforcing UserId lock out after not
more than six attempts.
Includes a statement enforcing a lockout duration of 30
min minimum or until administrator enables the user ID
Includes a statement requiring user re-authentication
whenever a session has been idle for more than 15
minutes
Lists the Roles, privileges, access requirements, security
responsibilities
Lists the classification levels related to the
confidentiality of the data
Lists who have access to what
Policy and procedures associated to the Protection of
physical areas, Visitor handling, Visitor Checklist
8.5.10
Policy and procedures for Media distribution and

classification
9.7/9.8
8.5.8
8.5.9
8.5.11
8.5.11
8.5.12
8.5.13
8.5.14
7.1, 7.2, 12.4
9.1
9.2/9.3/9.4
9.5/9.6
Documentation
Media Distribution, Classification
and destruction
Monitoring/logging
Detection of WAP
Includes policy and procedures Storage, maintenance

and description of Hardcopy and Electronic Media Policy
and Procedures
Policy and procedures associated to monitoring/logging
Includes a statement enforcing that audit trails are
enablement and activation for system components.
Includes a statement enforcing logging of access to
credit card data
Includes a statement enforcing logging of actions taken
by root administrators
Includes a statement enforcing logging of access to
audit trails
Includes a statement enforcing logging of invalid access
Includes a statement enforcing logging of the
mechanism used to identify and authenticate
Includes a statement enforcing logging of initialization
of audit logs is logged
Includes a statement enforcing creation/deletion of
system components
Lists the type of data to be logged: UserId, type of
event, Date and time,Success or failure,origin of event,
affected data, system component or resource.
Includes a statement enforcin the use of Time
synchronization technology
Describes the measures taken for the protection of audit
trails
Describes the process associated to the review of Logs
(When, How)
Includes a statement enforcing log retention for one
Policy and procedures associated to the detection and
identification of wireless access points on a quarterly
basis
Lists all WAP and their business reasons
9.9/9.10
10.1
10.2.1
10.2.2
10.2.3
10.2.4
10.2.5
10.2.6
10.2.7
10.3
10.4
10.5
10.6/12.2
10.7
11.1
Documentation
ASV Scan process and scan reports Procedures associated to quarterly ASV scans and
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 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
process/configuration
IDS/IPS
Includes a statement enforcing the use IDS at entry
points and other critical points
Lists IDS/IPS and location
File-integrity tools used
Procedures and configuration associated to the FileIntegrity 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
11.2
Risk Assessment Process
Risk assessment process
12.1
Annual Risk Assessment

Daily Operational and security
procedures
Usage Policies and Procedures
Annual risk assessment reports

List of tasks/processes to be performed on a regular
basis
Policy and procedures associated to the use of critical
technology
Includes a statemente requiring explicit approval from
authorized parties to use the technologies.
12.1
12.3
11.3
11.4
11.4
11.5
12.3
12.3.1
Usage Policies and Procedures

Documentation
Security Policy
Includes a statement requiring that all technology use

be authenticated with user ID and password or other
authentication item (for example, token)
Includes a statement requiring a list of all devices and
personnel authorized to use the devices.
Includes a statement requiring labeling of devices with
information that can be correlated to owner, contact
information and purpose.
Includes a statement requiring acceptable uses for the
technology.
Includes a statement requiring acceptable network
locations for the technology.
Includes a statement requiring a list of companyapproved products.
Lists company approved products
Includes a statement requiring automatic disconnect of
sessions for remote-access technologies after a specific
period of inactivity
Includes a statement requiring activation of remoteaccess technologies used by vendors and business
partners only when needed by vendors and business
partners, with immediate deactivation after use.
12.3.2
Includes a statement prohibiting 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
Security policy for employee and contractors

Describes Information Security responsibilities for
Employees and Contractors
Lists formal assignment of information security to a
Chief Security Officer or other security-knowledgeable
member of management.
12.1
12.4
12.3.3
12.3.4
12.3.5
12.3.6
12.3.7
12.3.8
12.3.9
12.5
Security Policy
Documentation
Includes assignment of responsibility for creating and
12.5.1
distributing security policies and procedures
Includes assignment of responsibility for monitoring and 12.5.2
analyzing security alerts and distributing information to
appropriate information security and business unit
management personnel is formally assigned.
Security Awareness program
HR Screening process
Service Provider management
policies and procedures
Includes assignment of responsibility for creating and

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

policies and procedures
Documentation
Incident response Plan
Written agreement that includes an acknowledgement

that the service providers are responsible for the
security of cardholder data the service providers
possess.
List of service providers
Incident response plan
Includes:
12.8.2
12.8.1
12.9
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
available on a 24/7 basis to respond to alerts.
Includes annual testing
Includes appropriate training to staff with security
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.3
12.9.2
12.9.4
12.9.1
Documentation
Version
Owner
Location
Published/DRAFT
Documentation
Version
Owner
Location
Published/DRAFT
Documentation
Documentation
Documentation
Documentation
Documentation
Documentation
Documentation
Documentation
Documentation
Documentation
Documentation
Compliance % per requirement
0%
1
10
ent
10
11
12
PCI Severity per requirements
300
200
100
0
24
67
135
129
14
14
36
111
111
132
64
216
132
64

Name
Email
Name 1
Name 2
Name 3
Name 4
Tel
Function
Areas of expertize
Types
A
B
C-VT
C
D
urn to Table of content
Merchant types
Description
Card-not-present (e-commerce or mail/telephone-order) merchants, all cardholder data functions outsourced. This would
never apply to face-to-face merchants.
Imprint-only merchants with no electronic cardholder data storage, or standalone, dial- out terminal merchants with no
electronic cardholder data storage
Merchants using only web-based virtual terminals, no electronic cardholder data storage
Merchants with payment application systems connected to the Internet, no electronic cardholder data storage
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.

Compensating Constraints
Control Id
#
List constraints precluding
compliance with the original
requirement.
1
2
3
4
5
6
7
8
9
10
11
Objective
Identified Risk
Define the objective of the

original control; identify the
objective met by the
compensating control.
Identify any additional risk

posed by the lack of the original
control.
Definition of Compensation Control
Validation of Compensating Control
Define the compensating controls and

Define how the compensating controls
explain how they address the objectives of were validated and tested.
the original control and the increased risk, if
any.
Maintenance
Define process and controls
in place to maintain
compensating controls
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)
C1
Critical Control 1: Inventory of Authorized and

Unauthorized Devices
C1.1
An accurate and up-to-date inventory, controlled by active

monitoring and configuration management, can reduce the chance
of attackers finding unauthorized and unprotected systems to
exploit.
C1.2
Deploy an automated asset inventory discovery tool and use it to

build a preliminary asset inventory of systems connected to the
enterprise network. Both active tools that scan through network
address ranges and passive tools that identify hosts based on
analyzing their traffic should be employed.
C1.3
C1.4
Matching
PCI Reqs
If Any
16.67%
Matching Score
level
1.5
Scoping
0.5
11.1
11.2
0.5
Maintain an asset inventory of all systems connected to the network

and the network devices themselves, recording at least the network
addresses, machine name(s), purpose of each system, an asset
owner responsible for each device, and the department 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,
Scoping
0.5
The asset inventory created must also include data on whether the
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

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

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

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

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

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

Unauthorized Software
C2.1
Devise a list of authorized software that is required in the enterprise

for each type of system, including servers, workstations, and laptops
of various kinds and uses.
0.00%
-
0
N
C2.2
Deploy software inventory tools throughout the organization

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

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

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

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

Hardware and Software on Laptops, Workstations,
45.45%
C3.1
Strict configuration management should be followed, building a

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.
2.2
C3.2
System images must have documented security settings that are

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.
2.2
C3.3
Standardized images should represent hardened versions of the

underlying operating system and the applications installed on the
system, such as those released by the NIST, NSA, Defense
Information Systems Agency (DISA), Center for Internet Security
(CIS), and others. This hardening would typically include removal of
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
C3.5
C3.6
2.1
2.2
2.2.2
2.2.3
2.2.4
Any deviations from the standard build or updates to the standard

build should be documented and approved in a change management
system.
Organizations should negotiate contracts to buy systems configured
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.
The master images themselves must be stored on securely

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.
6.1
-
F
N
1
0
C3.7 Run the last version of software and make sure it is fully patched.
C3.7.1 Remove outdated or older software from the system.
C3.8
At least once a month, run assessment programs on a varying

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

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

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
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

Assessment and Remediation
C4.1
Organizations should run automated vulnerability scanning tools

against all systems on their networks on a weekly or more frequent
basis. Where feasible, vulnerability scanning should occur on a daily
basis using an up-to-date vulnerability scanning tool.
C4.1.1 Any vulnerability identified should be remediated in a timely

manner, with critical vulnerabilities fixed within 48 hours.
C4.2
Event logs should be correlated with information from vulnerability

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 knownvulnerable target
11.5
20.00%
11.2
11.2.1
11.2.2
11.2.3
0.5
6.1
0.5
C4.3
C4.4
C4.5
C4.6
C4.7
C4.8
C4.9
Organizations should deploy automated patch management tools

and software update tools for all systems for which such tools are
available and safe.
In order to overcome limitations of unauthenticated vulnerability
scanning, organizations should ensure that all vulnerability scanning
is performed in authenticated mode either with agents running
locally on each end system to analyze the security configuration or
with remote scanners that are given administrative rights on the
system
being tested.
Organizations
should compare the results from back-to-back
vulnerability scans to verify that vulnerabilities were addressed
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.
Vulnerability scanning tools should be tuned to compare services
that are listening on each machine against a list of authorized
services. The tools should be further tuned to identify changes over
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.
Security personnel should chart the numbers of unmitigated, critical
vulnerabilities for each department/division.
Security personnel should share vulnerability reports indicating
critical issues with senior management to provide effective
incentives for mitigation.
Organizations should measure the delay in patching new
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.
6.2
C4.10 Critical patches must be evaluated in a test environment before

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
C5.1
Organizations should monitor workstations, servers, and mobile

devices for active, up-to-date anti-malware protection with antivirus, anti-spyware,
C5.1.1 personal firewalls
C5.1.2 and host-based IPS functionality.
C5.1.3 All malware detection events should be sent to enterprise antimalware administration tools and event log servers.
C5.2
Organizations should employ anti-malware software and signature

auto update features or have administrators manually push updates
to all machines on a daily basis.
C5.2.1 After applying an update, automated systems should verify that
each system has received its signature update.
C5.3 Organizations should configure laptops, workstations, and servers 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

automated anti-malware scan of removable media when it is
inserted.
3
0.5
11.4
F
P
1
0.5
5.2
37.50%
5.1
1.4
C5.5
C5.6
C5.7
C5.8
All attachments entering the organizations e-mail gateway should

be scanned and blocked if they contain malicious code. This
scanning should be done before the e-mail is placed in the users
inbox.
Behavioral-based anomaly detection should be used to complement
and enhance traditional signature-based detection.
Organizations should deploy network access control tools to verify
security configuration and patch-level compliance before granting
access to a network.
Continuous monitoring should be performed on outbound traffic. 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
C6.1
Organizations should protect web applications by deploying web

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.
At a minimum, explicit error checking should be done for all input.
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.2
50.00%
6.6
4.5
0.5
C6.3
Organizations should test in-house-developed and third-partyprocured web and other application software for coding errors and
malware insertion, including backdoors prior to deployment using
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.
Organizations should test in-house-developed and third-partyprocured web applications for common security weaknesses using
automated remote web application scanners prior to deployment,
whenever updates are made to the application
and on a regular recurring basis.
6.3.2
6.4.5.3
6.6
11.2
11.2.3
11.3.2
C6.5
For applications that rely on a database, organizations should

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

into account throughout the requirements, design, implementation,
testing, and other phases of the software development life cycle of
all applications.
6.3
C6.7
Organizations should ensure that all software development

personnel receive training in writing secure code for their specific
development environment.
Require that all in-house-developed software include white-list
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.
6.5
Sample scripts, libraries, components, compilers, or any other

unnecessary code that is not being used by an application should be
uninstalled or removed from the system.
C6.4
C6.8
C6.9
C7
Critical Control 7: Wireless Device Control
C7.1
Organizations should ensure that each wireless device connected to

the network matches an authorized configuration and security
profile, with a documented owner of the connection and a defined
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

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
C7.4
Network vulnerability scanning tools should be configured to detect

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.
Organizations should use wireless intrusion detection systems
C7.5
(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.
802.1x should be used to control which devices are allowed to
C7.6
C7.7
C7.8
connect to the wireless network.

A site survey should be performed to determine what areas within
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.
Where a specific business need for wireless access has been
identified, organizations should configure wireless access on client
machines to allow access only to authorized wireless networks.
For devices that do not have an essential wireless business 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.
28.13%
2.1.1
4.1.1
11.1
4.5
0.5
11.1
C7.9
Organizations should regularly scan for unauthorized or

misconfigured wireless infrastructure devices, using techniques such
as war driving to identify access points and clients accepting peerto-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
least Advanced Encryption Standard (AES) encryption used with at
least WiFi Protected Access 2 protection.
C7.11 Organizations should ensure that wireless networks use
authentication protocols such as Extensible Authentication ProtocolTransport Layer Security (EAP/TLS) or Protected Extensible
Authentication Protocol (PEAP), which provide credential protection
mutual authentication.
C7.12 and
Organizations
should ensure that wireless clients use strong, multifactor authentication credentials to mitigate the risk of unauthorized
access from compromised credentials.
C7.13 Organizations should disable peer-to-peer wireless network
capabilities on wireless clients, unless such functionality meets a
documented business need.
C7.14 Organizations should disable wireless peripheral access of devices
(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
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
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
11.1
4.1.1.
1.2.3
40.00%
C8.1
C8.2
C8.3
C8.4
C8.5
C9
C9.1
C9.2
Organizations should ensure that each system is automatically

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.
Data on backup media should be tested on a regular basis by
performing a data restoration process to ensure that the backup is
properly working.
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.
Organizations should ensure that backups are properly protected via
physical security or encryption when they are stored locally, as well
as when they are moved across the network.
Backup media, such as hard drives and tapes, should be stored in
physically secure, locked facilities.
3.4
9.5
9.5
33.33%
Critical Control 9: Security Skills Assessment and
Appropriate
Training
tosecurity
Fill Gaps
Organizations should
develop
awareness training for 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.
12.6
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.
12.6
C9.3
Metrics should be created for all policies and measured on a regular

basis. Awareness should focus on the areas that are receiving the
lowest compliance score.
C9.4
Organizations should devise periodic security awareness 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.
Organizations
should conduct periodic exercises to verify that
C9.5
C9.6
C10
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.
Provide awareness sessions for users who are not following policies
after they have received appropriate training.
Critical Control 10: Secure Configurations for

Network Devices such as Firewalls, Routers, and
50.00%
C10.1 Compare firewall, router, and switch configuration against standard

secure configurations defined for each type of network device in use
in the organization. The security configuration of such devices
should be documented, reviewed, and approved by an organization
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.
1.2.2
1.1.5
1.1.6
2.2
C10.2 At network interconnection pointssuch as Internet gateways, interorganization connections, and internal network segments with
different security controlsimplement ingress and egress 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.
1.2
1.2.1
1.1.5
C10.3 Network devices that filter unneeded services or block attacks

(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

configuration that allow traffic to flow through network security
devices, such as firewalls and network-based IPS, should be
documented and recorded in a configuration management system,
with a specific business reason for each change, a specific
individuals name responsible for that business need, and an
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
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.
1.1
1.1.1
1.1.2
1.1.4
1.1.5
1.1.6
C10.6 Network devices should be managed using two-factor authentication

and encrypted sessions. Only true two-factor 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.
2.3
8.3
C10.7 The latest stable version of a network devices inter-network

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

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

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

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
against all key servers and compared to a known effective baseline.
If a new port is found open, an alert should be generated and
reviewed.
C11.3 Any server that is visible from the Internet or an untrusted network
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 should
be reviewed quarterly via a change control group, and business units
should re- justify the business use. Sometimes 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
as DNS, file, mail, web, and database servers.
C11.6 Application firewalls should be placed in front of any critical servers
to verify and validate the traffic going to the server. Any
unauthorized services or traffic should be blocked and an alert
generated.
C12
Critical Control 12: Controlled Use of

Administrative Privileges
C12.1 Organizations should inventory all administrative passwords
41.67%
2.5
11.2.1
11.2.2
11.2.3
0.5
1.1.5
0.5
2.2.1
6.6
0.5
53.57%
-
7.5
N
C12.1.1and validate that each person with administrative privileges on

desktops, laptops, and servers is authorized by a senior executive
C12.1.2and that his/her administrative password has at least 12 semirandom characters, consistent with the FDCC standard.
7.1
0.5
8.5.10
0.5
2.1
C12.3 Organizations should configure all administrative-level accounts to

require regular password changes on a frequent interval of no longer
than 60 days.
C12.4 Organizations should ensure all service accounts have long and
difficult-to- guess passwords that are changed on a periodic basis, as
is done for traditional user and administrator passwords, at a
frequent interval of no longer than 90 days.
8.5.9
C12.5 Passwords for all systems should be stored in a well-hashed or

encrypted format.
C12.5.1Furthermore, files containing these encrypted or hashed passwords
required for systems to authenticate users should be readable only
with superuser privileges.
C12.6 Organizations should ensure that administrator accounts are used
only for system administration activities, and not for reading e-mail,
composing documents, or surfing the Internet.
C12.6.1Web browsers and e-mail clients especially must be configured to
never run as administrator.
C12.7 Through policy and user awareness, organizations should require
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.
8.4
C12.2 Before deploying any new devices in a networked environment,

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.8 Organizations should configure operating systems so that passwords

cannot be re-used within a certain timeframe, such as six months.
C12.9 Organizations should implement focused auditing on the use of
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
alert when an account is added to or removed from a domain
administrators group.
C12.11 All administrative access, including domain administrative access,
should use two-factor authentication.
C12.12 Access to a machine (either remotely or locally) should be blocked
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
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
defined roles within the organization. For example, Workstation
admin accounts should only be allowed administrative access of
workstations, laptops, etc.
C13
Critical Control 13: Boundary Defense
8.5.12
0.5
10.2.2
10.2.2
0.5
12.8.2
7.2
7.2.2
0.5
50.00%
6.5
C13.1 Organizations should deny communications with (or limit data flow
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.1Tests can be periodically carried out by sending packets from bogon

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
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.
1.1.1
0.5
11.4
C13.3 Network-based IPS devices should be deployed to compliment IDS

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
network-based
IPS can
provide
automation
block
bad
C13.4 configured
On DMZ networks,
monitoring
systems
(which
may be to
built
in to
the
11.4
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

systems from DMZ and extranet systems. DMZ systems are
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.
1.1.3
1.3.7
C13.6 Design and implement network perimeters so that all outgoing 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
forms of access that allow login to internal systems) to use twofactor authentication.
C13.8 All devices remotely logging into the internal network should be
managed by the enterprise, with remote control of their
configuration, installed software,
and patch levels.
8.3
C13.9 Organizations should periodically scan for back-channel

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

network, organizations should devise internal network segmentation
schemes to limit traffic to only those services needed for business
use across the internal network.
1.3.7
0.5
C13.11 Organizations should develop plans to rapidly deploy filters on

internal networks to help stop the spread of malware or an intruder.
C13.12 To minimize the impact of an attacker pivoting between
compromised systems, only allow DMZ systems to communicate
with private network systems via application proxies or applicationaware firewalls over approved channels
C13.13 To help identify covert channels exfiltrating data through a firewall,
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

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

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
for the logs generated on a regular basis, so that log files will not fill
up between log rotation intervals.
C14.2.1The logs must be archived and digitally signed on a periodic basis.
10.5
10.5.3
-
0.5
C14.2 All remote access to a network, whether to the DMZ or the internal
network (i.e., VPN, dial-up, or other mechanism), should be logged
verbosely.
C.14.3 Operating systems should be configured to log access control events

associated with a user attempting to access a resource (e.g., a file or
directory) without the appropriate permissions. Failed logon
attempts must also be logged.
10.2.1 10.2.7
10.3.4
C14.4 Security personnel and/or system administrators should run

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
sources (i.e., Network Time Protocol NTP) from which all servers
and network equipment retrieve time information on a regular basis
so that timestamps in logs are consistent.
10.6
10.4
(10.4.3)
0.5
10.2
10.6
0.5
10.5.4
C14.6 Network boundary devices, including firewalls, network-based IPS,

and inbound and outbound proxies, should be configured to
verbosely log all traffic (both allowed and blocked) arriving at the
C14.7 device.
For all servers, organizations should ensure that logs are written to
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
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

Need to Know
28.57%
C15.1 Organizations should establish a multi-level data

identification/classification scheme (e.g., a three- or four-tiered
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
(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
nonpublic data and special authentication for sensitive data.
C15.4 The network should be segmented based on the trust levels of the
information stored on the servers.
C15.4.1Whenever information flows over a network of lower trust level, the
information should be encrypted.
C15.5 The use of portable USB drives should either be limited or data
should automatically be encrypted before it is written to a portable
C15.6 drive.
Host-based data loss prevention (DLP) should be used to enforce
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
trying to access information that they should not access.
7.2
0.5
1.2
1.3
4.1
0.5
68.18%
-
7.5
0
C16
Critical Control 16: Account Monitoring and Control
C16.1 Review all system accounts and disable any account that cannot be
associated with a business process and owner.
C16.2 Systems should automatically create a report on a daily basis that
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

system access by disabling accounts immediately upon termination
of an employee or contractor.
C16.4 Organizations should regularly monitor the use of all accounts,
automatically
logging off users after a standard period of inactivity.
C16.5 Organizations should monitor account usage to determine dormant
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
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
minimum length of 12 characters,
C16.7.1 contain letters, numbers, and special characters
C16.7.2be changed at least every 90 days, have a minimal age of one day,
C1.7.3 and not be allowed to use the previous 15 passwords as a new
password.
C16.8 After eight failed logon attempts within a 45-minute period, the
account should be locked
C16.8.1for 120 minutes.
C16.9 On a periodic basis, such as quarterly or at least annually,
organizations should require that managers match active employees
and contractors with each account belonging to their 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
accounts through audit logging.
8.5.4
8.5.6
8.5.15
8.5.5
8.5.10
0.5
8.5.11
0.5
8.5.9
8.5.12
F
P
1
0.5
8.5.13
8.5.14
0.5
12.2
0.5
C16.11 Organizations should profile each users typical account usage by

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
C17.1 Organizations should deploy approved hard drive encryption

software to mobile machines that hold sensitive data.
C17.2 Network monitoring tools should analyze outbound traffic looking 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
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
C17.4 security
Conduct personnel.
periodic scans of server machines using automated tools to
30.00%
-
3
0
10.0
4.00
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
information leaving an organization.
C17.6 Data should be moved between networks using secure,
authenticated, and encrypted mechanisms.
C17.7 Data stored on removable and easily transported storage media

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.
3.4
C17.8 If there is no business need for supporting such devices,

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 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
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.
100.00%
12.5.3
12.9
6
1
12.9.1
12.9.1
C18
Critical Control 18: Incident Response Capability
C18.1 Organizations should ensure that they have written incident

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
computer
and should
network
incidents
to specificpersonnel
individuals.
Organizations
define
management
who will
C18.3 support the incident handling process by acting in key decisionmaking roles.
C18.4 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.
12.9.1
C18.5 Organizations should publish information for all personnel, 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.
12.9.4
C18.6 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.
12.9.4
2.5
1
C19
Critical Control 19: Secure Network Engineering
C19.1 The network should be designed using a minimum of a three-tier

architecture (DMZ, middleware, and private network). Any system
accessible from the Internet should be on the DMZ, but DMZ
systems never contain sensitive data. Any system with sensitive
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
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.
50.00%
1.3
1.3.1
1.3.2
1.3.3
C19.3 DNS should be deployed in a hierarchical, structured fashion, with 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 development
lifecycle, ensuring that any security issues are addressed as early as
possible.
C19.5 Organizations should segment the enterprise network into multiple,
separate trust zones to provide more granular control of system
access and additional intranet boundary defenses.
6.3
1.3
0.5
C20
Critical Control 20: Penetration Tests and Red Team

Exercises
35.71%
2.5
C20.1 Organizations should conduct regular external and internal

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.
11.3
C20.2 Organizations should perform periodic red team exercises to test 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
penetration tests and red team exercises are fully mitigated.
11.3b
C20.4
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 Social engineering should be included within a penetration test.

Supplement
The human element is often the weakest link in an organization and
one that attackers
often target.
C20.6 Organizations should devise a scoring method for determining the
results of
red team exercises so that results can be compared over time.
C20.7 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.
0.5
Notes
While there is no specific inventory

requirement, the inventory process
is actually part of a scoping
exercice.
No specific inventory requirements
but target discovery is the first part
of the external scanning process.
While there is no specific inventory

requirement, the inventory process
is actually part of a scoping
exercice.
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
PCI requirements less restrictive

(once a quarter or after major
changes
PCI less restrictive in terms of
critical vulnerabilities fixing period
(One month)
11.2 requires ASV to run

unauthenticated scans with the
known limitations. PCI rules should
align on Top 20.
For the risk approach. Nothing about
validation /control process
Checking services and configuration

as part of a scan isn't explicitely
required by PCI.
PCI doesn't mention ati-malware

protection.
11.4 requires the use of network

based IPS/IDS. PCI doesn't require
host based IPS
PCI doesn't address the
centralization of malware event
management. The closest
requirement is 5.2 requiring
generation
of audit
logs
5.2 is the closest
requirement:
(Antivirus must be current)
Should be part of 5.2 but email

servers could not be within the
scope.
Code review OR WAF
No mention of automated static

code analysis software
Testing procedure 6.5.a require to

verify training requirement t
6.3.1 talks about account removal

6.4.4 talks about test data removal
but no mention of scripts,
librairies,...
No mention of documented
configuration
PCI DSS doesn't specify an

encryption algorithm.
10.5.3 requires backup of audit trail

files
could be included in 12.6

(awareness program).
No determination/validation of level
of understanding
Part of the discovery phasis of a

newtork scan. Although, specific
reports should be built to list these
discrepencies.
1.1.5 is the closest requirement

related to busines justification. No
mention of regular review.
PCI leaves the choice between a

WAF or code-review.
General statement. Not talk

specifically of Admin privileges.
General requirement of at least 7
characters. No specific req for
admin
General requirement: 90 days. No

specific requirement for admin
accounts.
Service account passwords aren't
addressed.
10.2.2 is the closest requirement
8.3 Two-factor only required for

remote access.
Discovery
No requirement for digital signature

Not specific requirement for remote
access
Resource = CC data
Don't mention about # of time

synchronization sources
No specific mention of such devices
No mention of SEIM
Could be part of a risk assessment

methodology.
7.2 is the closest requiremement
PCI less restrictive (90 days)
PCI les restrictive (7 characters)

PCI less restrictive (No special
characters)
PCI is also 90 days
PCI less restrictive (the last 4)
PCI more restrictive (6 attempts)
PCI less restrictive (30 minutes or
unlocked by administrator)
Partially covered through the
requirement for a User account
maintenance procedure.
PCI requires encryption only through

public network
Network segmentation is addressed

as a way to reduce the scope of the
assessment.
Noted exploitable vulnerabilities

must be corrected
Social engineering is mentionned

within the Supplemental document
about pen test
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
vulnerabilities
Report location
Firewalls are devices that control computer traffic allowed between an entitys networks (internal) and untrusted
A firewall examines all network traffic and blocks those transmissions that do not meet the specified security cri
All systems must be
from unauthorized
from untrusted
networks,to
whether
entering
the systemd
Requirement
1:protected
Install and
maintain aaccess
firewall
configuration
protect
cardholder
Other system components may provide firewall functionality, provided they meet the minimum requirements fo
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
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 pe
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 comple
PCI DSS Requirement
1.1 Establish firewall and router configuration

standards that include the following:
1.1.1 A formal process for approving and testing all

network connections and changes to the firewall
and router configurations
1.1.2 Current network diagram with all connections

to cardholder data, including any wireless networks
1.1.3 Requirements for a firewall at each Internet

connection and between any demilitarized zone
(DMZ) and the internal network zone
1.1.4 Description of groups, roles, and

responsibilities for logical management of network
components
1.1.5 Documentation and business justification for

use of all services, protocols, and ports allowed,
including documentation of security features
implemented for those protocols considered to be
insecure. Examples of insecure services, protocols,
or ports include but are not limited to FTP, Telnet,
POP3, IMAP, and SNMP.
1.1.6 Requirement to review firewall and router

rule sets at least every six months
1.2 Build firewall and router configurations that

restrict connections between untrusted networks and
any system components in the cardholder data
environment.
Note: An untrusted network is any network that is
external to the networks belonging to the entity
under review, and/or which is out of the entity's
ability to control or manage.
1.2.1 Restrict inbound and outbound traffic to that

which is necessary for the cardholder data
environment.
1.2.2 Secure and synchronize router configuration

files.
1.2.3 Install perimeter firewalls between any

wireless networks and the cardholder data
environment, and configure these firewalls to deny
or control (if such traffic is necessary for business
purposes) any traffic from the wireless environment
into the cardholder data environment.
1.3 Prohibit direct public access between the Internet

and any system component in the cardholder data
environment.
1.3.1 Implement a DMZ to limit inbound traffic to

only system components that provide authorized
publicly accessible services, protocols, and ports.
1.3.2 Limit inbound Internet traffic to IP addresses

within the DMZ.
1.3.3 Do not allow any direct connections inbound

or outbound for traffic between the Internet and the
cardholder data environment.
1.3.4 Do not allow internal addresses to pass from

the Internet into the DMZ.
1.3.5 Do not allow unauthorized outbound traffic

from the cardholder data environment to the
Internet.
1.3.6 Implement stateful inspection, also known as

dynamic packet filtering. (That is, only
established connections are allowed into the
network.)
1.3.7 Place system components that store

cardholder data (such as a database) in an internal
network zone, segregated from the DMZ and other
untrusted networks.
1.3.8 Do not disclose private IP addresses and

routing information to unauthorized parties.
Note: Methods to obscure IP addressing may
include, but are not limited to:
- Network Address Translation (NAT)
- Placing servers containing cardholder data behind
proxy servers/firewalls or content caches,
- Removal or filtering of route advertisements for
private networks that employ registered
addressing,
- Internal use of RFC1918 address space instead of
registered addresses.
1.4 Install personal firewall software on any mobile

and/or employee-owned computers with direct
connectivity to the Internet (for example, laptops
used by employees), which are used to access the
organizations network.
raffic allowed between an entitys networks (internal) and untrusted networks (external), as well as traffic into and out of m
ocks those transmissions that do not meet the specified security criteria.
orized
from untrusted
networks,to
whether
entering
the systemdata
via the Internet as e-commerce, employee Internet ac
ain aaccess
firewall
configuration
protect
cardholder
wall functionality, provided they meet the minimum requirements for firewalls as provided in Requirement 1. Where other s
CI Compliance Report:
percent who were found compliant in previous report
ement is the documentation of network device configurations, with only 63 percent of companies meeting Requirement 1.1
utdated.
t 1.2.1) continues to be an issue for many being audited, with 23 percent of businesses found to be non-compliant at the ti
ill flowing through many networks.
time to dig into every rule in the firewalls to understand the complete rule sets.
Guidance
Firewalls and routers are key components of the

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.
A policy and process for approving and testing all connections
and changes to the firewalls and 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
SANS
Top 20 Critical
Security
Controls
C10.4
C10.4
C13.1.1
Network diagrams enable the organization to identify

the location of all its network devices. 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.
C10.4
Using a firewall on every connection coming into (and out

of) the network allows the organization to monitor and
control access in and out, and to minimize the chances of
a malicious individuals obtaining access to the internal
network.
C13.5
This description of roles and assignment of responsibility

ensures that someone is clearly responsible for the
security of all components and is aware of their
responsibility, and that no devices are left unmanaged.
C10.4
Compromises often happen due to unused or insecure

service and ports, since these often have known
vulnerabilitiesand many organizations are vulnerable to
these types of compromises because they do not patch
security vulnerabilities for services, protocols, and ports
they don't use (even though the vulnerabilities are 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.
C10.1
C10.2
C10.4
C11.4
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.
This review gives the organization an opportunity 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.
C10.1
C10.4
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.
It is essential to install network protection, namely a

system component with (at a minimum) stateful
inspection firewall capability, between the internal, trusted
network and any other untrusted network that is external
and/or out of the entitys ability to control or manage.
Failure to implement this measure correctly means that
the entity will be vulnerable to unauthorized access by
malicious individuals or software.
C10.2
C15.4
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.
This requirement 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 (for
example, to send data they've obtained from within your
network out to an untrusted server.
C10.2
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.
While running configuration files are usually 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.
C10.1
The known (or unknown) implementation and exploitation

of wireless technology within a network is a common path
for malicious individuals to gain access to the network and
cardholder data. If a wireless device or network is installed
without a companys knowledge, a malicious individual
could easily and invisibly enter the 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.
C15.4
C7.15
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.
A firewall's intent is to manage and control all connections

between public systems and internal 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.
C19.1
C19.5
The DMZ is that part of the network that manages

connections between the Internet (or other untrusted
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.
C19.1
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.
Termination of IP connections at the DMZ provides

opportunity for inspection and restriction of
source/destination, and/or inspection / blocking of content,
thus preventing unfiltered access between untrusted and
trusted environments.
C19.1
Termination of IP connections both inbound and outbound

provides opportunity for inspection and 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.
C19.1
Normally a packet contains the IP address of the

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.
C13.5
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.
All traffic outbound from inside the cardholder data

environment should be evaluated to ensure that
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).
C10.2
Where environments have no inbound connectivity

allowed, outbound connections may be achieved via
architectures or system components that interrupt and
inspect the IP connectivity.
A firewall that performs stateful packet inspection keeps

"state" (or the status) for each connection to the
firewall. By keeping "state," the firewall knows 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.
NC
Cardholder data requires the highest level of information

protection. If cardholder data is located within the DMZ,
access to this information is easier for an external
attacker, since there are fewer layers to penetrate.
Note: the intent of this requirement does not include
storage in volatile memory.
Restricting the broadcast of IP addresses is essential to

prevent a hacker learning the IP addresses of the
internal network, and using that information to access the
network.
C13.5
C13.10
NC
Effective means to meet the intent of this requirement

may vary depending on the specific networking
technology being used in your environment. For example,
the controls used to meet this requirement may be
different for IPv4 networks than for IPv6 networks.
One technique to prevent IP address information from
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.
If a computer does not have a firewall or anti-virus

program installed, spyware, Trojans, viruses, worms and
rootkits (malware) may be downloaded and/or installed
unknowingly. The computer is even more vulnerable 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
C5.1.1
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.
external), as well as traffic into and out of more sensitive areas within an entitys internal trusted networks. The cardholder
rnet as e-commerce, employee Internet access through desktop browsers, employee e-mail access, dedicated connections
provided in Requirement 1. Where other system components are used within the cardholder data environment to provide fi
ent of companies meeting Requirement 1.1.5 regularly.
nesses found to be non-compliant at the time of the assessment.
Testing Procedure
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:
1.1.1 Verify that there is a formal process for testing and approval of all network
connections and changes to firewall and router configurations.
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.
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.
1.1.4 Verify that firewall and router configuration standards include a description of
groups, roles, and responsibilities for logical management of network components.
1.1.5.a Verify that firewall and router configuration standards include a documented
list of services, protocols and ports necessary for businessfor example, hypertext
transfer protocol (HTTP) and Secure Sockets Layer (SSL), Secure Shell (SSH), and
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.
1.1.6.a Verify that firewall and router configuration standards require review of
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.
1.2 Examine firewall and router configurations to verify that connections are restricted
between untrusted networks and system components in the cardholder data
environment, as follows:
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.
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.
1.2.3 Verify that there are perimeter firewalls installed between any wireless 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.
1.3 Examine firewall and router configurationsincluding but not limited to the choke
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.
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.
1.3.2 Verify that inbound Internet traffic is limited to IP addresses within the DMZ.
1.3.3 Verify direct connections inbound or outbound are not allowed for traffic
between the Internet and the cardholder data environment.
1.3.4 Verify that internal addresses cannot pass from the Internet into the DMZ.
1.3.5 Verify that outbound traffic from the cardholder data environment to the
Internet is explicitly authorized
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.)
1.3.7 Verify that system components that store cardholder data are on an internal
network zone, segregated from the DMZ and other untrusted networks.
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.
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.
rusted networks. The cardholder data environment is an example of a more sensitive area within an entitys trusted netwo
ail access, dedicated connections such as business-to-business connections, via wireless networks, or via other sources. Oft
der data environment to provide firewall functionality, these devices must be included within the scope and assessment of
Validation instruction for QSA/ISA

(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
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
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
.Identify the current network diagrams and firewall configuration standards reviewed.
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
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
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
Identify the router configuration standards that require a review of router rule sets
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
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 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.
Describe how the router configuration files were observed to be secured
Describe how the router configuration files were observed to be synchronized.
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.
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
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).
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.
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.
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 employeeowned 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
within an entitys trusted network.
etworks, or via other sources. Often, seemingly insignificant paths to and from untrusted networks can provide unprotected
in the scope and assessment of Requirement 1.
Merchant TYPES
Priority
C-VT
In Place ?
Severity in case of
non compliance
28
Y
N
C
24
74
10
ks can provide unprotected pathways into key systems. Firewalls are a key protection mechanism for any computer networ
Proofs /
Stage of implementation
Documentation links
Remediation plan
echanism for any computer network.
Estimated date for completion
Comments
Owner
Name
Requirement 2: Do not use vendor-supplied defaults for system passwords and oth
Malicious individuals (external and internal to an entity) often use vendor default passwords and other vendor d
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 t
Requirements 2.2.3b (secure system configuration) and 2.2.4 (remove unnecessary services) both remain low, a
Almost all systems administrators profess to know how to configure a system to be secure (Requirement 2.2.3a)
PCI DSS Requirement
2.1 Always change vendor-supplied defaults before

installing a system on the network, including but not
limited to passwords, simple network management
protocol (SNMP) community strings, and elimination
of unnecessary accounts.
2.1.1 For wireless environments connected to the
cardholder data environment or transmitting
cardholder data, change wireless vendor defaults,
including but not limited to default wireless
encryption keys, passwords, and SNMP community
strings.
2.2 Develop configuration standards for all system

components. Assure that these standards address all
known security vulnerabilities and are consistent with
industry-accepted system hardening standards.
Sources of industry-accepted system hardening
standards may include, but are not limited to:
-
Center for Internet Security (CIS)

International Organization for Standardization (ISO)
SysAdmin Audit Network Security (SANS) Institute
National Institute of Standards Technology (NIST)
2.2.1 Implement only one primary function per

server to prevent functions that require different
security levels from co-existing on the same server.
(For example, web servers, database servers, and
DNS should be implemented on separate servers.)
Note: Where virtualization technologies are in use,
implement only one primary function per virtual
system component.
server to prevent functions that require different

security levels from co-existing on the same server.
(For example, web servers, database servers, and
DNS should be implemented on separate servers.)
Note: Where virtualization technologies are in use,
implement only one primary function per virtual
system component.
2.2.2 Enable only necessary and secure services,

protocols, daemons, etc., as required for the
function of the system. Implement security
features for any required services, protocols or
daemons that are considered to be insecurefor
example, use secured technologies such as SSH, SFTP, SSL, or IPSec VPN to protect insecure services
such as NetBIOS, file-sharing, Telnet, FTP, etc.
2.2.3 Configure system security parameters to

prevent misuse.
2.2.4 Remove all unnecessary functionality, such

as scripts, drivers, features, subsystems, file
systems, and unnecessary web servers.
2.3 Encrypt all non-console administrative access

using strong cryptography. Use technologies such as
SSH, VPN, or SSL/TLS for webbased management and
other nonconsole administrative access.
2.4 Shared hosting providers must protect each

entitys hosted environment and cardholder data.
These providers must meet specific requirements as
detailed in Appendix A: Additional PCI DSS
Requirements for Shared Hosting Providers.
or-supplied defaults for system passwords and other security parameters
o an entity) often use vendor default passwords and other vendor default settings to compromise systems. These passwor
CI Compliance Report
cent the year before.
ement to change vendor-supplied default passwords, which was up to 82 percent from 48 percent.
uration) and 2.2.4 (remove unnecessary services) both remain low, at 74 percent and 67 percent respectively.
know how to configure a system to be secure (Requirement 2.2.3a), but when it comes down to building and maintaining
Guidance
SANS
Top 20 Critical
Security Controls
Malicious individuals (external and internal to a

company) often use vendor default settings, account
names, and passwords to compromise systems.
These settings are well known in hacker communities
and leave your system highly vulnerable to attack.
C3.3
C12.2
Many users install these devices without

management approval and do not change default
settings or configure security settings. If wireless
networks are not implemented with sufficient security
configurations (including changing default 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).
C11.5
C7.1
There are known weaknesses with many operating

systems, databases, and enterprise applications, and
there are also known ways to configure these
systems to fix security vulnerabilities. To help those
that are not security experts, security organizations
have established system-hardening
recommendations, which advise how to correct these
weaknesses. If systems are left with these
weaknessesfor example, weak file settings or
default services and protocols (for services or
protocols that are often not needed)an attacker 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.
C3.1
C3.2
C3.3
C10.1
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.
This is intended to ensure your organization's system

configuration standards and related processes
address server functions that need to have different
security levels, or that may introduce security
weaknesses to other functions on the same server.
For example:
1. A database, which needs to have strong security
measures in place, would be at risk sharing a server
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.
NC

address server functions that need to have different
security levels, or that may introduce security
weaknesses to other functions on the same server.
For example:
1. A database, which needs to have strong security
measures in place, would be at risk sharing a server
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.
As stated in Requirement 1.1.5, there are many

protocols that a business may need (or have enabled
by default) that are commonly used by malicious
individuals to compromise a network. To ensure that
only the necessary services and protocols are
enabled and that all insecure services and protocols
are adequately secured before new servers are
deployed, this requirement should be part of your
organization's configuration standards and related
processes.
C3.3
C10.1
This is intended to ensure your organizations system

specifically address security settings and parameters
that have known security implications.
C3.3
C10.6
The server-hardening standards must include

processes to address unnecessary functionality with
specific security implications (like removing/disabling
FTP or the web server if the server will not be
performing those functions).
C3.3
If remote administration is not done with secure

authentication and encrypted communications,
sensitive administrative or operational level
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.
C10.6
This is intended for hosting providers that provide

shared hosting environments for multiple clients on
the same server. When all data is on the same server
and under control of a single environment, 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.
NC
y parameters
s to compromise systems. These passwords and settings are well known by hacker communities and are easily determined
from 48 percent.
and 67 percent respectively.
comes down to building and maintaining a system in a compliant manner (Requirement 2.2.3c), were still failing in over a
Testing Procedure
2.1 Choose a sample of system components, and attempt to log on (with system
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.)
2.1.1 Verify the following regarding vendor default settings for wireless 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.
2.2.a Examine the organizations system configuration standards for all types of system
components and verify the system configuration standards are consistent with industryaccepted hardening standards.
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).
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.
2.2.2.a For a sample of system components, inspect enabled system services,

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.
2.2.3.a Interview system administrators and/or security managers to verify that they
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.
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.
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.
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.
unities and are easily determined via public information.
.2.3c), were still failing in over a quarter of all cases.
Validation Instructions for QSA/ISA

Identify the sample of system components observed.
For each sampled system component, describe how attempts to log on using vendorsupplied accounts and passwords confirm that all default accounts and passwords are
changed before installing a system on the network.
Identify the document requiring that wireless encryption keys must be changed: i.
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
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
changed.
Describe how observed wireless configurations confirm that default SNMP
community strings are changed.
Identify the document requiring that default passwords/passphrases on access points

must be changed.
Describe how observed wireless configurations confirm that default
passwords/passphrases are changed.
Identify the document requiring that firmware on wireless devices must be updated to
support encryption for authentification and transmission
Describe how observed wireless configurations confirm that firware is updated to
support strong encryption for authnetification and transmission.
Identify the document that defines any other security-related wireless vendor defaults.
Describe how the observed wireless configurations confirm that other securityrelated 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
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.
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 are
applied.
Describe how it was observed that configuration standards are applied when new
systemsthe
aresystem
configured.
Identify
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.
iii. System security parameters are configured to prevent misuse.
iv. All unnecessary functionality (for example, scripts, drivers, features, subsystems, file
systems, etc.) is removed.
For each sampled system component, describe how observed system configurations
confirm
that only one primary function per server is implemented.
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
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
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
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
common security parameter settings for the system components that they configure.
Identify the system configuration standards that define the common security
parameter
settings.
For each sampled system component, describe how common security parameters
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.
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.
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 functionality is
present on the system components.
Identify the sample of system components observed For each sampled system
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 administrator
password is requested.
For each sampled system component, describe how the observed services and
parameter files confirm that the following are not available for use internally:
Telnett and other remote-login command
For each sampled system component:
i. Describe how administrator access to web-based management interfaces is configured
to
require strong cryptography.
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.
Priority
A B C-VT
In place?
Severity
3
3
26
Y
N
C
67
67
0 0
12
Proofs / Documentation links
Remediation plan
Comments
Owner
Requirement 3: Protect stored cardholder data
Protection methods such as encryption, truncation, masking, and hashing are critical components of cardholder
data if full PAN is not needed, and not sending unprotected PANs using end-user messaging technologies, such a
Please refer to the PCI DSS and PA-DSS Glossary of Terms, Abbreviations, and Acronyms for definitions of strong
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,
PCI DSS Requirement
3.1 Keep cardholder data storage to a minimum by

implementing data retention and disposal policies,
procedures and processes, as follows.
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
data
- A quarterly automatic or manual process for
identifying and securely deleting stored cardholder
data that exceeds defined retention requirements
3.2 Do not store sensitive authentication data after

authorization (even if encrypted).
Sensitive authentication data includes the data as
cited in the following Requirements 3.2.1 through
3.2.3:
Note: It is permissible for issuers and companies that
support issuing services to store sensitive
authentication data if there is a business justification
and the data is stored securely.
3.2.1 Do not store the full contents of any track

(from the magnetic stripe located on the back of a
card, equivalent data contained on a chip, or
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

value (three-digit or four-digit number printed on
the front or back of a payment card) used to verify
card-notpresent transactions.
3.2.3 Do not store the personal identification

number (PIN) or the encrypted PIN block.
3.3 Mask PAN when displayed (the first six and last
four digits are the maximum number of digits to be
displayed).
Notes:
- This requirement does not apply to employees and
other parties with a legitimate business need to see
the full PAN.
- This requirement does not supersede stricter
requirements in place for displays of cardholder data
for example, for point-of-sale (POS) receipts.
3.4 Render PAN unreadable anywhere it is stored

(including on portable digital media, backup media,
and in logs) by using any of the following approaches:
- One-way hashes based on strong cryptography
(hash must be of the entire PAN)
- Truncation (hashing cannot be used to replace the
truncated segment of PAN)
- Index tokens and pads (pads must be securely
stored)
- Strong cryptography with associated keymanagement processes and procedures
Note: It is a relatively trivial effort for a
malicious individual to reconstruct original
PAN data if they have access to both the
truncated and hashed version of a PAN.
Where hashed and truncated versions of
the same PAN are present in an entitys
environment, additional controls should
be in place to ensure that the hashed and
truncated versions cannot be correlated
to reconstruct the original PAN.
3.4.1 If disk encryption is used (rather than file- or

column-level database encryption), logical access
must be managed independently of native
operating system access control mechanisms (for
example, by not using local user account
databases). Decryption keys must not be tied to
user accounts.
3.5 Protect any keys used to secure cardholder data

against disclosure and misuse:
Note: This requirement also applies to keyencrypting keys used to protect dataencrypting keys
such key-encrypting keys must be at least as
strong as the data-encrypting key.
3.5.1 Restrict access to cryptographic keys to the

fewest number of custodians necessary.
3.5.2 Store cryptographic keys securely in the fewest
possible locations and forms.
3.5.2 Store cryptographic keys securely in the fewest

3.6 Fully document and implement all keymanagement processes and procedures for
cryptographic keys used for encryption of cardholder
data, including the following:
Note: Numerous industry standards for key
management are available from various resources
including NIST, which can be found at
http://csrc.nist.gov.
3.6.1 Generation of strong cryptographic keys
3.6.2 Secure cryptographic key distribution
3.6.3 Secure cryptographic key storage
3.6.4 Cryptographic key changes for keys that

have reached the end of their cryptoperiod (for
example, after a defined period of time has passed
and/or after a certain amount of ciphertext has
been produced by a given key), as defined by the
associated application vendor or key owner, and
based on industry best practices and guidelines (for
example, NIST Special Publication 800-57).
3.6.5 Retirement or replacement (for example,

archiving, destruction, and/or revocation) of keys as
deemed necessary when the integrity of the key
has been weakened (for example, departure of an
employee with knowledge of a clear-text key), or
keys are 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

management operations are used, these operations
must be managed using split knowledge and dual
control (for example, requiring two or three people,
each knowing only their own key component, to
reconstruct the 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

cryptographic keys.
3.6.8 Requirement for cryptographic key

custodians to formally acknowledge that they
understand and accept their key-custodian
responsibilities.
ardholder data
cation, masking, and hashing are critical components of cardholder data protection. If an intruder circumvents other securi
ng unprotected PANs using end-user messaging technologies, such as e-mail and instant messaging.
sary of Terms, Abbreviations, and Acronyms for definitions of strong cryptography and other PCI DSS terms.
CI Compliance report
m seems to be a particularly difficult task for many companies.
n policy
et with Requirement 3.1
s met only 63 percent of the time.
of cases,
Guidance
A formal data retention policy identifies what data

needs to be retained, and where that data resides 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.
SANS
Top 20 Critical
Security Controls
NC
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
NC
Sensitive authentication data consists of magnetic

stripe (or track) data6, card validation code or
value7, and PIN data8. Storage of sensitive
authentication data after authorization is prohibited!
This data is very valuable to malicious individuals as
it allows them to generate counterfeit payment cards
and create fraudulent transactions. See PCI DSS and
PA-DSS Glossary of Terms, Abbreviations, and
Acronyms for the full definition 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.
NA
If full track data is stored, malicious individuals who

obtain that data can reproduce and sell payment
cards.
NA
The purpose of the card validation code is to protect

"card-not-present" transactionsInternet or mail
order/telephone order (MO/TO) transactionswhere
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 inhand and can read the value. If this prohibited data is
stored and subsequently stolen, malicious individuals
can execute fraudulent Internet and MO/TO
transactions.
NA
These values should be known only to the card 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).
NA
The display of full PAN on items such as computer

screens, payment card receipts, faxes, or paper
reports can result in this data being obtained by
unauthorized individuals and used fraudulently. The
PAN can be displayed in full form on the merchant
copy receipts; however the paper receipts should
adhere to the same security requirements as
electronic copies and follow the guidelines of the PCI
Data Security Standard, especially Requirement 9
regarding physical security. The full PAN can also be
displayed for those with a legitimate business need
to see the full PAN.
NA
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.
Lack of protection of PANs can allow malicious

individuals to view or download this data. PANs stored
in primary storage (databases, or flat files such as
text files spreadsheets) as well as non-primary
storage (backup, audit logs, exception or
troubleshooting logs) must all be protected. Damage
from theft or loss of backup tapes during transport
can be reduced by ensuring PANs are rendered
unreadable via encryption, truncation, or hashing.
Since audit, troubleshooting, and exception logs have
to be retained, you can prevent disclosure of data in
logs by rendering PANs unreadable (or removing
them) in logs.
By correlating hashed and truncated versions of a
given PAN, a malicious individual may easily derive
the original PAN value. Controls that prevent the
correlation of this data will help ensure that the
original PAN remains unreadable.
Please refer to the PCI DSS and PA-DSS Glossary of
Terms, Abbreviations, and Acronyms for definitions of
strong cryptography.
C17.7
C8.4
The intent of this requirement is to address the

acceptability of disk encryption for rendering
cardholder data unreadable. Disk encryption encrypts
data stored on a computer's mass storage and
automatically decrypts the information when an
authorized user requests it. Disk-encryption systems
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:
NC
1) A direct association with the operating system, or

2) Decryption keys that are associated with user
accounts.
Cryptographic keys must be strongly protected

because those who obtain access will be able to
decrypt data. Key-encrypting keys, if used, must be
at least as strong as the data-encrypting key in order
to ensure proper protection of the key that encrypts
the data as well as the data encrypted with that key.
NC
The requirement to protect keys from disclosure and

misuse applies to both data- encrypting keys and keyencrypting 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 keyencrypting keys include but are not limited to
hardware security modules (HSMs) and tamper
evident storage with dual control and split
knowledge.
There should be very few who have access to

cryptographic keys, usually only those who have key
custodian responsibilities.
NC
Cryptographic keys must be stored securely, usually

encrypted with key-encrypting keys, and stored in
very few locations. It is not intended that the keyencrypting 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.
NC
Cryptographic keys must be stored securely, usually

encrypted with key-encrypting keys, and stored in
very few locations. It is not intended that the keyencrypting 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.
The manner in which cryptographic keys are
managed is a critical part of the continued security of
the encryption solution. A good key management
process, whether it is manual or automated as part of
the encryption product, is based on industry
standards and addresses all key elements at 3.6.1
through 3.6.8.
NC
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."
NC
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.
NC
The encryption solution must store keys securely,

meaning the keys are not stored in the clear (encrypt
them with a key-encryption key).
NC
A cryptoperiod is the time span during which a

particular cryptographic key can be used for its
defined purpose. Considerations for defining the
cryptoperiod include, but are not limited to, the
strength of the underlying algorithm, size or length of
the key, risk of key compromise, and the sensitivity of
the data being encrypted.
Periodic changing of encryption keys when the keys
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.
NC
Old keys that are no longer used or needed should be

retired and destroyed to ensure that the keys can no
longer be used. If old keys need to be kept (to
support archived, encrypted data, for example) they
should be strongly protected. (See 3.6.6 below.) The
encryption solution should also allow for and facilitate
a process to replace keys that are known to be, or
suspected of being, compromised.
NC
Split knowledge and dual control of keys are used to

eliminate the possibility of one persons having
access to the whole key. This control is applicable for
manual key management operations, or where key
management is not implemented by the encryption
product.
NC
The encryption solution should not allow for or accept

substitution of keys coming from unauthorized
sources or unexpected processes.
NC
This process will ensure individuals that act as key

custodians commit to the key- custodian role and
understand the responsibilities.
NC
ction. If an intruder circumvents other security controls and gains access to encrypted data, without the proper cryptograp
nd instant messaging.
aphy and other PCI DSS terms.
Testing Procedure
3.1 Obtain and examine the policies, procedures and processes for data retention and
disposal, and perform the following:
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.
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:
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
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.
3.4.a Obtain and examine documentation about the system used to protect the PAN,
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.
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.
3.5 Verify processes to protect keys used for encryption of cardholder data against
disclosure and misuse by performing the following:
3.5.1 Examine user access lists to verify that access to keys is restricted to the fewest
number of custodians necessary.
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
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:

3.6.1 Verify that key-management procedures are implemented to require the
generation of strong keys.
3.6.2 Verify that key-management procedures are implemented to require secure key
distribution.
3.6.3 Verify that key-management procedures are implemented to require secure key
storage.
3.6.4 Verify that key-management procedures are implemented to require periodic

key changes at the end of the defined cryptoperiod.
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.
3.6.6 Verify that manual clear-text key-management procedures require split

knowledge and dual control of keys.
3.6.7 Verify that key-management procedures are implemented to require the

prevention of unauthorized substitution of keys.
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.
a, without the proper cryptographic keys, the data is unreadable and unusable to that person. Other effective methods of p

Identify the documented policies and procedures that:

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
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 coverage
for all storage of cardholder data.
Identify the documented policies and procedures that:

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.
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
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:
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.

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.

For each sampled system component and data source, describe how observation of
the data sources confirms that card verification codes or values (CVV2, CVC2, CID, CAV2)
are not stored under any circumstance.

For each sampled system component and data source, describe how observation of
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.

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,

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.

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.
For each item in the sample, describe how PAN was observed to be rendered
unreadable.
Identify the sample of audit logs observed.
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:

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 be

stored securely.
If disk encryption is used, describe how cardholder data on removable media
was observed to be encrypted wherever stored.
Identify observed user access lists for cryptographic key storage.

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.
Keysarestoredinencryptedform.
ii. Key-encrypting keys are stored separately from data encrypting keys.
Identify all locations where keys are stored.

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
encryption of cardholder data.
If the entity being assessed is a service provider:

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.
Identify the document that defines procedures for the generation of strong keys.
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.
Describe how the procedures for secure key distribution were observed to be
implemented.
Identify the document that defines procedures for secure key storage.
Describe how the procedures for secure key storage were observed to be
implemented.
Identify the document that defines:

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
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
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
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 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

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
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.
son. Other effective methods of protecting stored data should be considered as potential risk mitigation opportunities. For e
Priority
C-VT
In Place ?
Severity
###
###
###
###
###
###
###
###
###
###
###
###
###
###
###
###
###
###
###
###
###
###
###
###
###
###
###
###
###
###
###
###
###
###
###
###
###
137
###
0
37
Y
N
C
135
l risk mitigation opportunities. For example, methods for minimizing risk include not storing cardholder data unless absolut
Proofs /
Documentation
links
minimizing risk include not storing cardholder data unless absolutely necessary, truncating cardholder
Remediation plan
Comments
Owner
Name 1
Requirement 4: Encrypt transmission of cardholder data across open, public netwo
Sensitive information must be encrypted during transmission over networks that are easily accessed by maliciou
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 contain
PCI DSS Requirement
4.1 Use strong cryptography and security protocols

(for example, SSL/TLS, IPSEC, SSH, etc.) to safeguard
sensitive cardholder data during transmission over
open, public networks.
Examples of open, public networks that are in scope
of the PCI DSS include but are not limited to:
-
The Internet
Wireless technologies,
Global System for Mobile communications (GSM)
General Packet Radio Service (GPRS).
4.1.1 Ensure wireless networks transmitting

cardholder data or connected to the cardholder
data environment, use industry best practices (for
example, IEEE 802.11i) to implement strong
encryption for authentication and transmission.
Note: The use of WEP as a security control was
prohibited as of 30 June 2010.
4.2 Never send unprotected PANs by end-user

messaging technologies (for example, e-mail, instant
messaging, chat, etc.).
ssion of cardholder data across open, public networks
ring transmission over networks that are easily accessed by malicious individuals. Misconfigured wireless networks and vul
from 63 percent to 72 percent.
less networks and no longer allow any PCI- regulated traffic containing sensitive cardholder data to flow over the airwaves
Guidance
SANS
Top 20 Critical
Security Controls
Sensitive information must be encrypted during

transmission over public networks, because it is easy
and common for a malicious individual to intercept
and/or divert data while in transit.
C15.4.1
C17.6
For example, Secure Sockets Layer (SSL) encrypts

web pages and the data entered into them. When
using SSL secured websites, ensure https is part of
the URL.
Note that some protocol implementations (such as
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.
Malicious users use free and widely available tools

to eavesdrop on wireless communications. Use of
strong cryptography can limit disclosure of
sensitive information across the network. Many
known compromises of cardholder data stored only
in the wired network originated when a malicious
user expanded access from an insecure wireless
network. Examples of wireless implementations
requiring strong cryptography include but are not
limited to GPRS, GSM, WIFI, satellite, and Bluetooth.
C7.1
C7.10
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 networkor
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.
E-mail, instant messaging, and chat can be easily

intercepted by packet-sniffing during delivery
traversal across internal and public networks. Do not
utilize these messaging tools to send PAN unless they
provide strong encryption.
NA
s. Misconfigured wireless networks and vulnerabilities in legacy encryption and authentication protocols continue to be tar
e cardholder data to flow over the airwaves.
Testing Procedure
4.1 Verify the use of security protocols wherever cardholder data is transmitted or
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.
4.1.1 For wireless networks transmitting cardholder data or connected to the
cardholder data environment, verify that industry best practices (for example, IEEE
802.11i) are used to implement strong encryption for authentication and transmission.
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.
ation protocols continue to be targets of malicious individuals who exploit these vulnerabilities to gain privileged access to c
Vaidation Instructions for QSA/ISA

Identify all instances where cardholder data is transmitted or received over open, 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.

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
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
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:
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
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
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
each identified instance:
i. Describe the method used for securing PAN or rendering it unreadable for each enduser 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
end-user messaging technologies.
ties to gain privileged access to cardholder data environments.
Priority
C-VT
In Place?
Severity
18
Y
N
C
14
Proofs /
Documentation links
Remediation plan
Comments
Owner
Requirement 5: Use and regularly update anti-virus software or programs
Malicious software, commonly referred to as malwareincluding viruses, worms, and Trojansenters the netw
PCI DSS Requirement
5.1 Deploy anti-virus software on all systems

commonly affected by malicious software
(particularly personal computers and servers).
5.1.1 Ensure that all anti-virus programs are

capable of detecting, removing, and protecting
against all known types of malicious software.
5.2 Ensure that all anti-virus mechanisms are

current, actively running, and generating audit logs.
y update anti-virus software or programs
malwareincluding viruses, worms, and Trojansenters the network during many business approved activities including
Requirement 5 (Use
Guidance
SANS
Top 20 Critical
Security Controls
There is a constant stream of attacks using widely

published exploits, often "0 day" (published and
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.
C5.1
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.
It is important to protect against ALL types and
forms of malicious software.
C5.1
C5.2
C5.3
C5.4
C5.5
The best anti-virus software is limited in 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.
C5.2
many business approved activities including employee e-mail and use of the Internet, mobile computers, and storage device
Major Observations from the 2011 Verizon PCI Compliance Report:

Requirement 5 (Use and regularly update anti-virus software or programs) dropped from 70 percent la
Testing Procedure
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.
5.1.1 For a sample of system components, verify that all anti-virus programs detect,
remove, and protect against all known types of malicious software (for example,
viruses, Trojans, worms, spyware, adware, and rootkits).
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.
e computers, and storage devices, resulting in the exploitation of system vulnerabilities. Anti-virus software must be used
Verizon PCI Compliance Report:

rams) dropped from 70 percent last year to 64 percent this year.

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

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.
iii. Protect against all known types of malicious software.
Identify the policy document that requires updating of anti-virus software and definitions.
For i.
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.
Automatic updates are performed.
Periodic scans are performed.
Identify the sample of system components observed (include all operating system 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.
iii. Automatic updates are performed.
iv. Periodic scans are performed.
Identify the sample of system components observed
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.
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.
Anti-virus software must be used on all systems commonly affected by malware to protect systems from current and evolvin
Priority
A B C-VT
In Place?
Severity
###
###
###
###
###
###
###
###
0 0
Y
N
C
14
14
protect systems from current and evolving malicious software threats.
Proofs /
Documentation links
e threats.
Remediation plan
Comments
Owner
Requirement 6: Develop and maintain secure systems and applications
Unscrupulous individuals use security vulnerabilities to gain privileged access to systems. Many of these vulnera
Note: Appropriate software patches are those patches that have been evaluated and tested sufficiently to deter

Requirement 6 (Develop and maintain secure systems and applications) is up from 48 percent overall complianc
Patching itself is still an issue, as only 74 percent of businesses were able to make certain that all systems were
PCI DSS Requirement
6.1 Ensure that all system components and software

are protected from known vulnerabilities by having
the latest vendor-supplied security patches installed.
Install critical security patches within one month of
release.
Note: An organization may consider applying a riskbased approach to prioritize their patch installations.
For example, by prioritizing critical infrastructure (for
example, public-facing devices and systems,
databases) higher than less-critical internal devices,
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

ranking to newly discovered security vulnerabilities.
Notes:
- Risk rankings should be based on industry best
practices. For example, criteria for ranking High
risk vulnerabilities may include a CVSS base score of
4.0 or above, and/or a vendor-supplied patch
classified by the vendor as critical, and/or a
vulnerability affecting a critical system component.
- The ranking of vulnerabilities as defined in 6.2.a is
considered a best practice until June 30, 2012, after
which it becomes a requirement.
Notes:
- Risk rankings should be based on industry best
practices. For example, criteria for ranking High
risk vulnerabilities may include a CVSS base score of
4.0 or above, and/or a vendor-supplied patch
classified by the vendor as critical, and/or a
vulnerability affecting a critical system component.
- The ranking of vulnerabilities as defined in 6.2.a is
considered a best practice until June 30, 2012, after
which it becomes a requirement.
6.3 Develop software applications (internal and

external, and including webbased administrative
access to applications) in accordance with PCI DSS
(for example, secure authentication and logging), and
based on industry best practices. Incorporate
information security throughout the software
development life cycle. These processes must include
the following:
6.3.1 Removal of custom application accounts,

user IDs, and passwords before applications
become active or are released to customers
6.3.2 Review of custom code prior to release to

production or customers in order to identify any
potential coding vulnerability.
Note: This requirement for code reviews applies to
all custom code (both internal and public-facing), as
part of the system development life cycle. Code
reviews can be conducted by knowledgeable
internal personnel or third parties. Web applications
are also subject to additional controls, if they are
public facing, to address ongoing threats and
vulnerabilities after
implementation, as defined at PCI DSS
Requirement 6.6.
6.4 Follow change control processes and procedures

for all changes to system components. The processes
must include the following:
6.4.1 Separate development/test and production
environments
6.4.2 Separation of duties between

development/test and production environments
6.4.3 Production data (live PANs) are not used for

testing or development
6.4.4 Removal of test data and accounts before

production systems become active
6.4.5 Change control procedures for the

implementation of security patches and software
modifications. Procedures must include the
following:
6.4.5.1 Documentation of impact.
6.4.5.2 Documented change approval by

authorized parties.
6.4.5.3 Functionality testing to verify that the

change does not adversely impact the security of
the system.
6.4.5.4 Back-out procedures.
6.5 Develop applications based on secure coding

guidelines. Prevent common coding vulnerabilities in
software development processes, to include the
following:
Note: The vulnerabilities listed at 6.5.1 through 6.5.9
were current with industry best practices when this
version of PCI DSS was published. However, as
industry best practices for vulnerability management
are updated (for example, the OWASP Guide, SANS
CWE Top 25, CERT Secure Coding, etc.), the current
best practices must be used for these
requirements.
version of PCI DSS was published. However, as

industry best practices for vulnerability management
are updated (for example, the OWASP Guide, SANS
CWE Top 25, CERT Secure Coding, etc.), the current
best practices must be used for these
requirements.
6.5.1 Injection flaws, particularly SQL injection.

Also consider OS Command Injection, LDAP and
XPath injection flaws as well as other injection
flaws.
6.5.2 Buffer overflow
6.5.3 Insecure cryptographic storage
6.5.4 Insecure communications
6.5.5 Improper error handling
6.5.6 All High vulnerabilities identified in the

vulnerability identification process (as defined in
PCI DSS Requirement 6.2).
Note: This requirement is considered a best
practice until June 30, 2012, after which it becomes
a requirement.
6.5.7 Cross-site scripting (XSS)
6.5.8 Improper Access Control (such as insecure

direct object references, failure to restrict URL
access, and directory traversal)
6.5.9 Cross-site request forgery (CSRF)
6.6 For public-facing web applications, address new

threats and vulnerabilities on an ongoing basis and
ensure these applications are protected against
known attacks by either of the following methods:
- Reviewing public-facing web applications via manual
or automated application vulnerability security
assessment tools or methods, at least annually and
after any changes
- Installing a web-application firewall in front of
public-facing web applications
ntain secure systems and applications
rabilities to gain privileged access to systems. Many of these vulnerabilities are fixed by vendorprovided security patches, w
e patches that have been evaluated and tested sufficiently to determine that the patches do not conflict with existing secu
e systems and applications) is up from 48 percent overall compliance to 53 percent.
rcent of businesses were able to make certain that all systems were properly patched at the time of the IROC.
Guidance
SANS
Top 20 Critical
Security Controls
There are a considerable amount of attacks using

widely published exploits, often "0 day" (published
within the hour) against otherwise secured systems.
Without implementing the most recent patches on
critical systems as soon as possible, a malicious
individual can use these exploits to attack and
disable the network. Consider prioritizing changes
such that critical security patches on critical or at-risk
systems can be installed within 30 days, and other
less-risky changes are installed within 2-3 months.
C3.7
C4.1.1
The intention of this requirement is that organizations

keep up-to-date with new vulnerabilities that may
impact their environment.
C4.5
While it is important to monitor vendor

announcements for news of vulnerabilities and
patches related to their products, it is equally
important to monitor common industry vulnerability
news groups and mailing lists for vulnerabilities and
potential workarounds that may not yet be known or
resolved by the vendor.
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
While it is important to monitor vendor

announcements for news of vulnerabilities and
patches related to their products, it is equally
important to monitor common industry vulnerability
news groups and mailing lists for vulnerabilities and
potential workarounds that may not yet be known or
resolved by the vendor.
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
Without the inclusion of security during the

requirements definition, design, analysis, and testing
phases of software development, security
vulnerabilities can be inadvertently or maliciously
introduced into the production environment.
C6.6
C19.4
Custom application accounts, user IDs, and passwords

should be removed from production 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.
C3.3
Security vulnerabilities in custom code are commonly

exploited by malicious individuals to gain access to a
network and compromise cardholder data.
C6.3
Code reviews may be performed manually, or with

the assistance of automated review tools. Automated
review tools have functionality that reviews code for
common coding mistakes and vulnerabilities. While
automated review is useful, it should not generally be
relied upon as the sole means of code review. An
individual knowledgeable and experienced in code
review should be involved 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.
Without proper change controls, security features

could be inadvertently or deliberately omitted or
rendered inoperable, processing irregularities could
occur, or malicious code could be introduced.
Due to the constantly changing state of 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.
C20.7
Reducing the number of personnel with access to

the production environment and cardholder data
minimizes risk and helps ensure that access is
limited to those individuals with a business need to
know.
NC
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.
Security controls are usually not as stringent in 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.
Test data and accounts should be removed from
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.
Without proper change controls, security features
could be inadvertently or deliberately omitted or
rendered inoperable, processing irregularities could
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.
NC
NC
NC
The impact of the change should be documented so

that all affected parties will be able to plan
appropriately for any processing changes.
NC
Approval by authorized parties indicates that the

change is a legitimate and approved change
sanctioned by the organization.
NC
Thorough testing should be performed to verify that

the security of the environment is not reduced by
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.
C6.3
For each change, there should be back-out

procedures in case the change fails, to allow for
restoring back to the previous state.
NC
The application layer is high-risk and may be targeted

by both internal and external threats. Without proper
security, cardholder data and other confidential
company information can be exposed, resulting in
harm to a company, its customers, and its reputation.
As with all PCI DSS requirements, Requirements 6.5.1
through 6.5.5 and 6.5.7 through 6.5.9 are the
minimum controls that should be in place. This list is
composed of the most common, accepted secure
coding practices at the time that this version of the
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
C6.7
through 6.5.5 and 6.5.7 through 6.5.9 are the

minimum controls that should be in place. This list is
composed of the most common, accepted secure
coding practices at the time that this version of the
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.
Validate input to verify user data cannot modify

meaning of commands and queries. Injection flaws,
particularly SQL injection, are a commonly 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 commerceenabled 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.
C6.1
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.
NC
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.
NC
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.
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."
NC
Any high vulnerabilities noted per Requirement 6.2

that could affect the application should be
accounted for during the development phase. For
example, a vulnerability identified in a shared
library or in the underlying operating system should
be evaluated and addressed prior to the application
being released to production.
NA
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.
C6.1
Do not expose internal object references to users. A

direct object reference occurs when a 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.
NC
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.
C6.1
Attacks on web-facing applications are common and

often successful, and are allowed by poor coding
practices. This requirement for reviewing applications
or installing web-application firewalls is intended to
greatly reduce the number of compromises on publicfacing web applications that result in breaches of
cardholder data.
Manual or automated vulnerability security
assessment tools or methods that review and/or scan
for application vulnerabilities can be used to satisfy
this requirement
Web-application firewalls filter and block nonessential 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.
C13.12
C6.1
C6.3
C11.6
fixed by vendorprovided security patches, which must be installed by the entities that manage the systems. All critical syste
e patches do not conflict with existing security configurations. For in-house developed applications, numerous vulnerabilitie
ent.
ched at the time of the IROC.
Testing Procedure
6.1.a For a sample of system components and related software, compare the list of
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.
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.
6.3.a Obtain and examine written software development processes to verify that the
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:
6.3.1 Custom application accounts, user IDs and/or passwords are removed before
system goes into production or is released to customers.
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:
6.4.1 The development/test environments are separate from the production
environment, with access control in place to enforce the separation.
6.4.2 There is a separation of duties between personnel assigned to the

development/test environments and those assigned to the production environment.
6.4.3 Production data (live PANs) are not used for testing or development.
6.4.4 Test data and accounts are removed before a production system becomes
active.
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:
6.4.5.1 Verify that documentation of impact is included in the change control
documentation for each sampled change.
6.4.5.2 Verify that documented approval by authorized parties is present for each
sampled change.
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.
6.4.5.4 Verify that back-out procedures are prepared for each sampled change.
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:
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.)
6.5.2 Buffer overflow (Validate buffer boundaries and truncate input strings.)
6.5.3 Insecure cryptographic storage (Prevent cryptographic flaws)
6.5.4 Insecure communications (Properly encrypt all authenticated and sensitive

communications)
6.5.5 Improper error handling (Do not leak information via error messages)
6.5.6 All High vulnerabilities as identified in PCI DSS Requirement 6.2.
6.5.7 Cross-site scripting (XSS) (Validate all parameters before inclusion, utilize
context-sensitive escaping, etc.)
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.)
6.5.9 Cross-site request forgery (CSRF). (Do not reply on authorization credentials and
tokens automatically submitted by browsers.)
6.6 For public-facing web applications, ensure that either one of the following methods
are in place as follows:
- 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 thirdparty company or an internal organization, as long as the reviewers specialize in
application security and can demonstrate independence from the development team.
age the systems. All critical systems must have the most recently released, appropriate software patches to protect agains
lications, numerous vulnerabilities can be avoided by using standard system development processes and secure coding te

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
related
software were observed to be installed.
Identify the document requiring that all critical new security patches are installed 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
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.
Identify the documented software development processes that include information
security throughout the software development life cycle.
Identify the documented software development processes that specify how software
applications are developed in accordance with PCI DSS.
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 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.
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.
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 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:
Describe how it was observed that:
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.
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
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
Identify the sample of: i. System components

ii. Recent changes/security patches
For each sampled change, describe how documentation of the impact of the 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 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 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.
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
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.
Identify the sample of developers interviewed.

Describe how the interviewed personnel demonstrated they are knowledgeable in
secure
coding techniques.
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.
not vulnerable to buffer overflow.
vulnerable to insecure cryptographic storage.
not vulnerable to insecure cryptographic storage.
vulnerable to insecure communications.
not vulnerable to insecure communications.
vulnerable to improper error handling.
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
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).
application interfaces are not vulnerable to improper access control.
Describe the processes observed to be in place for ensuring that web applications and
application interfaces are not vulnerable to improper access control.
application interfaces are not vulnerable to cross-site request forgery.
Describe the processes observed to be in place for ensuring that web applications and
application interfaces are not vulnerable to cross-site request forgery.
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.
If a web-application firewall(s) is used:
i. Describe how the web-application firewall was observed to be placed in front of all
publicfacing 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
oftware patches to protect against exploitation and compromise of cardholder data by malicious individuals and malicious s
t processes and secure coding techniques.
Priority
A B C-VT
In Place?
Severity
3
3
3
36
Y
N
C
129
129
0 0
cious individuals and malicious software.
Proofs /
Documentation links
Remediation plan
Comments
Owner
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 t
Need to know is when access rights are granted to only the least amount of data and privileges needed to per
PCI DSS Requirement
7.1 Limit access to system components and

cardholder data to only those individuals whose job
requires such access. Access limitations must include
the following:
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
components with multiple users that restricts access
based on a users need to know, and is set to deny
all unless specifically allowed.
This access control system must include the
following:
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.
o cardholder data by business need to know
by authorized personnel, systems and processes must be in place to limit access based on need to know and according to
anted to only the least amount of data and privileges needed to perform a job.
The percentage of orga

Organizations
Most organizations fail to meet it in full due to lack
Whe
Guidance
The more people who have access to cardholder

data, the more risk there is that a users account will
be used maliciously. Limiting access to those with a
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.
SANS
Top 20 Critical
Security Controls
C12.1.1
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.
C12.6
C12.7
NC
C12.1.1
NC
Without a mechanism to restrict access based on
users need to know, a user may unknowingly be
granted access to cardholder data. Use of an
automated access control system or mechanism is
essential to manage multiple users. This system
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.
C12.14
C15.3
NC
C12.14
NC
cess based on need to know and according to job responsibilities.
b.
Major Observations 2011 Verizon PCI Compliance Repo

The percentage of organizations fully meeting Requirement 7 at time of IROC was 75 percent, an eig
Organizations met an average of 87 percent of tests in Requirement 7 at time of IROCthe
organizations fail to meet it in full due to lack of a documented and enforced access control policy as well as fail to automa
When implementing access controls, several organizations are still focusing too m
Testing Procedure
7.1 Obtain and examine written policy for data control, and verify that the policy
incorporates the following:
7.1.1 Confirm that access rights for privileged user IDs are restricted to least
privileges necessary to perform job responsibilities.
7.1.2 Confirm that privileges are assigned to individuals based on job classification
and function (also called role-based access control or RBAC).
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.
7.1.4 Confirm that access controls are implemented via an automated access control
system.
7.2 Examine system settings and vendor documentation to verify that an access control
system is implemented as follows:
7.2.1 Confirm that access control systems are in place on all system components.
7.2.2 Confirm that access control systems are configured to enforce privileges
assigned to individuals based on job classification and function.
7.2.3 Confirm that the access control systems have a default deny-all setting.
011 Verizon PCI Compliance Report:

e of IROC was 75 percent, an eight percent increase over the 2010 report results.
quirement 7 at time of IROCthe highest among all twelve key controls.
ol policy as well as fail to automate the process of identifying and maintaining a list of authorized personnel.
anizations are still focusing too much on the network perimeter.

Identify the data control policy document which requires that access rights for
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
individuals based on job classification and function.
Identify the data control policy document that requires the following:
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
implemented using an automated access control system
Describe the access control systems in use.

Describe how access control systems were observed to be in place on all system
components.
For each access control system in use:
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:
i. Describe how the access control system was observed to have a default deny-all
setting.
horized personnel.
Priority
C-VT
In place?
Severity
###
###
###
###
###
###
###
###
###
36
###
0
Y
N
C
36
Proofs /
Documentation links
Remediation plan
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
Sub-requirement 8.3 (Ensure proper user authentication and password management for non-consumer u
Sub-requirements 8.4 (Render all passwords unreada
PCI DSS Requirement
8.1 Assign all users a unique ID before allowing them

to access system components or cardholder data.
8.2 In addition to assigning a unique ID, employ at

least one of the following methods to authenticate all
users:
- 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
8.3 Incorporate two-factor authentication for remote

access (network-level access originating from outside
the network) to the network by employees,
administrators, and third parties. (For example,
remote authentication and dialin service (RADIUS)
with tokens; terminal access controller access control
system (TACACS) with tokens; or other technologies
that facilitate two-factor authentication.)
Note: Two-factor authentication requires that two of
the three authentication methods (see Requirement
8.2 for descriptions of authentication methods) be
used for authentication. Using one factor twice (for
example, using two separate passwords) is not
considered two-factor authentication.
8.4 Render all passwords unreadable during

transmission and storage on all system components
using strong cryptography.
8.5 Ensure proper user identification and

authentication management for nonconsumer users
and administrators on all system components as
follows:
8.5.1 Control addition, deletion, and modification
of user IDs, credentials, and other identifier objects.
8.5.2 Verify user identity before performing

password resets.
8.5.3 Set passwords for first-time use and resets to

a unique value for each user and change
immediately after the first use.
8.5.4 Immediately revoke access for any

terminated users.
8.5.5 Remove/disable inactive user accounts at

least every 90 days.
8.5.6 Enable accounts used by vendors for remote

access only during the time period needed. Monitor
vendor remote access accounts when in use.
8.5.7 Communicate authentication procedures and

policies to all users who have access to cardholder
data.
8.5.8 Do not use group, shared, or generic

accounts and passwords, or other authentication
methods.
8.5.9 Change user passwords at least every 90

days.
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

out the user ID after not more than six attempts.
8.5.14 Set the lockout duration to a minimum of

30 minutes or until administrator enables the user
ID.
8.5.15 If a session has been idle for more than 15

minutes, require the user to re-authenticate to reactivate the terminal or session.
8.5.16 Authenticate all access to any database

containing cardholder data. This includes access by
applications, administrators, and all other users.
Restrict user direct access or queries to databases
to database administrators.
ID to each person with computer access

to each person with access ensures that each individual is uniquely accountable for his or her actions
Major
More than half
Of all the compliance validation te
user authentication and password management for non-consumer users and administrators on all system components) an
Sub-requirements 8.4 (Render all passwords unreadable during transmission and storage on all system com
Most organizations do communicate their password po
Guidance
SANS
Top 20 Critical
Security Controls
By ensuring each user is uniquely identifiedinstead

of using one ID for several employeesan
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.
C12.7
These authentication items, when used in addition to

unique IDs, help protect users unique IDs from being
compromised (since the one attempting the
compromise needs to know both the unique ID and
the password or other authentication item).
C12.7
A digital certificate is a valid option as a form of the

authentication type something you have as long as
it is unique.
Two-factor authentication requires two forms of

authentication for higher-risk accesses, such as those
originating from outside your network. For additional
security, your organization can also consider using
two-factor authentication when accessing networks of
higher security from networks of lower securityfor
example, from corporate desktops (lower security) to
production servers/databases with cardholder data
(high security).
C10.6
C13.7
This requirement is intended to apply to users that

have remote access to the network, where that
remote access could lead to access to the cardholder
data environment.
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.
Many network devices and applications transmit the
user ID and unencrypted password across the
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
C12.5
Since one of the first steps a malicious individual will take

to compromise a system is to exploit weak or nonexistent
passwords, it is important to implement good processes for
user identification and authentication management.
To ensure users added to your systems are all valid

and recognized users, the addition, deletion, and
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.
C16.9
Many malicious individuals use "social engineering

for 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 resetting passwords. Ensure such questions are secured
properly and not shared.
NC
If the same password is used for every new user set

up, an internal user, former employee, or malicious
individual may know or easily discover this password,
and use it to gain access to accounts.
NC
If an employee has left the company, and still has

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.
C16.3
Existence of inactive accounts allows an

unauthorized user exploit the unused account to
potentially access cardholder data.
C16.5
Allowing vendors (like POS vendors) to have 24/7

access into your network in case they need to
support your systems increases the chances of
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.
C16.4
Communicating password/authentication procedures

to all users helps those users understand 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).
NC
If multiple users share the same authentication

credentials (for example, user account and
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.
NC
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.
should also meet PCI DSS requirements (if such

accounts are not disabled) to prevent them from
being misused.
Strong passwords are the first line of defense into a

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.
C12.3
C16.7.2
C12.1.2
C16.7
C16.7.1
C12.8
C1.7.3
Without account-lockout mechanisms in place, an

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.
C16.8
If an account is locked out due to someone

continually trying to guess a password, controls to
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.
C16.8.1
When users walk away from an open machine with

access to critical network or cardholder data, that
machine may be used by others in the users
absence, resulting in unauthorized account access
and/or account misuse.
C16.4
Without user authentication for access to databases

and applications, the potential for unauthorized or
malicious access increases, and such access cannot
be logged since the user has not been authenticated
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).
NC
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 I
nistrators on all system components) and 8.5.7 (Communicate password procedures and policies to all users who have acc
nsmission and storage on all system components using strong cryptography) and 8.5.10 (Require a minimum password len
ations do communicate their password policies and standards internally, but still experience difficulty enforcing them acros
Testing Procedure
8.1 Verify that all users are assigned a unique ID for access to system components or
cardholder data.
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).
8.3 To verify that two-factor authentication is implemented for all remote network
access, observe an employee (for example, an administrator) connecting remotely to
the network and verify that two of the three authentication methods are used.
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:
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.
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 nonface-to-face method, the users identity is verified before the password is reset.
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.
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.
8.5.5 Verify that inactive accounts over 90 days old are either removed or disabled.
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.
8.5.7 Interview the users from a sample of user IDs, to verify that they are familiar
with authentication procedures and policies.
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.
8.5.9.a For a sample of system components, obtain and inspect system configuration
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.
8.5.10.a For a sample of system components, obtain and inspect system

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.

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.

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.

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.
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.
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.
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).
tions taken on critical data and systems are performed by, and can be traced to, known and authorize
ce report:
time of the IROC.
age of 77 percent at the time of IROC.
policies to all users who have access to cardholder data) rate among the best implemented compliance test procedures wit
Require a minimum password length of at least seven characters) were the least compliant at the time of IROC.
e difficulty enforcing them across all computing devices.

Identify the document requiring that the users are assigned a unique userId before
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
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
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:
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
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
Identify the samples of: Administrator and General userIDs

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 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,
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
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 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 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
being used. Describe how vendor accounts were observed to be monitored while being
used.
Identify the sample of user IDs.
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:

Group and shared password or other authentication methods
Identify the system administrators interviewed who verify that the following are never
distributed, even if requested:
i. Group passwords or other authentication methods
ii. Shared passwords or other authentication methods
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 nonconsumer 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.
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
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:

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 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:
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
ed to, known and authorized users.
d compliance test procedures within the main compliance requirements.

at the time of IROC.
Priority
A B C-VT
In Place?
Severity
###
###
###
###
###
###
###
###
###
###
###
33
Y
N
C
132
132
###
0 0
Proofs /
Documentation links
Remediation plan
Comments
Owner
Requirement 9: Restrict physical access to cardholder data

Any physical access to data or systems that house cardholder data provides the opportunity f
personnel, service workers, or anyone who needs to enter the facility for a short duration, usu
Sub-r
The m
PCI DSS Requirement
9.1 Use appropriate facility entry controls to limit and

monitor physical access to systems in the cardholder
data environment.
9.1.1 Use video cameras and/or access control

mechanisms to monitor individual physical access
to sensitive areas. Review collected data and
correlate with other entries. Store for at least three
months, unless otherwise restricted by law.
Note: Sensitive areas refers to any data center,
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 accessible

network jacks. For example, areas accessible to
visitors should not have network ports enabled
unless network access is explicitly authorized.
9.1.3 Restrict physical access to wireless access

points, gateways, handheld devices,
networking/communications hardware, and
telecommunication lines.
9.2 Develop procedures to easily distinguish between

onsite personnel and visitors, especially in areas
where cardholder data is accessible.
9.3 Make sure all visitors are handled as follows:
9.3.1 Authorized before entering areas where

cardholder data is processed or maintained.
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
of visitor activity. Document the visitors name, the
firm represented, and the onsite personnel
authorizing physical access on the log. Retain this log
for a minimum of three months, unless otherwise
restricted by law.
9.5 Store media back-ups in a secure location,

preferably an off-site facility, such as an alternate or
back-up site, or a commercial storage facility. Review
the locations security at least annually.
9.6 Physically secure all media.
9.7 Maintain strict control over the internal or

external distribution of any kind of media, including
the following:
9.7.1 Classify media so the sensitivity of the data

can be determined.
9.7.2 Send the media by secured courier or other

delivery method that can be accurately tracked.
9.8 Ensure management approves any and all media

that is moved from a secured area (especially when
media is distributed to individuals).
9.9 Maintain strict control over the storage and

accessibility of media.
9.9.1 Properly maintain inventory logs of all media

and conduct media inventories at least annually.
9.10 Destroy media when it is no longer needed for

business or legal reasons as follows:
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.
access to cardholder data

ms that house cardholder data provides the opportunity for individuals to access devices or data and t
Majorrefers
Observat
e who needs to enter the facility for a short duration, usually not more than one day. Media
to
Sub-requirements 9.3, 9.4 (employee/visitor controls), and 9

Only about half (55 percent) o
On average, 84 percent of tests were fully met in Re
The most challenging sub-control, at time of IROC, is 9.9.1: P
Guidance
SANS
Top 20 Critical
Security Controls
Without physical access controls, unauthorized

persons could potentially gain access to the building
and to sensitive information, and could alter system
configurations, introduce vulnerabilities into the
network, or destroy or steal equipment.
NC
When investigating physical breaches, these controls

can help identify individuals that physically access
those sensitive areas storing cardholder data.
Examples of sensitive areas include corporate
database server rooms, back-end server room of a
retail location that stores cardholder data, and
storage areas for large quantities of cardholder data,
NC
Restricting access to network jacks will prevent

malicious individuals from plugging into readily
available network jacks that may allow them access
into internal network resources. Consider turning off
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.
NC
Without security over access to wireless components

and devices, malicious users could use your
organizations unattended wireless devices to 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.
NC
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.
Without badge systems and door controls,

unauthorized and malicious users can easily gain
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.
NC
Visitor controls are important to reduce the ability of

unauthorized and malicious persons to gain access to
your facilities (and potentially, to cardholder data).
Visitor controls are important to ensure visitors only
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.
NC
NC
NC
A visitor log documenting minimum information on
the visitor is easy and inexpensive to maintain and
will assist, during a potential data breach
investigation, in identifying physical access to a
building or room, and potential access to cardholder
data. Consider implementing logs at the entry to
facilities and especially into zones where cardholder
data is present.
NC
If stored in a non-secured facility, backups that

contain cardholder data may easily be lost, stolen, or
copied for malicious intent. For secure storage,
consider contracting with a commercial data storage
company OR, for a smaller entity, using a safedeposit box at a bank.
C8.4
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.
C8.4
Procedures and processes help protect cardholder

data on media distributed to internal and/or external
users. Without such procedures data can be lost or
stolen and used for fraudulent purposes.
NC
It is important that media be identified such that its

classification status can be easily discernable. Media
not identified as confidential may not be adequately
protected or may be lost or stolen
NC
NC
Media may be lost or stolen if sent via a nontrackable 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.
Cardholder data leaving secure areas without a
process approved by management can lead to lost 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.
NC
Without careful inventory methods and storage

controls, stolen or missing media could go unnoticed
for an indefinite amount of time.
NC
If media is not inventoried, stolen or lost media

may not be noticed for a long time or at all.
If steps are not taken to destroy information

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.
NC
NC
Examples of methods for securely destroying

electronic media include secure wiping, degaussing,
or physical destruction (such as grinding or shredding
hard disks).
NC
NC
iduals to access devices or data and to remove systems or hardcopies, and should be appropriately res
Majorrefers
Observations
from the
2011
Verizon Compliance
Report:
more than one day. Media
to all paper
and
electronic
media containing
cardholder data
nts 9.3, 9.4 (employee/visitor controls), and 9.6 (secure physical delivery) rate among the best implemented compliance te
Only about half (55 percent) of organizations fully met Requirement 9 at the time of IROC.
erage, 84 percent of tests were fully met in Requirement 9 at the time of IROC, a seven percent reduction from our 2010 re
nging sub-control, at time of IROC, is 9.9.1: Properly maintain inventory logs of all media and conduct media inventories at
Testing Procedure
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.
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.
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.
9.1.3 Verify that physical access to wireless access points, gateways, handheld
devices, networking/communications hardware, and telecommunication lines is
appropriately restricted.
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:
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.
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.
9.3.3 Observe visitors leaving the facility to verify visitors are asked to surrender their
ID badge upon departure or expiration.
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.
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.
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).
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.
9.7.1 Verify that all media is classified so the sensitivity of the data can be
determined.
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.
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.
9.9 Obtain and examine the policy for controlling storage and maintenance of all media
and verify that the policy requires periodic media inventories.
9.9.1 Obtain and review the media inventory log to verify that periodic media
inventories are performed at least annually.
9.10 Obtain and examine the periodic media destruction policy and verify that it covers
all media, and confirm the following:
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.
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).
should be appropriately restricted. For the purposes of Requirement 9, onsite personnel refers to ful
rt:
ining
cardholder data
best implemented compliance test procedures.

he time of IROC.
rcent reduction from our 2010 results.
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
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 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
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
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.
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
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
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
badges clearly identify visitors.
Describe how badges distinguish onsite personnel from visitors.
Describe how the use of visitor badges was observed to verify that the visitor ID 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.
Describe how observed visitors within the facility are easily distinguished from
onsite personnel.
Describe how visitor badges were observed to expire.
Describe how observed visitors were asked to surrender their ID badge upon departure
or expiration.
Describe how a visitor log was observed to be in use to record physical access to:
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
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.
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
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 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
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

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
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.

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
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 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
that the policy covers all media.
Describe the documented process for destruction of hardcopy materials.

Describe how the observed process provides reasonable assurance that hardcopy
materials cannot be reconstructed.
Describe how the containers used for storing information to be destroyed were
observed to be secured.
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.
If data is rendered unrecoverable via secure deletion or a secure wipe program,
identify the industry-accepted standards used.
site personnel refers to full-time and part-time employees, temporary employees, contractors and con
Priority
C-VT
In Place?
I
n
t
e
N
r
m
e
d
i
a
r
y
C
N
o
n
t
r
o
l
N
5
5
1
1
N
N
29
Y
N
C
111
orary employees, contractors and consultants who are physically present on the entitys premises. A v
Severity
Proofs /
Documentation links
5
5
5
111
t on the entitys premises. A visitor refers to a vendor, guest of any onsite
Remediation plan
Commen
ts
Owner
Requirement 10: Track and monitor all access to network resources and cardholder
Logging mechanisms and the ability to track user activities are critical in preventing, detecting, or minimizing th

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 fro
On average, organizations met 70 percent of tests in Requirement 10 at time of IROC, a five percent decrease fr
The most challenging sub-control appears to be 10.5.5: Use file-integrity monitoring or change-detection softwa
Other pitfalls towards compliance with Requirement 10 are the failure or inability to invest in a capable automat
PCI DSS Requirement

10.1 Establish a process for linking all access to
system components (especially access done with
administrative privileges such as root) to each
individual user.
10.2 Implement automated audit trails for all system

components to reconstruct the following events:
10.2.1 All individual accesses to cardholder data
10.2.2 All actions taken by any individual with root

or administrative privileges
10.2.3 Access to all audit trails
10.2.4 Invalid logical access attempts
10.2.5 Use of identification and authentication

mechanisms
10.2.6 Initialization of the audit logs
10.2.7 Creation and deletion of system-level

objects
10.3 Record at least the following audit trail entries

for all system components for each event:
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,

synchronize all critical system clocks and times and
ensure that the following is implemented for
acquiring, distributing, and storing time.
Note: One example of time synchronization
technology is Network Time Protocol (NTP).
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 industryaccepted time sources.
10.5 Secure audit trails so they cannot be altered.
10.5.1 Limit viewing of audit trails to those with a

job-related need.
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 changedetection software on logs to ensure that existing
log data cannot be changed without generating
alerts (although new data being added
should not cause an alert).
10.6 Review logs for all system components at least

daily. Log reviews must include those servers that
perform security functions like intrusion-detection
system (IDS) and authentication, authorization, and
accounting protocol (AAA) servers (for example,
RADIUS).
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,

with a minimum of three months immediately
available for analysis (for example, online, archived,
or restorable from back-up).
tor all access to network resources and cardholder data
user activities are critical in preventing, detecting, or minimizing the impact of a data compromise. The presence of logs in
st challenging key controls to meet.
ement 10 at the time of IROC, representing a 13 percent increase from last years data set.
f tests in Requirement 10 at time of IROC, a five percent decrease from 2010.
o be 10.5.5: Use file-integrity monitoring or change-detection software on logs to ensure that existing log data cannot be ch
irement 10 are the failure or inability to invest in a capable automated tool (log aggregator) to monitor logs on a daily basi
Guidance
SANS
Top 20 Critical
Security Controls
It is critical to have a process or system that links

user access to system components accessed, and in
particular, for those users with administrative
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.
C17.2
Generating audit trails of suspect activities alerts the

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.
C14.1
C14.6
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.
C.14.3
Accounts with increased privileges, such as the

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.
C12.9
C12.10
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,
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.
NC
C14.3
Without knowing who was logged on at the time 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.
NC
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.
NC
Malicious software, such as malware, often 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.
C.14.3
By recording these details for the auditable events at

10.2, a potential compromise can be quickly
identified, and with sufficient detail to know who,
what, where, when, and how.
C14.1
NC
NC
NC
C14.3
NC
NC
Time synchronization technology is used to

synchronize clocks on multiple systems. When
properly deployed, this technology can synchronize
clocks on large numbers of systems to within a
fraction of a second of each other. Some problems
that can occur when clocks are not properly
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.
C.14.5
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.
C6.5
NC
C14.5
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.
C14.2.1
C14.7
Adequate protection of the audit logs includes 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 the internal network.
NC
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 the internal network.
C14.7
C14.2.1
C14.7
File-integrity monitoring systems check for changes

to critical files, and notify when such changes are
noted. For file-integrity monitoring purposes, an
entity usually monitors files that 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.
NC
Many breaches occur over days or months before

being detected. Checking logs daily minimizes the
amount of time and exposure of a potential breach.
The log- review process does not have to be manual.
Especially for those entities with a large number of
servers, consider use of log harvesting, parsing, and
alerting tools.
C14.4
C14.6
Retaining logs for at least a year allows for the fact

that it often takes a while to notice that a
compromise has occurred or is occurring, and allows
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.
NC
a data compromise. The presence of logs in all environments allows thorough tracking, alerting, and analysis when someth
s data set.
o ensure that existing log data cannot be changed without generating alerts. File- integrity monitoring can be extremely com
aggregator) to monitor logs on a daily basis, not maintaining security procedures to trigger a response to an exception rep
Testing Procedure
10.1 Verify through observation and interviewing the system administrator, that audit
trails are enabled and active for system components.
10.2 Through interviews, examination of audit logs, and examination of audit log
settings, perform the following:
10.2.1 Verify all individual access to cardholder data is logged.
10.2.2 Verify actions taken by any individual with root or administrative privileges are
logged.
10.2.3 Verify access to all audit trails is logged.
10.2.4 Verify invalid logical access attempts are logged.
10.2.5 Verify use of identification and authentication mechanisms is logged.
10.2.6 Verify initialization of audit logs is logged.
10.2.7 Verify creation and deletion of system level objects are logged.
10.3 Through interviews and observation, for each auditable event (from 10.2), perform
the following:
10.3.1 Verify user identification is included in log entries.
10.3.2 Verify type of event is included in log entries.
10.3.3 Verify date and time stamp is included in log entries.
10.3.4 Verify success or failure indication is included in log entries.
10.3.5 Verify origination of event is included in log entries.
10.3.6 Verify identity or name of affected data, system component, or resources is

included in log entries.
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:
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.
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.
10.4.3 Verify that the time servers accept time updates from specific, industryaccepted 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).
10.5 Interview system administrator and examine permissions to verify that audit trails
are secured so that they cannot be altered as follows:
10.5.1 Verify that only individuals who have a job-related need can view audit trail
files.
10.5.2 Verify that current audit trail files are protected from unauthorized
modifications via access control mechanisms, physical segregation, and/or network
segregation.
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.
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.
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.
10.6.a Obtain and examine security policies and procedures to verify that they include
procedures to review security logs at least daily and that follow-up to exceptions is
required.
10.6.b Through observation and interviews, verify that regular log reviews are
performed for all system components.
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.
erting, and analysis when something does go wrong. Determining the cause of a compromise is very difficult, if not impossi
monitoring can be extremely complex and expensive to implement.

r 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.
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.
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.
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.
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.
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.
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
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
Describe how audit logs were observed to include user identification.
dentify the responsible personnel interviewed who confirm that the type of event is
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
Describe how audit logs were observed to include the date and time.
Identify the responsible personnel interviewed who confirm that success or failure
I.indication is included in log entries.
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.
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.
ii. Describe how audit logs were observed to include the identity or name of affected
data,
Identify
the
time synchronization
system
component,
or resource.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
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
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
requiring
that:
Time signals
from external
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
confirm the above.
Describe how time synchronization processes were observed to verify the above.
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:
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 industryaccepted 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 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 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.
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.
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 externalfacing 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 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.
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
Describe the implemented procedures for:
i. Reviewing logs for all system components at least daily
ii. Following up exceptions
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
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.
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.
At least the last three months logs can be immediately restored for analysis.
ise is very difficult, if not impossible, without system activity logs.
al
Priority
A B C-VT C
In Place?
Severity
I
n
t
N
e
r
m
e
d
i
a
r
y
N
C
o
n
t
r
o
lN
###
###
###
###
###
###
###
###
###
###
###
###
###
###
###
###
###
###
###
###
###
###
###
###
###
###
###
###
###
###
###
###
###
33
Y
N
C
132
###
0 0
132
Proofs /
Documentation links
Remediation plan
Comments
Owner
Requirement 11: Regularly test security systems and processes.
Vulnerabilities are being discovered continually by malicious individuals and researchers, and being introduced b

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
Organizations continue to have difficulty meeting the sub-requirements regarding network vulnerability scannin
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 remediate
Time and resource constraints hindered some in our sample from being able to present four passing external a
53 percent of organizations perform external and internal penetration testing at least once a year and after any
PCI DSS Requirement
11.1 Test for the presence of wireless access points

and detect unauthorized wireless access points on a
quarterly basis.
Note: Methods that may be used in the process
include but are not limited to wireless network scans,
physical/logical inspections of system components
and infrastructure, network access control (NAC), or
wireless IDS/IPS. Whichever methods are used, they
must be sufficient to detect and identify any
unauthorized devices.
11.2 Run internal and external network vulnerability

scans at least quarterly and after any significant
change in the network (such as new system
component installations, changes in network
topology, firewall rule modifications, product
upgrades).
Note: It is not required that four passing quarterly
scans must be completed for initial PCI DSS
compliance if the assessor verifies 1) the most recent
scan result was a passing scan, 2) the entity has
documented policies and procedures requiring
quarterly scanning, and 3) vulnerabilities noted in the
scan results have been corrected as shown in a rescan. For subsequent years after the initial PCI DSS
review, four passing quarterly scans must have
occurred.
11.2.1 Perform quarterly internal vulnerability

scans.
11.2.2 Perform quarterly external vulnerability scans

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

any significant change.
Note: Scans conducted after changes may be
performed by internal staff.
11.3 Perform external and internal penetration

testing at least once a year and after any significant
infrastructure or application upgrade or modification
(such as an operating system upgrade, a subnetwork added to the environment, or a web server
added to the environment). These penetration tests
must include the following:
11.3.1 Network-layer penetration tests
11.3.2 Application-layer penetration tests
11.4 Use intrusion-detection systems, and/or

intrusion-prevention systems to monitor all traffic at
the perimeter of the cardholder data environment as
well as at critical points inside of the cardholder data
environment, and alert personnel to suspected
compromises.
Keep all intrusion-detection and prevention engines,
baselines, and signatures up-to-date.
11.5 Deploy file-integrity monitoring tools to alert

personnel to unauthorized modification of critical
system files, configuration files, or content files; and
configure the software to perform critical file
comparisons at least weekly.
Note: For file-integrity monitoring purposes, critical
files are usually those that do not regularly change,
but the modification of which could indicate a system
compromise or risk of compromise. File-integrity
monitoring products usually come pre-configured
with critical files for the related operating 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).
ecurity systems and processes.
ally by malicious individuals and researchers, and being introduced by new software. System components, processes, and c
equirement 11 at the time of IROC
CI DSS standard
of tests in Requirement 11 at time of IROC, a five percent drop, from 2010.
eting the sub-requirements regarding network vulnerability scanning (11.2), penetration testing (11.3), and file integrity m
requirements of 11.2.
uarterly) combined with the expectation that findings are remediated and re- tested.
e in our sample from being able to present four passing external and internal scans.
l and internal penetration testing at least once a year and after any significant infrastructure or application upgrade or mod
Guidance
Implementation and/or exploitation of wireless

technology within a network is one of the most
common paths for malicious users to gain access to
the network and cardholder data. If a wireless device
or network is installed without a companys
knowledge, it can allow an attacker to easily and
invisibly enter the network.
Unauthorized wireless devices may be hidden within
or attached to a computer or other system
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
SANS
Top 20 Critical
Security
Controls
C1.2
C13.9
C7.1
C7.3
C7.9
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
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.
A vulnerability scan is an automated tool run against

external and internal network devices and servers,
designed to expose potential vulnerabilities in
networks that could be found and exploited by
malicious individuals. Once these weaknesses are
identified, the entity corrects them, and repeats the
scan to verify the vulnerabilities have been corrected.
C1.2
C13.9
C6.4
C4.1
C11.2
At the time of an entitys initial PCI DSS assessment,

it is possible that four quarterly scans have not yet
been performed. If the most recent scan result meets
the criteria for a passing scan, and there are policies
and procedures in place for future quarterly scans,
the intent of this requirement is met. It is not
necessary to delay an in place assessment for this
requirement due to a lack of four scans if these
conditions are satisfied.
An established process for identifying vulnerabilities

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.
C4.1
C11.2
vulnerability scanning.
As external networks are at greater risk of compromise, quarterly

external vulnerability scanning must be perfor
C4.1
Scanning an environment after any significant

changes are made ensures that changes were
completed appropriately such that the security of the
environment was not compromised as a result 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.
C6.4
C4.1
C11.2
The intent of a penetration test is to simulate a real

world attack situation with a goal of identifying how
far an attacker would be able to penetrate into an
environment. This allows an entity to gain a better
understanding of their potential exposure and
develop a strategy to defend against attacks.
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.
C13.9
C20.1
C20.1
C20.4
Intrusion detection and/or intrusion prevention

systems (IDS/IPS) compare the traffic coming into the
network with known signatures and/or behaviors of
thousands of compromise types (hacker tools, Trojans
and other malware), and send alerts and/or stop the
attempt as it happens. Without a proactive approach
to unauthorized 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.
C13.2
C13.3
C5.1.2
File-integrity monitoring (FIM) tools check for changes

to critical files, and notify when such changes are
detected. There are both off-the-shelf and open
source tools available for file integrity monitoring. If
not implemented properly and the output of the FIM
monitored, a malicious individual could alter
configuration file contents, operating system
programs, or application executables. Such
unauthorized changes, if undetected, could render
existing security controls ineffective and/or result in
cardholder data being stolen with no perceptible
impact to normal processing.
C3.9
oftware. System components, processes, and custom software should be tested frequently to ensure security controls conti
penetration testing (11.3), and file integrity monitoring (11.5).
tested.
al scans.
nt infrastructure or application upgrade or modification (Requirement 11.3).
Testing Procedure
11.1.a Verify that the entity has a documented process to detect and identify wireless
access points on a quarterly basis.
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.
11.2 Verify that internal and external vulnerability scans are performed as follows:
11.2.1.a Review the scan reports and verify that four quarterly internal scans
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).
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.
11.2.3.a Inspect change control documentation and scan reports to verify that system
components subject to any significant change were scanned.
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).
11.3.a Obtain and examine the results from the most recent penetration test to verify
that penetration testing is performed at least annually and after any significant changes
to the environment.
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).
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.
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.
11.4.a Verify the use of intrusion-detection systems and/or intrusion-prevention systems

and that all traffic at the perimeter of the cardholder data environment as well 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.
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.
to ensure security controls continue to reflect a changing environment

Identify the document that defines the methods and processes to:
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 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 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,
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
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
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
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
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
Describe how organizational independence of the tester was observed to exist.
Identify the external scan report documents that verify four quarterly external scans
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 and
no
automatic failures).
Describe how the external scan reports verify that the scans were completed by a PCI
SSC- Approved Scanning Vendor (ASV).
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.
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
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.
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:
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
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.
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.
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.
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
Maintaining IDS/IPS devices
Updating IDS/IPS devices
Describe the file-integrity monitoring (FIM) tools deployed.

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:

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.
Priotity
A B C-VT
###
In Place?
Severity
###
###
###
###
###
###
###
###
###
###
###
###
###
###
###
###
###
###
###
###
###
###
###
###
25
Y
N
C
64
64
###
0 0
15
Proofs /
Documentation links
Remediation plan
Estimated date for

completion
Comments
Owner
Requirement 12: Maintain a policy that addresses information security for all perso
A strong security policy sets the security tone for the whole entity and informs personnel what is expected of th

39 percent of organizations fully met Requirement 12 at the time of IROC. This is a five percent drop in comparis
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
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 mainta
Lack of interpretation of sub-control 12.8.4 (Maintain a program to monitor service providers PCI DSS complianc
PCI DSS Requirement
12.1 Establish, publish, maintain, and disseminate a

security policy that accomplishes the following:
12.1.1 Addresses all PCI DSS requirements.

12.1.2 Includes an annual process that identifies
threats, and vulnerabilities, and results in a formal
risk assessment.
(Examples of risk assessment methodologies
include but are not limited to OCTAVE, ISO 27005
and NIST SP 800-30.)
12.1.3 Includes a review at least annually and

updates when the environment changes.
12.2 Develop daily operational security procedures

that are consistent with requirements in this
specification (for example, user account maintenance
procedures, and log review procedures).
12.3 Develop usage policies for critical technologies

(for example, remote- access technologies, wireless
technologies, removable electronic media, laptops,
tablets, personal data/digital assistants (PDAs), e-mail
usage and Internet usage) and define proper use of
these technologies. Ensure these usage policies
require the following:
12.3.1 Explicit approval by authorized parties
12.3.2 Authentication for use of the technology
12.3.3 A list of all such devices and personnel with

access
12.3.4 Labeling of devices to determine owner,

contact information and purpose
12.3.5 Acceptable uses of the technology
12.3.6 Acceptable network locations for the

technologies
12.3.7 List of company-approved products
12.3.8 Automatic disconnect of sessions for

remote-access technologies after a specific period
of inactivity
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

via remote-access technologies, prohibit copy,
move, and storage of cardholder data onto local
hard drives and removable electronic media, unless
explicitly authorized for a defined business need.
12.4 Ensure that the security policy and procedures

clearly define information security responsibilities for
all personnel.
12.5 Assign to an individual or team the following

information security management responsibilities:
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

program to make all personnel aware of the
importance of cardholder data security.
12.6.1 Educate personnel upon hire and at least

annually.
Note: Methods can vary depending on the role of
the personnel and their level of access to the
cardholder data.
12.6.1 Educate personnel upon hire and at least

annually.
Note: Methods can vary depending on the role of
the personnel and their level of access to the
cardholder data.
12.6.2 Require personnel to acknowledge at least

annually that they have read and understood the
security policy and procedures.
12.7 Screen potential personnel prior to hire to

minimize the risk of attacks from internal sources.
(Examples of background checks include previous
employment history, criminal record, credit history,
and reference checks.)
Note: For those potential personnel to be hired for
certain positions such as store cashiers who only
have access to one card number at a time when
facilitating a transaction, this requirement is a
recommendation only.
12.8 If cardholder data is shared with service

providers, maintain and implement policies and
procedures to manage service providers, to include
the following:
12.8.1 Maintain a list of service providers.
12.8.2 Maintain a written agreement that includes

an acknowledgement that the service providers are
responsible for the security of cardholder data the
service providers possess.
12.8.3 Ensure there is an established process for
engaging service providers including proper due
diligence prior to engagement.
12.8.4 Maintain a program to monitor service

providers PCI DSS compliance status at least
annually.
12.9 Implement an incident response plan. Be

prepared to respond immediately to a system breach.
12.9.1 Create the incident response plan to be

implemented in the event of system breach. Ensure
the plan addresses the following, at a minimum:
- 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.
12.9.3 Designate specific personnel to be available

on a 24/7 basis to respond to alerts.
12.9.4 Provide appropriate training to staff with

security breach response responsibilities.
12.9.5 Include alerts from intrusion- detection,

intrusion-prevention, and file- integrity monitoring
systems.
12.9.6 Develop a process to modify and evolve the

incident response plan according to lessons learned
and to incorporate industry developments.
cy that addresses information security for all personnel.
ne for the whole entity and informs personnel what is expected of them. All personnel should be aware of the sensitivity of
ement 12 at the time of IROC. This is a five percent drop in comparison to the 2010 report findings.
of tests in Requirement 12 at the time of IROC.
equisite work; thus they lack critical content, and fail to identify the information assets that must be protected.
ment 12 at the time of the IROC is 12.4
er Requirement 12 are 12.8.2 and 12.8.4.
nowledgement from service providers of their commitment to maintain proper security of cardholder data obtained from cli
Maintain a program to monitor service providers PCI DSS compliance status) contributed towards its low compliance rating
Guidance
A company's information security policy creates the

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.
SANS
Top 20 Critical
Security Controls
NC
NA
A risk assessment enables an organization to identify
threats and the associated vulnerabilities which have
the potential to negatively impact their business.
Resources can then be effectively allocated to
implement controls that reduce the likelihood 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,
NC
Security threats and protection methods evolve

rapidly throughout the year. Without updating the
security policy to reflect relevant changes, new
protection measures to fight against these threats
are not addressed.
NC
Daily operational security procedures act as desk

instructions for personnel to use in their day-to-day
system administrative and maintenance activities.
Undocumented operational security procedures will
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.
C16.9
Personnel usage policies can either prohibit use of

certain devices and other technologies if that is
company policy, or provide guidance for personnel as
to correct usage and implementation. If usage
policies are not in place, personnel may use the
technologies in violation of company policy, thereby
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.
NC
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.
NC
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.
NC
Malicious individuals may breach physical security

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 nonapproved 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.
NC
device labeling allows for quick identification of nonapproved 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.
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 cardholder
data.
NC
NC
NC
NC
Remote-access technologies are frequent "back

doors" to critical resources and cardholder data. By
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.
NC
NC
To ensure all personnel are aware of their

responsibilities to not store or copy cardholder data
onto their local personal computer or other media,
your policy should clearly prohibit such activities
except for personnel that have been explicitly
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.
NC
Without clearly defined security roles and

responsibilities assigned, there could be inconsistent
interaction with the security group, leading to
unsecured implementation of technologies or use of
outdated or unsecured technologies.
NC
Each person or team with responsibilities for

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.
NC
NC
NC
C18.1
NC
NC
If personnel are not educated about their security

responsibilities, security safeguards and processes
that have been implemented may become ineffective
through errors or intentional actions.
C9.1
C9.2
If the security awareness program does not include

periodic refresher sessions, key security processes
and procedures may be forgotten or bypassed,
resulting in exposed critical resources and cardholder
data. The focus and depth of the initial 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
NC
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 computerbased training session, while ongoing periodic
updates may be delivered via e-mails, posters,
newsletters, etc.
If the security awareness program does not include

periodic refresher sessions, key security processes
and procedures may be forgotten or bypassed,
resulting in exposed critical resources and cardholder
data. The focus and depth of the initial 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 computerbased training session, while ongoing periodic
updates may be delivered via e-mails, posters,
newsletters, etc.
Requiring an acknowledgement by personnel in
writing or electronically helps ensure that they have
read and understood the security policies/procedures,
and that they have made and will continue to make a
commitment to comply with these policies.
NC
Performing thorough background investigations prior

to hiring potential personnel who are expected to be
given access to cardholder data reduces the risk of
unauthorized use of PANs and other cardholder data
by individuals with questionable or criminal
backgrounds. It is expected that a company would
have a policy and process for background checks,
including their own decision process for which
background check results would have an impact on
their hiring decisions (and what that impact would
be).
NC
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.
If a merchant or service provider shares cardholder

data with a service provider, then certain
requirements apply to ensure continued protection of
this data will be enforced by such service providers.
Keeping track of all service providers identifies
where potential risk extends to outside of the
organization.
NC
The acknowledgement of the service providers

evidences their commitment to maintaining proper
security of cardholder data that it obtains from its
clients, and thus holds them accountable.
C12.13
The process ensures that any engagement of a

service provider is thoroughly vetted internally by
an organization, which should include a risk
analysis prior to establishing a formal relationship
with the service provider.
NC
Knowing your service providers PCI DSS

compliance status provides assurance that they
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.
NA
Without a thorough security incident response plan

that is properly disseminated, read, and understood
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.
C18.1
The incident response plan should be thorough and

contain all the key elements to allow your company
to respond effectively in the event of a breach that
could impact cardholder data.
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.
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.
C18.2
C18.4
C18.2
NC
C18.5
C18.6
These monitoring systems are designed to focus on

potential risk to data, are critical in taking quick
action to prevent a breach, and must be included in
the incident-response processes.
NC
Incorporating lessons learned into the incident

response plan after an incident helps keep the plan
current and able to react to emerging threats and
security trends.
NC
nnel should be aware of the sensitivity of data and their responsibilities for protecting it. For the purposes of Requirement 1
10 report findings.
ssets that must be protected.
curity of cardholder data obtained from clientsand accepting accountability for the protection of that data remains a tax
ntributed towards its low compliance rating.
Testing Procedure
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).
12.1.1 Verify that the policy addresses all PCI DSS requirements.
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.
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.
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.
12.3 Obtain and examine the usage policies for critical technologies and perform the
following:
12.3.1 Verify that the usage policies require explicit approval from authorized parties to
use the technologies.
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).
12.3.3 Verify that the usage policies require a list of all devices and personnel
authorized to use the devices.
12.3.4 Verify that the usage policies require labeling of devices with information that
can be correlated to owner, contact information and purpose.
12.3.5 Verify that the usage policies require acceptable uses for the technology.
12.3.6 Verify that the usage policies require acceptable network locations for the
technology.
12.3.7 Verify that the usage policies require a list of company- approved products.
12.3.8 Verify that the usage policies require automatic disconnect of sessions for
remote-access technologies after a specific period of inactivity.
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.
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.
12.4 Verify that information security policies clearly define information security
responsibilities for all personnel.
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:
12.5.1 Verify that responsibility for creating and distributing security policies and
procedures is formally assigned.
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.
12.5.3 Verify that responsibility for creating and distributing security incident
response and escalation procedures is formally assigned.
12.5.4 Verify that responsibility for administering user account and authentication
management is formally assigned.
12.5.5 Verify that responsibility for monitoring and controlling all access to data is
formally assigned.
12.6.a Verify the existence of a formal security awareness program for all personnel.
12.6.b Obtain and examine security awareness program procedures and documentation
and perform the following:
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.
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.
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:
12.8.1 Verify that a list of service providers is maintained.
12.8.2 Verify that the written agreement includes an acknowledgement by the service
providers of their responsibility for securing cardholder data.
12.8.3 Verify that policies and procedures are documented and were followed
including proper due diligence prior to engaging any service provider.
12.8.4 Verify that the entity maintains a program to monitor its service providers PCI
DSS compliance status at least annually.
12.9 Obtain and examine the Incident Response Plan and related procedures and
perform the following:
12.9.1.a Verify that the incident response plan includes:

- 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.
12.9.2 Verify that the plan is tested at least annually.
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.
12.9.4 Verify through observation and review of policies that staff with responsibilities
for security breach response are periodically trained.
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.
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.
or the purposes of Requirement 12, personnel refers to full-time and part-time employees, temporary employees, contra
ction of that data remains a taxing compliance issue

(For In-place requirements)
Identify the documented information security policy.

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.
Identify the document that defines the annual risk assessment process. Describe
how the documented process:
i. Identifies threats and vulnerabilities
ii. Results in formal risk assessment
Describe how observed risk assessment results confirm that:

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:
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
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
Identify critical technologies in use.

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:
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:
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

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

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.
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. 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 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
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
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
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:

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

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
Creating and distributing security incident response and escalation procedures
Describe how the above assigned responsibilities were observed to be implemented.
Identify the document that formally assigns responsibility for administering user
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:
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
personnel. Describe how a formal security awareness program was observed to be
implemented for all
personnel.
Identify the document defining the methods of communicating awareness and

educating personnel.
Identify the methods observed for communicating awareness and educating
personnel.
Identify the document requiring that all personnel attend awareness training:
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:

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:

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.
Identify all service providers with whom cardholder data is shared.

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
maintained (kept up-to-date).
For each service provider with whom cardholder data is shared:
Identify the document that includes service provider acknowledgment of their
responsibility for securing cardholder data.
Identify the document that defines procedures for proper due diligence prior to
engaging any service provider.
Describe how the procedures for proper due diligence were observed to be
implemented.

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.
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
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 and
procedures were followed.
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
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:
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.
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.
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
Describe how the above processes were observed to be implemented.
es, temporary employees, contractors and consultants who are resident on the entitys site or otherwise have access to t
Priority
###
C-VT
In Place?
N
6
###
###
I
n
t
e
N
r
m
e
d
i
a
r
N
y
N
C
o
n
t
r
o
l
Severity
6
1
N
1
###
1
N
###
###
N
6
###
N
6
###
N
6
###
###
###
N
6
###
N
6
###
N
6
###
N
6
###
N
6
###
###
N
6
###
N
6
###
N
6
###
N
6
###
###
N
###
4
N
6
###
N
6
###
N
6
###
1
N
###
###
1
N
###
N
6
###
N
6
###
###1
2
N
###1
N
###1
2
N
###1
2
N
###1
N
###
###
N
###
4
N
###
N
###
###
4
N
###
N
###
4
N
216
###5
14
14
18
44
Y
N
C
216
otherwise have access to the cardholder data environment.
Proofs /
Documentation links
Remediation plan
Comments
Owner
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

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

PCI Compliance Dashboard - v10

Uploaded by

Copyright:

Available Formats

Table of content

Introduction and News

PCI Compliance Dashboard VER

Please feel free to use this compliance dashboard to sustain your PC

Comments, feedbacks and suggestions are welcome. Send them to Di

Some sheets are protected to prevent accidental changes. You may un

Return to Table of content

PCI Compliance Dashboard VERSIO

Comments, feedbacks and suggestions are welcome. Send them to Didier Go

How to start using this dashboard?

1.Define your scope (Scope sheet)

Include Prioritized Approach milestones as defined by PCIco

WHAT'S NEW IN THIS VERSION

Compliance Dashboard home page

PCI 30 Seconds Newsletters

Seconds newsletter #1 - PCI what are you talking about?

ain your PCI compliance journey, to support the discussion

You may unprotect them at any time. No password

roof, Stage,remediation, estimated, Comments and select the

ated compensating controls sheet

November 2011 Didier Godart

at Impact on Quarterly Scans?

comply with PCI DSS

Join the community!

Join the community!

About Fuze Network

Join the community!

About Indelible data

Join the community!

Join the community!

Join the community!

Return to Table of content

Card Verification Code or

Dynamic Packet Filtering

File Integrity Monitoring

Remote Lab Environment

Virtual Machine Monitor

Wireless Access Point

Something you know, such as a password or passphrase

Also known as Card Validation Code or Value, or Card Security Code.

Identifier for a particular user or application.

Define your Card Data Environment (CDE)

older data or sensitive authentication data and those

Last Scan date

last Scan date

Scan report location

Last scan report

Return to Table of content

TYPE HERE YOUR COMPANY NAME

You MUST select in cell B3 your Merchant type (A, B, C, C-

% compliance # of Requirements # in Place # not in Place

(See the merchant types)

PCI DSS Req

Global network diagram

Global network diagram (Confidential)

Lightened network diagram

Includes development/test and production environments 6.4

Includes a list of secure and unsecure services,

System Configuration/hardening for

Includes a list of common security parameter settings

Policies, Procedures and standards documentation

Role and responsibilities for

PCI DSS Req