Table of content DSS V3 PCI DashBoard

Introduction and News

Glossary
Executive summary
Chart - % Compliance
Chart - Severity
Chart Priority
PCI Team
Scope definition
Required Documentation for audit
Crypto Keys inventory
Merchant types
Compensating Controls definition
Not Applicable - Rationals
Vulnerability scans form
Penetration tests form
Training & Knownledge Evidences
Requirement 1
Requirement 2
Requirement 3
Requirement 4
Requirement 5
Requirement 6
Requirement 7
Requirement 8
Requirement 9
Requirement 10
Requirement 11
Requirement 12
SANS-PCI Matrix
 Return to Table of content

PCI Compliance Dashboard VERSION 1

Feel free to use this “compliance dashboard” to sustain your PCI com
and acquiring banks. This dashboard is fully aligned with PCI DSS V3.
Appreciation, feedback and suggestions are WELCOME. Send them to
If you like this tool don't hesitate to let the community know about it

Enjoy!

Didier Godart

Author, Owner and Contact

This dashboard is sponsored by:

Version history
What's new in this version
PCI 30 seconds newsletters
Table of content

Executive Summary
How to use this dashboard?
 1.Select your Merchant type (Excutive Summary sheet)
2.Define your scope (Scope sheet)
3.Define your PCI Team (PCI team sheet)
4.For each requirement sheet:
5.Select the appropriate answer (In place, not in place, compensating control) and fill appropriate cells
6. Use the compensating controls page to document and justify them
7. Use the NA sheet to document and justify the NA requirements
8. Use the navigation links on the top of each sheet to navigate through the various sections and access
9.Control your compliance status through the Excutive summary board (Executive sheet) and associated
10.Use the vulnerability scans sheet to maintain a record of your scans
11.Use the penetration testing form to maintain record of your pen tests
12.Use the documentation sheet to get a detailed list on the required documentation and maintain you
13.Use the Crypto key sheet to make an inventory of your cryptographic keys
14.Use the Training and knowledge form to maintain records and evidence of trainings and knowledges

Version History
V0.1 Requirements and testing procedures
V0.2 Add merchant type for each requirements

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

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

V0.5 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.
V0.6 All sheets are protected to avoid accidental deletion. (No password)

Instructions:
1.Select your merchant type within the sheet "Executive summary"
2.Select the appropriate answer for each requirements (Column L: Y/N/C)
3. Use the compensating controls sheet to describe your controls whenever used.
4.View your compliance progress through the "Executive summary" and " Charts"
sheets.
V0.7 1.Navigation: Add Table of content and navigation links
2.Rename sheet "PCI Actor" to "PCI Team"
3.Associate column "Owner" in requirements sheets to the name of individuals
listed within sheet "PCI Team". A list box allows the selection of a name from this
sheet.
4. Add Documentation sheet listing all your documentation related to PCI.
5.Add row "SANS Top 20 Critical Security Controls" - Matching subcontrols for each
PCI requirement wherever possible.
6.Add Sheet " SANS-PCI" Listing all SANS Top 20 Critical Security Controls and Sub-
controls together with PCI requirements partially or fully matching the sub-
controls. Also % of match for each SANS Controls. For more details on the
Matching matrix read the associated Technical paper "PCI-SANS Top 20 Critical
Security Controls"
7.Add "Scope" sheet allowing you to define the Card Data Environment (CDE)
8. Add two buttons within the Executive Summary Sheet allowing you to
hide/unhide non applicable requirements associated to the selected Merchant
Type (THANKS to Tony). Macros do not work on MAC.
9. Dissociate form chart sheet in two specific chart sheets (% of compliance and
Severity)

V0.8 Adapt SANS numerotation to new version (Version 3.1 October 3, 2011)

V0.9 Update the documentation sheet with the list of (required or optional) technical
and non-technical documents together with their associated PCI DSS requirements.

V10 Update Scope sheet with Criticality, Patch level, Scan date and Scan report location
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)

V11 Integration PCI DSS V3

Updated list of documents (Contact me at d@dgozone.com) to obtain it.
Add a sheet "training& knowledge evidences"
Update list of PCI newsletters

WHAT'S NEW IN THIS VERSION

V12 Integration Testing procedure on New ROC
Alignment with SAQ V3 (A,B,C,C-VT,D)
Integration of the new merchant types: B-IP and S
Integration of major observations from Verizon 2014 PCI Compliance Report (see
individual requirement pages)
Review Severity rating = ABS (Priority - 7)
Add possible answer (Not Tested and Not Applicable)
Adapt Executive summary dashboard
Add Column Max Severity versus severity
V14 Integration SAQ A-EP
Integration SAQ P2EP
Add Section Progress based on Priority Approach (See executive summary)
Add New Chart "Progress by Priority"
Add New sheet -list of requirements marked as NA + rationals
Add Various navigation links
Add the selected merchant type on each requirement sheet.

Compliance Dashboard home page

PCI 30 Seconds Newsletters

PCI 30 Seconds newsletter #1 - PCI what are you talking about?
PCI 30 seconds newsletter #2 - Payment processing terminology and workflow
PCI 30 seconds newsletter #3 - Distributing roles
PCI 30 seconds newsletter #4 - Merchant levels
PCI 30 seconds newsletter #5 - What is your type?
PCI 30 seconds newsletter #6 - PCI DSS in a nutshel
PCI 30 seconds newsletter #7 - Define the scope of an assessment
PCI 30 seconds newsletter #8 - certification program, striving for quality
PCI 30 seconds newsletter #9 - The validation toolbox
PCI 30 seconds newsletter #10 - Prioritized Approach
PCI 30 seconds newsletter #11 - Tokenization
PCI 30 seconds newsletter #12 - the gap analysis process
PCI 30 seconds newsletter #3 - Compensating controls, magic trick or mirage?
PCI 30 seconds newsletter #14 - The world is not perfect!
PCI 30 seconds newsletter #15 - Nice Look!
PCI 30 seconds newsletter #16 – Is your organization behaving like a fashion victim or a clown?
PCI 30 seconds newsletter #17 – Why are my scan reports so thick? - Impact of "potential" vulnerabilities
PCI 30 seconds newsletter #18 – What to do if compromised?
PCI 30 seconds newsletter #19 - Your PCI Logbook. What's required in terms of Log management?
PCI 30 seconds newsletter #20 – PCI DSS and SANS Top 20 Critical Security Controls: The Sumo match.
PCI 30 seconds newsletter #21 - "Qualified" internal scanning staff using "appropriate" scanning tools - What doe
PCI 30 seconds newsletter #22 - Don't get lost in translation with Executives. Get them listening.
PCI 30 seconds newsletter # 23 – Introduction to Risk Assessment
PCI 30 second newsletter #24 - PCIco strengthens the scoping rules
PCI 30 seconds newsletter #25 - A New Standard is Born.
PCI 30 seconds newsletter #26 - PCIP is it worth it?
PCI 30 seconds newsletter #27 -Static versus Active Protection Systems. What Impact on Quarterly Scans?
PCI 30 Seconds newsletter #28 - The PCI Library - What docs are required for compliance?
PCI 30 seconds newsletter #29 - Do all PCI DSS requirements apply?
PCI 30 seconds newsletter #30 - Trainings your organization must deliver to comply with PCI DSS
PCI 30 Seconds Newsletter #31 - PCI DSS Crypto-framework
PCI 30 seconds newsletter #32 - Money for nothing
PCI 30 seconds newsletter #33 - Key take-away from the PCI Community meeting 2013
PCI 30 seconds newsletter #34 - PCI DSS Version 3 Changes and Impact - Should You Care?
PCI 30 seconds newsletter #35 - Patching within the context of PCI - All you need to know

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
rd VERSION 14 - PCI DSS V3
” to sustain your PCI compliance journey, to support the discussion with your inter
aligned with PCI DSS V3.
WELCOME. Send them to Didier Godart (d@dgozone.com).
ommunity know about it.

Didier GodartDgozone (www.dgozone.com)+32 498787744SkypeID Dgozon

RAPID7

Start Here
ng control) and fill appropriate cells (Proof, Stage,remediation, estimated, Comments and select the owner responsible for
em

ough the various sections and access the executive summary

oard (Executive sheet) and associated charts (% of compliance and Severity)
cans
n tests
red documentation and maintain your PCI library (Contact d@dgozone.com to get this supplement material).
raphic keys
evidence of trainings and knowledges required by DSS V3

Contributors

Jan-11 Peter Hill

Feb 2011 Didier Godart
Risk Product Manager Rapid7
+32 498787744
SkypeID Dgozone
didier_godart@rapid7.com

August 2011 Didier Godart

Risk Product Manager Rapid7
+32 498787744
SkypeID Dgozone
didier_godart@rapid7.com

October 2011 Didier Godart

Risk Product Manager Rapid7
+32 498787744
SkypeID Dgozone
didier_godart@rapid7.com

November 2011 Didier Godart

Risk Product Manager Rapid7
+32 498787744
SkypeID Dgozone
didier_godart@rapid7.com
December 2011 Didier Godart
Risk Product Manager Rapid7
+32 498787744
SkypeID Dgozone
didier_godart@rapid7.com

Swathy Anand
Vice President - Project Management
Fuze Network
swathyanand@gmail.com

May 2012 Didier Godart

Risk Product Manager Rapid7
+32 498787744
SkypeID Dgozone
didier_godart@rapid7.com

Tony Wilson
Managing Director
Indelible Data (a division of Indelible Designs
Limited)
tony@indelible-data.co.uk

July 2012 "Didier Godart

Risk Product Manager Rapid7
+32 498787744
SkypeID Dgozone
April 2013 "Didier Godart
Risk Product Manager Rapid7
+32 498787744
SkypeID Dgozone
June 2013 "Didier Godart
Risk Product Manager Rapid7
Founder Dgozone (www.dgozone.com)
+32 498787744
SkypeID Dgozone
d@dgozone.com

"
Dec 2013 "Didier Godart
Founder Dgozone (www.dgozone.com)
+32 498787744
SkypeID Dgozone
d@dgozone.com
 March 2014 "Didier Godart
Founder Dgozone (www.dgozone.com)
+32 498787744
SkypeID Dgozone
d@dgozone.com

April 2014 Didier Godart

Founder Dgozone (www.dgozone.com)
+32 498787744
SkypeID Dgozone
d@dgozone.com
http://be.linkedin.com/in/didiergodart

The complete list of newsletters is now online

ion victim or a clown?

pact of "potential" vulnerabilities

rms of Log management?

ty Controls: The Sumo match.
"appropriate" scanning tools - What does that mean?
ves. Get them listening.
What Impact on Quarterly Scans?
d for compliance?

to comply with PCI DSS

meeting 2013
Should You Care?
ou need to know

external scans?
DSS V3
, to support the discussion with your internal team, QSA

(d@dgozone.com).

About Didier
on, estimated, Comments and select the owner responsible for actions)

y
e and Severity)

@dgozone.com to get this supplement material).

About Swathy About Fuze Network

About Tony About Indelible data

 Contact

Contributors:

Jim Seaman
Principle Security Consultant
MSc, CCP, CISM, CRISC, QSA, A.Inst.IISP
Randomstorm.com
jim.seaman@randomstorm.com
--------
Paul McMillan | Consulting Manager
PCI QSA
Sysnet Global Solutions
paul.mcmillan@sysnetgs.com

letters is now online

Return to Table of content
AAA Acronym for “authentication, authorization, and accounting.” Protocol for authenticating a user based on their
verifiable identity, authorizing a user based on their user rights, and accounting for a user’s consumption of
network resources.

Access Control Mechanisms that limit availability of information or information-processing resources only to authorized persons
or applications.
Account Data Account data consists of cardholder data plus sensitive authentication data. See Cardholder Data and Sensitive
Authentication Data
Account Number See Primary Account Number (PAN).
Acquirer Also referred to as “acquiring bank” or “acquiring financial institution.” Entity that initiates and maintains
relationships with merchants for the acceptance of payment cards.
Adware Type of malicious software that, when installed, forces a computer to automatically display or download
advertisements.
AES Abbreviation for “Advanced Encryption Standard.” Block cipher used in symmetric key cryptography adopted by
NIST in November 2001 as U.S. FIPS PUB 197 (or “FIPS 197”).
ANSI Acronym for “American National Standards Institute.” Private, non-profit organization that administers and
coordinates the U.S. voluntary standardization and conformity assessment system.
Anti-Virus Program or software capable of detecting, removing, and protecting against various forms of malicious software
(also called “malware”) including viruses, worms, Trojans or Trojan horses, spyware, adware, and rootkits.

Application Includes all purchased and custom software programs or groups of programs, including both internal and external
(for example, web) applications.
Audit Log Also referred to as “audit trail.” Chronological record of system activities. Provides an independently verifiable
trail sufficient to permit reconstruction, review, and examination of sequence of environments and activities
surrounding or leading to operation, procedure, or event in a transaction from inception to final results.

Audit Trail See Audit Log.

ASV Acronym for “Approved Scanning Vendor.” Company approved by the PCI
SSC to conduct external vulnerability scanning services.
Authentication Process of verifying identity of an individual, device, or process. Authentication typically occurs through the use of
one or more authentication factors such as:
􏰀􏰀􏰀
Something you know, such as a password or passphrase
Something you have, such as a token device or smart card
Something you are, such as a biometric

Authentication Credentials Combination of the user ID or account ID plus the authentication factor(s) used to authenticate an individual,
device, or process,
Authorization Granting of access or other rights to a user, program, or process. For a network, authorization defines what an
individual or program can do after successful authentication.

For the purposes of a payment card transaction authorization occurs when a merchant receives transaction
approval after the acquirer validates the transaction with the issuer/processor.

B
Backup Duplicate copy of data made for archiving purposes or for protecting against damage or loss.
Bluetooth Wireless protocol using short-range communications technology to facilitate transmission of data over short
distances.

C
Cardholder Non-consumer or consumer customer to whom a payment card is issued to or any individual authorized to use
the payment card.
Cardholder Data At a minimum, cardholder data consists of the full PAN. Cardholder data may also appear in the form of the full
PAN plus any of the following: cardholder name, expiration date and/or service code
See Sensitive Authentication Data for additional data elements that may be transmitted or processed (but not
stored) as part of a payment transaction.

Cardholder Data The people, processes and technology that store, process or transmit cardholder data or sensitive authentication
Environment data, including any connected system components.
Card Verification Code or Also known as Card Validation Code or Value, or Card Security Code.
Value Refers to either: (1) magnetic-stripe data, or (2) printed security features.
(1) Data element on a card's magnetic stripe that uses secure cryptographic process to protect data integrity on
the stripe, and reveals any alteration or counterfeiting. Referred to as CAV, CVC, CVV, or CSC depending on
payment card brand. The following list provides the terms for each card brand:
􏰀 CAV – Card Authentication Value (JCB payment cards)
􏰀 CVC – Card Validation Code (MasterCard payment cards)
􏰀 CVV – Card Verification Value (Visa and Discover payment cards)
􏰀 CSC – Card Security Code (American Express)
(2) For Discover, JCB, MasterCard, and Visa payment cards, the second type of card verification value or code is
the rightmost three-digit value printed in the signature panel area on the back of the card. For American Express
payment cards, the code is a four-digit unembossed number printed above the PAN on the face of the payment
cards. The code is uniquely associated with each individual piece of plastic and ties the PAN to the plastic. The
following list provides the terms for each card brand:
􏰀 CID – Card Identification Number (American Express and Discover payment cards)
􏰀 CAV2 – Card Authentication Value 2 (JCB payment cards)
􏰀 CVC2 – Card Validation Code 2 (MasterCard payment cards)
􏰀 CVV2 – Card Verification Value 2 (Visa payment cards)

CERT Acronym for Carnegie Mellon University's “Computer Emergency Response Team.” The CERT Program develops
and promotes the use of appropriate technology and systems management practices to resist attacks on
networked systems, to limit damage, and to ensure continuity of critical services.

CIS Acronym for “Center for Internet Security.” Non-profit enterprise with mission to help organizations reduce the
risk of business and e-commerce disruptions resulting from inadequate technical security controls.

Column-Level Database Technique or technology (either software or hardware) for encrypting contents of a specific column in a database
Encryption versus the full contents of the entire database. Alternatively, see Disk Encryption or File-Level Encryption.
Compensating Controls Compensating controls may be considered when an entity cannot meet a requirement explicitly as stated, due to
legitimate technical or documented business constraints, but has sufficiently mitigated the risk associated with
the requirement through implementation of other controls. Compensating controls must:
(1) Meet the intent and rigor of the original PCI DSS requirement;
(2) Provide a similar level of defense as the original PCI DSS requirement;
(3) Be “above and beyond” other PCI DSS requirements (not simply in compliance with other PCI DSS
requirements); and
(4) Be commensurate with the additional risk imposed by not adhering to the PCI DSS requirement.
See “Compensating Controls” Appendices B and C in PCI DSS Requirements and Security Assessment Procedures
for guidance on the use of compensating controls.

Compromise Also referred to as “data compromise,” or “data breach.” Intrusion into a computer system where unauthorized
disclosure/theft, modification, or destruction of cardholder data is suspected.
Console Screen and keyboard which permits access and control of a server, mainframe computer or other system type in
a networked environment.
Consumer Individual purchasing goods, services, or both.
Cryptography Discipline of mathematics and computer science concerned with information security, particularly encryption and
authentication. In applications and network security, it is a tool for access control, information confidentiality,
and integrity.

D
Database Structured format for organizing and maintaining easily retrievable information. Simple database examples are
tables and spreadsheets.
Database Administrator Also referred to as “DBA.” Individual responsible for managing and administering databases.
Default Accounts Login account predefined in a system, application, or device to permit initial access when system is first put into
service. Additional default accounts may also be generated by the system as part of the installation process.

Default Password Password on system administration, user, or service accounts predefined in a system, application, or device;
usually associated with default account. Default accounts and passwords are published and well known, and
therefore easily guessed.
Degaussing Also called “disk degaussing.” Process or technique that demagnetizes the disk such that all data stored on the
disk is permanently destroyed.
Disk Encryption Technique or technology (either software or hardware) for encrypting all stored data on a device (for example, a
hard disk or flash drive). Alternatively, File- Level Encryption or Column-Level Database Encryption is used to
encrypt contents of specific files or columns.

DMZ Abbreviation for “demilitarized zone.” Physical or logical sub-network that provides an additional layer of security
to an organization’s internal private network. The DMZ adds an additional layer of network security between the
Internet and an organization’s internal network so that external parties only have direct connections to devices in
the DMZ rather than the entire internal network.

DNS Acronym for “Domain Name System” or “domain name server.” System that stores information associated with
domain names in a distributed database on networks such as the Internet.
DSS Acronym for “Data Security Standard” and also referred to as “PCI DSS.”
Dual Control Process of using two or more separate entities (usually persons) operating in concert to protect sensitive
functions or information. Both entities are equally responsible for the physical protection of materials involved in
vulnerable transactions. No single person is permitted to access or use the materials (for example, the
cryptographic key). For manual key generation, conveyance, loading, storage, and retrieval, dual control requires
dividing knowledge of the key among the entities. (See also Split Knowledge.)

Dynamic Packet FilteringSee Stateful Inspection.

E
ECC Acronym for “Elliptic Curve Cryptography.” Approach to public-key cryptography based on elliptic curves over
finite fields. See Strong Cryptography.
Egress Filtering Method of filtering outbound network traffic such that only explicitly allowed traffic is permitted to leave the
network.
Encryption Process of converting information into an unintelligible form except to holders of a specific cryptographic key.
Use of encryption protects information between the encryption process and the decryption process (the inverse
of encryption) against unauthorized disclosure. See Strong Cryptography.
Encryption Algorithm A sequence of mathematical instructions used for transforming unencrypted text or data to encrypted text or
data, and back again. See Strong Cryptography.
Entity Term used to represent the corporation, organization or business which is undergoing a PCI DSS review.

F
File Integrity Monitoring Technique or technology under which certain files or logs are monitored to detect if they are modified. When
critical files or logs are modified, alerts should be sent to appropriate security personnel.

File-Level Encryption Technique or technology (either software or hardware) for encrypting the full contents of specific files.
Alternatively, see Disk Encryption or Column-Level Database Encryption.
FIPS Acronym for “Federal Information Processing Standards.” Standards that are publicly recognized by the U.S.
Federal Government; also for use by non- government agencies and contractors.
Firewall Hardware and/or software technology that protects network resources from unauthorized access. A firewall
permits or denies computer traffic between networks with different security levels based upon a set of rules and
other criteria.

Forensics Also referred to as “computer forensics.” As it relates to information security, the application of investigative
tools and analysis techniques to gather evidence from computer resources to determine the cause of data
compromises.

FTP Acronym for “File Transfer Protocol.” Network protocol used to transfer data from one computer to another
through a public network such as the Internet. FTP is widely viewed as an insecure protocol because passwords
and file contents are sent unprotected and in clear text. FTP can be implemented securely via SSH or other
technology.

G
Acronym for “General Packet Radio Service.” Mobile data service available to users of GSM mobile phones.
Recognized for efficient use of limited bandwidth. Particularly suited for sending and receiving small bursts of
data, such as e-mail and web browsing.
GPRS
GSM Acronym for “Global System for Mobile Communications.” Popular standard for mobile phones and networks.
Ubiquity of GSM standard makes international roaming very common between mobile phone operators, enabling
subscribers to use their phones in many parts of the world.

H
Hashing Process of rendering cardholder data unreadable by converting data into a fixed-length message digest via Strong
Cryptography. Hashing is a (mathematical) function in which a non-secret algorithm takes any arbitrary length
message as input and produces a fixed length output (usually called a “hash code” or “message digest”). A hash
function should have the following properties:
(1) It is computationally infeasible to determine the original input given only the hash code,
(2) It is computationally infeasible to find two inputs that give the same hash code.
In the context of PCI DSS, hashing must be applied to the entire PAN for the hash code to be considered rendered
unreadable. It is recommended that hashed cardholder data includes a salt value as input to the hashing function
(see Salt).

Host Main computer hardware on which computer software is resident.

Hosting Provider Offers various services to merchants and other service providers. Services range from simple to complex; from
shared space on a server to a whole range of “shopping cart” options; from payment applications to connections
to payment gateways and processors; and for hosting dedicated to just one customer per server. A hosting
provider may be a shared hosting provider, who hosts multiple entities on a single server.

HTTP Acronym for “hypertext transfer protocol.” Open internet protocol to transfer or convey information on the
World Wide Web.
HTTPS Acronym for “hypertext transfer protocol over secure socket layer.” Secure HTTP that provides authentication
and encrypted communication on the World Wide Web designed for security-sensitive communication such as
web-based logins.

Hypervisor Software or firmware responsible for hosting and managing virtual machines. For the purposes of PCI DSS, the
hypervisor system component also includes the virtual machine monitor (VMM).

I
ID Identifier for a particular user or application.
IDS Acronym for “intrusion detection system.” Software or hardware used to identify and alert on network or system
intrusion attempts. Composed of sensors that generate security events; a console to monitor events and alerts
and control the sensors; and a central engine that records events logged by the sensors in a database. Uses
system of rules to generate alerts in response to security events detected.

IETF Acronym for “Internet Engineering Task Force.” Large, open international community of network designers,
operators, vendors, and researchers concerned with evolution of Internet architecture and smooth operation of
Internet. The IETF has no formal membership and is open to any interested individual.

Index Token A cryptographic token that replaces the PAN, based on a given index for an unpredictable value.
Information Security Protection of information to insure confidentiality, integrity, and availability.
Information System Discrete set of structured data resources organized for collection, processing, maintenance, use, sharing,
dissemination, or disposition of information.
Ingress Filtering Method of filtering inbound network traffic such that only explicitly allowed traffic is permitted to enter the
network.
Insecure A protocol, service, or port that introduces security concerns due to the lack of controls over confidentiality
Protocol/Service/Port and/or integrity. These security concerns include services, protocols, or ports that transmit data and
authentication credentials (e.g., password/passphrase in clear-text over the Internet), or that easily allow for
exploitation by default or if misconfigured. Examples of insecure services, protocols, or ports include but are not
limited to FTP, Telnet, POP3, IMAP, and SNMP.

IP Acronym for “internet protocol.” Network-layer protocol containing address information and some control
information that enables packets to be routed. IP is the primary network-layer protocol in the Internet protocol
suite.

IP Address Also referred to as “internet protocol address.” Numeric code that uniquely identifies a particular computer on
the Internet.
IP Address Spoofing Attack technique used by a malicious individual to gain unauthorized access to computers. The malicious
individual sends deceptive messages to a computer with an IP address indicating that the message is coming from
a trusted host.

IPS Acronym for “intrusion prevention system.” Beyond an IDS, an IPS takes the additional step of blocking the
attempted intrusion.
IPSEC Abbreviation for “Internet Protocol Security.” Standard for securing IP communications by encrypting and/or
authenticating all IP packets. IPSEC provides security at the network layer.
ISO Better known as “International Organization for Standardization.” Non- governmental organization consisting of a
network of the national standards institutes of over 150 countries, with one member per country and a central
secretariat in Geneva, Switzerland, that coordinates the system.

Issuer Entity that issues payment cards or performs, facilitates, or supports issuing services including but not limited to
issuing banks and issuing processors. Also referred to as “issuing bank” or “issuing financial institution.”

Issuing services Examples of issuing services may include but are not limited to authorization and card personalization.

K
Key In cryptography, a key is a value that determines the output of an encryption algorithm when transforming plain
text to ciphertext. The length of the key generally determines how difficult it will be to decrypt the ciphertext in a
given message. See Strong Cryptography.

Key Management In cryptography, it is the set of processes and mechanisms which support key establishment and maintenance,
including replacing older keys with new keys as necessary.

L
Acronym for “local area network.” A group of computers and/or other devices that share a common
LAN communications line, often in a building or group of buildings.
LDAP Acronym for “Lightweight Directory Access Protocol.” Authentication and authorization data repository utilized
for querying and modifying user permissions and granting access to protected resources.

Log See Audit Log.

LPAR Abbreviation for “logical partition.” A system of subdividing, or partitioning, a computer's total resources—
processors, memory and storage—into smaller units that can run with their own, distinct copy of the operating
system and applications. Logical partitioning is typically used to allow the use of different operating systems and
applications on a single device. The partitions may or may not be configured to communicate with each other or
share some resources of the server, such as network interfaces.

M
MAC Acronym for “message authentication code.” In cryptography, it is a small piece of information used to
authenticate a message. See Strong Cryptography.
MAC Address Abbreviation for “media access control address.” Unique identifying value assigned by manufacturers to network
adapters and network interface cards.
Magnetic-Stripe Data Also referred to as “track data.” Data encoded in the magnetic stripe or chip used for authentication and/or
authorization during payment transactions. Can be the magnetic stripe image on a chip or the data on the track 1
and/or track 2 portion of the magnetic stripe.

Mainframe Computers that are designed to handle very large volumes of data input and output and emphasize throughput
computing. Mainframes are capable of running multiple operating systems, making it appear like it is operating as
multiple computers. Many legacy systems have a mainframe design.

Malicious Software / Software designed to infiltrate or damage a computer system without the owner's knowledge or consent. Such
Malware software typically enters a network during many business-approved activities, which results in the exploitation of
system vulnerabilities. Examples include viruses, worms, Trojans (or Trojan horses), spyware, adware, and
rootkits.

Masking In the context of PCI DSS, it is a method of concealing a segment of data when displayed or printed. Masking is
used when there is no business requirement to view the entire PAN. Masking relates to protection of PAN when
displayed or printed. See Truncation for protection of PAN when stored in files, databases, etc.
Merchant For the purposes of the PCI DSS, a merchant is defined as any entity that accepts payment cards bearing the logos
of any of the five members of PCI SSC (American Express, Discover, JCB, MasterCard or Visa) as payment for
goods and/or services. Note that a merchant that accepts payment cards as payment for goods and/or services
can also be a service provider, if the services sold result in storing, processing, or transmitting cardholder data on
behalf of other merchants or service providers. For example, an ISP is a merchant that accepts payment cards for
monthly billing, but also is a service provider if it hosts merchants as customers.

Monitoring Use of systems or processes that constantly oversee computer or network resources for the purpose of alerting
personnel in case of outages, alarms, or other predefined events.
MPLS Acronym for “multi protocol label switching.” Network or telecommunications mechanism designed for
connecting a group of packet-switched networks.

N
NAT Acronym for “network address translation.” Known as network masquerading or IP masquerading. Change of an
IP address used within one network to a different IP address known within another network.

Network Two or more computers connected together via physical or wireless means.
Network Administrator Personnel responsible for managing the network within an entity. Responsibilities typically include but are not
limited to network security, installations, upgrades, maintenance and activity monitoring.

Network Components Include, but are not limited to firewalls, switches, routers, wireless access points, network appliances, and other
security appliances.
Network Security Scan Process by which an entity’s systems are remotely checked for vulnerabilities through use of manual or
automated tools. Security scans that include probing internal and external systems and reporting on services
exposed to the network. Scans may identify vulnerabilities in operating systems, services, and devices that could
be used by malicious individuals.
Network Segmentation Network segmentation isolates system components that store, process, or transmit cardholder data from systems
that do not. Adequate network segmentation may reduce the scope of the cardholder data environment and thus
reduce the scope of the PCI DSS assessment. See the Network Segmentation section in the PCI DSS Requirements
and Security Assessment Procedures for guidance on using network segmentation. Network segmentation is not
a PCI DSS requirement. See System Components.

NIST Acronym for “National Institute of Standards and Technology.” Non-regulatory federal agency within U.S.
Commerce Department's Technology Administration. Their mission is to promote U.S. innovation and industrial
competitiveness by advancing measurement science, standards, and technology to enhance economic security
and improve quality of life.

NMAP Security-scanning software that maps networks and identifies open ports in network resources.
Non-Consumer Users Individuals, excluding cardholders, who access system components, including but not limited to employees,
administrators, and third parties.
NTP Acronym for “Network Time Protocol.” Protocol for synchronizing the clocks of computer systems, network
devices and other system components.

O
Off-the-Shelf Description of products that are stock items not specifically customized or designed for a specific customer or
user and are readily available for use.
Operating System / OS Software of a computer system that is responsible for the management and coordination of all activities and the
sharing of computer resources. Examples of operating systems include Microsoft Windows, Mac OS, Linux and
Unix.

OWASP Acronym for “Open Web Application Security Project.” A non-profit organization focused on improving the
security of application software. OWASP maintains a list of critical vulnerabilities for web applications. (See
http://www.owasp.org).

P
PA-QSA Acronym for “Payment Application Qualified Security Assessor,” company approved by the PCI SSC to conduct
assessments on payment applications against the PA-DSS.
PAN Acronym for “primary account number” and also referred to as “account number.” Unique payment card number
(typically for credit or debit cards) that identifies the issuer and the particular cardholder account.

Password / Passphrase A string of characters that serve as an authenticator of the user.

Pad In cryptography, the one-time pad is an encryption algorithm with text combined with a random key or "pad"
that is as long as the plain-text and used only once. Additionally, if key is truly random, never reused, and, kept
secret, the one-time pad is unbreakable

Parameterized Queries A means of structuring SQL queries to limit escaping and thus prevent injection attacks.
PAT Acronym for “port address translation” and also referred to as “network address port translation.” Type of NAT
that also translates the port numbers.
Patch Update to existing software to add functionality or to correct a defect.
Payment Application Any application that stores, processes, or transmits cardholder data as part of authorization or settlement

Payment Cards For purposes of PCI DSS, any payment card/device that bears the logo of the founding members of PCI SSC, which
are American Express, Discover Financial Services, JCB International, MasterCard Worldwide, or Visa, Inc.

PCI Acronym for “Payment Card Industry.”

Acronym for “personal data assistant” or “personal digital assistant.” Handheld mobile devices with capabilities
PDA such as mobile phones, e-mail, or web browser.
PED PIN entry device
Penetration Test Penetration tests attempt to exploit vulnerabilities to determine whether unauthorized access or
other malicious activity is possible. Penetration testing includes network and application testing as
well as controls and processes around the networks and applications, and occurs from both outside
the network trying to come in (external testing) and from inside the network.
Personnel Full-time and part-time employees, temporary employees, contractors, and consultants who are “resident” on
the entity’s site or otherwise have access to the cardholder data environment.
Personally Identifiable Information that can be utilized to identify an individual including but not limited to name, address, social security
Information number, phone number, etc.
PIN Acronym for “personal identification number.” Secret numeric password known only to the user and a system to
authenticate the user to the system. The user is only granted access if the PIN the user provided matches the PIN
in the system. Typical PINs are used for automated teller machines for cash advance transactions. Another type of
PIN is one used in EMV chip cards where the PIN replaces the cardholder’s signature.

PIN Block A block of data used to encapsulate a PIN during processing. The PIN block format defines the
content of the PIN block and how it is processed to retrieve the PIN. The PIN block is composed of the
PIN, the PIN length, and may contain subset of the PAN.
POI Acronym for “Point of Interaction,” the initial point where data is read from a card. An electronic
transaction-acceptance product, a POI consists of hardware and software and is hosted in acceptance
equipment to enable a cardholder to perform a card transaction. The POI may be attended or
unattended. POI transactions are typically integrated circuit (chip) and/or magnetic-stripe card-based
payment transactions.
Policy Organization-wide rules governing acceptable use of computing resources, security practices, and guiding
development of operational procedures
POS Acronym for “point of sale.” Hardware and/or software used to process payment card transactions at merchant
locations.
Private Network Network established by an organization that uses private IP address space. Private networks are commonly
designed as local area networks. Private network access from public networks should be properly protected with
the use of firewalls and routers.

Procedure Descriptive narrative for a policy. Procedure is the “how to” for a policy and describes how the policy is to be
implemented.
Protocol Agreed-upon method of communication used within networks. Specification describing rules and procedures that
computer products should follow to perform activities on a network.
PTS Acronym for “PIN Transaction Security,” PTS is a set of modular evaluation requirements managed by PCI Security
Standards Council, for PIN acceptance POI terminals. Please refer to www.pcisecuritystandards.org.

Public Network Network established and operated by a telecommunications provider, for specific purpose of providing data
transmission services for the public. Data over public networks can be intercepted, modified, and/or diverted
while in transit. Examples of public networks in scope of the PCI DSS include, but are not limited to, the Internet,
wireless, and mobile technologies.
PVV Acronym for “PIN verification value.” Discretionary value encoded in magnetic stripe of payment card.

Q
QSA Acronym for “Qualified Security Assessor,” company approved by the PCI SSC to conduct PCI DSS on-site
assessments.

R
RADIUS Abbreviation for “Remote Authentication Dial-In User Service.” Authentication and accounting system. Checks if
information such as username and password that is passed to the RADIUS server is correct, and then authorizes
access to the system. This authentication method may be used with a token, smart card, etc., to provide two-
factor authentication.

Acronym for “role-based access control.” Control used to restrict access by specific authorized users based on
RBAC their job responsibilities.
Remote Access Access to computer networks from a remote location, typically originating from outside the network. An example
of technology for remote access is VPN.
Removable Electronic Media Media that store digitized data and which can be easily removed and/or transported from one computer system
to another. Examples of removable electronic media include CD-ROM, DVD-ROM, USB flash drives and removable
hard drives.

ROC Report on Compliance - Report containing details documenting an entity’s compliance status with the PCI DSS.

Report on Validation Also referred to as “ROV.” Report containing details documenting a payment application’s compliance with the
PCI PA-DSS.
Process of changing cryptographic keys. Periodic re-keying limits the amount of data encrypted by a single key.
Re-keying
Remote Lab Environment A lab that is not maintained by the PA-QSA.
Reseller / Integrator An entity that sells and/or integrates payment applications but does not develop them.
RFC 1918 The standard identified by the Internet Engineering Task Force (IETF) that defines the usage and appropriate
address ranges for private (non-internet routable) networks.
Risk Analysis / Risk Process that identifies valuable system resources and threats; quantifies loss exposures (that is, loss potential)
Assessment based on estimated frequencies and costs of occurrence; and (optionally) recommends how to allocate resources
to countermeasures so as to minimize total exposure.

Rootkit Type of malicious software that when installed without authorization, is able to conceal its presence and gain
administrative control of a computer system.
Router Hardware or software that connects two or more networks. Functions as sorter and interpreter by looking at
addresses and passing bits of information to proper destinations. Software routers are sometimes referred to as
gateways.

RSA Algorithm for public-key encryption described in 1977 by Ron Rivest, Adi Shamir, and Len Adleman at
Massachusetts Institute of Technology (MIT); letters RSA are the initials of their surnames.

S
Salt Random string that is concatenated with other data prior to being operated on by a hash function. See also Hash.

Sampling The process of selecting a cross-section of a group that is representative of the entire group. Sampling may be
used by assessors to reduce overall testing efforts, when it is validated that an entity has standard, centralized PCI
DSS security and operational processes and controls in place. Sampling is not a PCI DSS requirement.

SANS Acronym for “SysAdmin, Audit, Networking and Security,” an institute that provides computer security training
and professional certification. (See www.sans.or
Scoping Process of identifying all system components, people, and processes to be included in a PCI DSS assessment. The
first step of a PCI DSS assessment is to accurately determine the scope of the review.

SDLC Acronym for “system development life cycle.” Phases of the development of a software or computer system that
includes planning, analysis, design, testing, and implementation.
Secure Coding The process of creating and implementing applications that are resistant to tampering and/or compromise.

Secure Wipe Also called “secure delete,” a program utility used to delete specific files permanently from a computer system.
Security Officer Also called “secure delete,” a program utility used to delete specific files permanently from a computer system.

Security Policy Set of laws, rules, and practices that regulate how an organization manages, protects, and distributes sensitive
information
Security Protocols Network communications protocols designed to secure the transmission of data. Examples of security protocols
include, but are not limited to SSL/TLS, IPSEC, SSH, etc.
SAQ Acronym for “Self-Assessment Questionnaire.” Tool used by any entity to validate its own compliance with the
PCI DSS.
Sensitive Area Any data center, server room or any area that houses systems that stores, processes, or transmits cardholder
data. This excludes the areas where only point-of-sale terminals are present such as the cashier areas in a retail
store.

Sensitive Authentication Security-related information (including but not limited to card validation codes/values, full magnetic-stripe data,
Data PINs, and PIN blocks) used to authenticate cardholders and/or authorize payment card transactions.

Separation of Duties Practice of dividing steps in a function among different individuals, so as to keep a single individual from being
able to subvert the process.
Server Computer that provides a service to other computers, such as processing communications, file storage, or
accessing a printing facility. Servers include, but are not limited to web, database, application, authentication,
DNS, mail, proxy, and NTP.

Service Code Three-digit or four-digit value in the magnetic-stripe that follows the expiration date of the payment card on the
track data. It is used for various things such as defining service attributes, differentiating between international
and national interchange, or identifying usage restrictions.

Service Provider Business entity that is not a payment brand, directly involved in the processing, storage, or transmission of
cardholder data. This also includes companies that provide services that control or could impact the security of
cardholder data. Examples include managed service providers that provide managed firewalls, IDS and other
services as well as hosting providers and other entities. Entities such as telecommunications companies that only
provide communication links without access to the application layer of the communication link are excluded.

SHA-1/SHA-2 Acronym for “Secure Hash Algorithm.” A family or set of related cryptographic hash functions including SHA-1
and SHA-2. See Strong Cryptography.
Smart Card Also referred to as “chip card” or “IC card (integrated circuit card).” A type of payment card that has integrated
circuits embedded within. The circuits, also referred to as the “chip,” contain payment card data including but not
limited to data equivalent to the magnetic-stripe data.

SNMP Acronym for “Simple Network Management Protocol.” Supports monitoring of network attached devices for any
conditions that warrant administrative attention.
Spyware Type of malicious software that when installed, intercepts or takes partial control of the user’s computer without
the user’s consent.
Acronym for “Structured Query Language.” Computer language used to create, modify, and retrieve data from
SQL relational database management systems.
SQL Injection Form of attack on database-driven web site. A malicious individual executes unauthorized SQL commands by
taking advantage of insecure code on a system connected to the Internet. SQL injection attacks are used to steal
information from a database from which the data would normally not be available and/or to gain access to an
organization’s host computers through the computer that is hosting the database.

SSH Abbreviation for “Secure Shell.” Protocol suite providing encryption for network services like remote login or
remote file transfer.
SSL Acronym for “Secure Sockets Layer.” Established industry standard that encrypts the channel between a web
browser and web server to ensure the privacy and reliability of data transmitted over this channel.

Stateful Inspection Also called “dynamic packet filtering,” it is a firewall capability that provides enhanced security by keeping track
of communications packets. Only incoming packets with a proper response (“established connections”) are
allowed through the firewall.

Strong Cryptography Cryptography based on industry-tested and accepted algorithms, along with strong key lengths and proper key-
management practices. Cryptography is a method to protect data and includes both encryption (which is
reversible) and hashing (which is not reversible, or “one way”). Examples of industry-tested and accepted
standards and algorithms for encryption include AES (128 bits and higher), TDES (minimum double-length keys),
RSA (1024 bits and higher), ECC (160 bits and higher), and ElGamal (1024 bits and higher).
See NIST Special Publication 800-57 (http://csrc.nist.gov/publications/) for more information.

SysAdmin Abbreviation for “system administrator.” Individual with elevated privileges who is responsible for managing a
computer system or network.
System Components Any network component, server, or application included in or connected to the cardholder data environment.

System-level object Anything on a system component that is required for its operation, including but not limited to application
executable and configuration files, system configuration files, static and shared libraries & DLL's, system
executables, device drivers and device configuration files, and added third-party components.

T
TACACS Acronym for “Terminal Access Controller Access Control System.” Remote authentication protocol commonly
used in networks that communicates between a remote access server and an authentication server to determine
user access rights to the network. This authentication method may be used with a token, smart card, etc., to
provide two-factor authentication.

TCP Acronym for “Transmission Control Protocol.” Basic communication language or protocol of the Internet.

TDES Acronym for “Triple Data Encryption Standard” and also known as “3DES” or “Triple DES.” Block cipher formed
from the DES cipher by using it three times. See Strong Cryptography.
TELNET Abbreviation for “telephone network protocol.” Typically used to provide user- oriented command line login
sessions to devices on a network. User credentials are transmitted in clear text.
Threat Condition or activity that has the potential to cause information or information processing resources to be
intentionally or accidentally lost, modified, exposed, made inaccessible, or otherwise affected to the detriment of
the organization

TLS Acronym for “Transport Layer Security.” Designed with goal of providing data secrecy and data integrity between
two communicating applications. TLS is successor of SSL.
Token A value provided by hardware or software that usually works with an authentication server or VPN to perform
dynamic or two-factor authentication. See RADIUS, TACACS, and VPN.
Transaction Data Data related to electronic payment card transaction.
Trojan Also referred to as “Trojan horse.” A type of malicious software that when installed, allows a user to perform a
normal function while the Trojan performs malicious functions to the computer system without the user’s
knowledge.
Truncation Method of rendering the full PAN unreadable by permanently removing a segment of PAN data. Truncation
relates to protection of PAN when stored in files, databases, etc. See Masking for protection of PAN when
displayed on screens, paper receipts, etc.

Trusted Network Network of an organization that is within the organization’s ability to control or manage.
Two-Factor Authentication Method of authenticating a user whereby two or more factors are verified. These factors include something the
user has (such as hardware or software token), something the user knows (such as a password, passphrase, or
PIN) or something the user is or does (such as fingerprints or other forms of biometrics).

U
Untrusted Network Network that is external to the networks belonging to an organization and which is out of the organization’s
ability to control or manage.

V
Virtualization Virtualization refers to the logical abstraction of computing resources from physical constraints. One common
abstraction is referred to as virtual machines or VMs, which takes the content of a physical machine and allows it
to operate on different physical hardware and/or along with other virtual machines on the same physical
hardware. In addition to VMs, virtualization can be performed on many other computing resources, including
applications, desktops, networks, and storage.

Virtual Machine Monitor The VMM is included with the hypervisor and is software that implements virtual machine hardware abstraction.
(VMM) It manages the system's processor, memory, and other resources to allocate what each guest operating system
requires.

Virtual Machine A self-contained operating environment that behaves like a separate computer. It is also known as the “Guest,”
and runs on top of a hypervisor.
Virtual Appliance (VA) A VA takes the concept of a pre-configured device for performing a specific set of functions and run this device as
a workload. Often, an existing network device is virtualized to run as a virtual appliance, such as a router, switch,
or firewall.
Virtual Switch or Router A virtual switch or router is a logical entity that presents network infrastructure level data routing and switching
functionality. A virtual switch is an integral part of a virtualized server platform such as a hypervisor driver,
module, or plug-in.

Virtual Terminal A virtual terminal is web-browser-based access to an acquirer, processor or third party service provider website
to authorize payment card transactions, where the merchant manually enters payment card data via a securely
connected web browser. Unlike physical terminals, virtual terminals do not read data directly from a payment
card. Because payment card transactions are entered manually, virtual terminals are typically used instead of
physical terminals in merchant environments with low transaction volumes.

VLAN Abbreviation for “virtual LAN” or “virtual local area network.” Logical local area network that extends beyond a
single traditional physical local area network.
VPN Acronym for “virtual private network.” A computer network in which some of connections are virtual circuits
within some larger network, such as the Internet, instead of direct connections by physical wires. The end points
of the virtual network are said to be tunneled through the larger network when this is the case. While a common
application consists of secure communications through the public Internet, a VPN may or may not have strong
security features such as authentication or content encryption.
A VPN may be used with a token, smart card, etc., to provide two-factor authentication.

Vulnerability Flaw or weakness which, if exploited, may result in an intentional or unintentional compromise of a system.

W
Acronym for “wide area network.” Computer network covering a large area, often a regional or company wide
WAN computer system.
Web Application An application that is generally accessed via a web browser or through web services. Web applications may be
available via the Internet or a private, internal network.
Web Server Computer that contains a program that accepts HTTP requests from web clients and serves the HTTP responses
(usually web pages).
WEP Acronym for “Wired Equivalent Privacy.” Weak algorithm used to encrypt wireless networks. Several serious
weaknesses have been identified by industry experts such that a WEP connection can be cracked with readily
available software within minutes. See WPA.

Wireless Access Point Network that connects computers without a physical connection to wires.
WLAN Acronym for “wireless local area network.” Local area network that links two or more computers or devices
without wires.
WPA/WPA2 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

Return to Table of content

Scope: “Area of computer system network that possesses cardholder data or sensitive authentication data and those
systems and segments that directly attach or support cardholder processing"

Define your Card Data Environment (CDE)

Perimeter
IP address/URL Name Type Purpose Owner

Internal
IP address/URL Name Type Purpose Owner
Scope Definition

System Admin Criticality Patch level Last Scan date Scan report location

System Admin Criticality Patch level last Scan date Last scan report
Table of content Intro Chart Compliance Chart Severity Chart Priority Merchant Types

ORGANIZATION
NAME: What's your company name?

Merchant Type: D Click on B3 to select your Merchant type (A, A-EP, PE2P,B,B-IP,C, C-VT, D,S)

Compliance Status SEVERITY

PCI-DSS # of # Not in # Not

% compliance # In Place # Compensating # Not Applicable Severity Max Severity
REQUIREMENTS Requirements Place Tested

1 74% 38 26 10 2 0 0 32 163
2 10% 31 3 25 0 0 3 123 136
3 2% 45 1 43 0 0 1 122 128
4 18% 11 2 8 0 0 1 41 51
5 9% 11 1 8 0 0 2 46 51
6 2% 42 1 41 0 0 0 143 144
7 73% 11 1 2 7 0 1 7 31
8 5% 37 2 35 0 0 0 97 103
9 16% 45 6 36 1 0 2 102 115
10 7% 41 3 33 0 3 2 103 121
11 6% 32 1 29 1 0 1 130 134
12 9% 46 3 41 1 0 1 88 98
Total 16% 390 50 311 12 3 14 1034 1275

81%
.
 PRIORITY BOARD based on PCI DSS APPROACH

#P1 #P1 #P2 #P2 #P3 #P3 #P4 #P4 #P5 #P5 #P6 #P6
in place Total in place Total in place Total in place Total in place Total in place Total

3 3 22 26 0 0 0 0 0 0 3 8
0 0 1 15 2 15 0 0 0 0 0 1
1 10 0 1 0 0 0 0 0 29 0 5
0 0 2 10 0 0 0 0 0 0 0 1
0 0 1 10 0 0 0 0 0 0 0 1
0 0 0 0 0 34 0 0 0 0 1 8
0 0 0 0 0 0 8 10 0 0 0 1
0 0 0 0 0 0 2 36 0 0 0 1
0 2 0 6 0 0 0 0 6 36 1 1
0 0 0 0 0 0 3 40 0 0 0 1
0 0 0 20 0 0 1 11 0 0 1 1
0 2 1 6 0 0 1 9 0 0 2 29
4 17 27 94 2 49 15 106 6 65 8 58

24% 29% 4% 14% 9% 14%

Documentation required to be in compliance with DSS V3.

Return to table of content This sheet provides the detailed list of documentation that your organisation should
have ready for the auditor visit. Each document is detailed in terms of content and
associated PCI DSS V3 requirements. The rest of this sheet could be used to track
various parameter along the life of these documents such as version, owner, where to
find it. ORDER

The content of this sheet will be sent for a contribution of $75. Just Contact
d@dgozone.com

Techical documentation

Ref Title/Topic Description PCI DSS Req Version

Policies, Procedures and standards documentation

Ref Title Description PCI DSS Req Version

Documentation required to be in compliance with DSS V3.

Owner Approved by Location/link Published/DRAFT

Owner Location Published/DRAFT

 Executive Summary Go to Chart Severity

Compliance % per requirement

80%
74% 73%
70%

60%

50%

40%

30%

20% 18%
16%

10% 9% 9%
10% 7%
5% 6%
2% 2%
0%
1 2 3 4 5 6 7 8 9 10 11 12
Return to Table of content Executive Summary Chart Compliance

180 Severity versus max severity per requirement

163
160

143144
140 136 134
128 130
123 122 121
120 115

103 102 103

100 97 98
88

80

60
51 51
46
41
40
32 31

20
7

0
1 2 3 4 5 6 7 8 9 10 11 12
 Table of content Chart Severity Chart Compliance

Priority % in place
1 24% Progress by Priority
35%
2 29%
3 4%
30% 4 14%
5 9%
6 14%
25%

20%

15%
Progress by Priority
10%

5%

0%
1 2 3 4 5 6
hart Compliance Executive Summary

Progress by Priority
Return to Table of content
Name Email Tel Function Areas of expertize
Name 1
Name 2
Name 3
Name 4
Return to Table of content
Executive Summary Merchant types

Types Description
A Card-not-present (e-commerce or mail/telephone-order) merchants, all cardholder data functions outsourced. This
would never apply to face-to-face merchants.
B Imprint-only merchants with no electronic cardholder data storage, or standalone, dial- out terminal merchants with
no electronic cardholder data storage

B Merchants who process cardholder data only via standalone, PTS-approved point-of-interaction devices with an IP
connection to the payment processor.

C-VT Merchants using only web-based virtual terminals, no electronic cardholder data storage
C Merchants with payment application systems connected to the Internet, no electronic cardholder data storage

D All other merchants not included in descriptions for SAQ types A through C above, and all service
providers defined by a payment brand as eligible to complete an SAQ.

S Service Providers
A-EP E-commerce merchants with a websites that do not themselves receive cardholder data but which do affect the
security of the payment transaction and/or the integrity of the page that accepts the consumer’s cardholder data.

PE2P Merchants using only hardware terminals as part of a validated P2PE solution listed by PCI SSC.
It's important to remember that SAQs are validation documents and whether a merchant is eligible or required to
validate to one of the SAQs, and which SAQ they should validate to, is determined by the payment brands and/or
acquirers. Also, please keep in mind that the v2.0 SAQs are still valid throughout 2014.
Return to Table of content
Compensatin #Req Constraints Objective Identified Risk
g
Control Id

# #requirement List constraints precluding Define the objective of the Identify any additional risk
s for which a compliance with the original original control; identify the posed by the lack of the
compensating requirement. objective met by the original control.
control is compensating control.
defined

1
2
3
4
5
6
7
8
9
10
11
Definition of Compensation Control Validation of Compensating Control Maintenance

Define the compensating controls and Define how the compensating controls Define process and controls
explain how they address the objectives of were validated and tested. in place to maintain
the original control and the increased risk, compensating controls
if any.
 Table of content Executive Summary

NOT #Req Rationals

APPLICABLE
# # Requirements Rationals
that is defined as
NA

1
2
3
4
5
6
7
8
9
10
11
Table of content

CRYPTOGRAPHIC KEY METADATA MODEL

Key Label Purpose Type of Key Key Class Assets:Application Key Owner Storage Protection Key lenght
using the key location method
Key Key Cryptoperiod Comments /
Manager Generation
Method
 Return to Table of content
SANS Top 20 Critical Security Controls and Subcontrols (+-200) Matching Matching Score Notes
PCI Reqs level
If Any

C1 Critical Control 1: Inventory of Authorized and 16.67% 1.5

Unauthorized Devices
C1.1 An accurate and up-to-date inventory, controlled by active Scoping P 0.5 While there is no specific inventory
monitoring and configuration management, can reduce the chance requirement, the inventory process
of attackers finding unauthorized and unprotected systems to is actually part of a scoping
exploit. exercice.

C1.2 Deploy an automated asset inventory discovery tool and use it to 11.1 P 0.5 No specific inventory requirements
build a preliminary asset inventory of systems connected to the 11.2 but target discovery is the first part
enterprise network. Both active tools that scan through network of the external scanning process.
address ranges and passive tools that identify hosts based on
analyzing their traffic should be employed.

C1.3 Maintain an asset inventory of all systems connected to the Scoping P 0.5 While there is no specific inventory
network and the network devices themselves, recording at least requirement, the inventory process
the network addresses, machine name(s), purpose of each system, is actually part of a scoping
an asset owner responsible for each device, and the department exercice.
associated with each device. The inventory should include every
system that has an Internet protocol (IP) address on the network,
including, but not limited to desktops, laptops, servers, network
equipment (routers, switches, firewalls,
C1.4 The asset inventory created must also include data on whether the - N 0
device is a portable device. Devices such as mobile phones, tablets,
laptops, and other portable electronic devices that store or process
data must be identified, regardless of whether or not they are
attached to the organization’s network.

C1.5 Ensure that network inventory monitoring tools are operational - N 0

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 - N 0
that they are included in periodic vulnerability scans and that asset
information is encrypted. Limit access to these systems to
authorized personnel only, and carefully log all such access. For
additional security, a secure copy of the asset inventory may be
kept in an off-line system air-gapped from the production network.

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

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

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

so if attacks occur, the impact can be remediated by moving the
untrusted system to a virtual local area network that has minimal
access.

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

Unauthorized Software
C2.1 Devise a list of authorized software that is required in the - N 0
enterprise for each type of system, including servers, workstations,
and laptops of various kinds and uses.

C2.2 Deploy software inventory tools throughout the organization - N 0

covering each of the operating system types in use, including
servers, workstations, and laptops. The software inventory system
should track the version of the underlying operating system as well
as the applications installed on it. Furthermore, the tool should
record not only the type of software installed on each system, but
also its version number and patch level.

C2.3 The software inventory tool should also monitor for unauthorized - N 0
software installed on each machine. This unauthorized software
also includes legitimate system administration software installed
on inappropriate systems where there is no business need for it.
C2.4 Deploy application white listing technology that allows systems to - N 0
run only approved software and prevents execution of all other
software on the system. Such white listing tools must be based on
acceptable hashing algorithms for determining authorized binaries
to execute on a system.

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

isolate and run applications that are required but based on higher
risk and that should not be installed within a networked
environment.

C3 Critical Control 3: Secure Configurations for 45.45% 5

Hardware and Software on Laptops, Workstations,
and Servers
C3.1 Strict configuration management should be followed, building a 2.2 F 1
secure image that is used to build all new systems that are
deployed to the enterprise. Any existing system that becomes
compromised is re-imaged with the secure build. Regular updates
to this image are integrated into the organization’s change
management processes.

C3.2 System images must have documented security settings that are 2.2 F 1
tested before deployment, approved by an organization change
control board, and registered with a central image library for the
organization or multiple organizations. These images should be
validated and refreshed on a regular basis (e.g., every six months)
to update their security configuration in light of recent
vulnerabilities and attack vectors.
C3.3 Standardized images should represent hardened versions of the 2.1 F 1
underlying operating system and the applications installed on the 2.2
system, such as those released by the NIST, NSA, Defense 2.2.2
Information Systems Agency (DISA), Center for Internet Security 2.2.3
(CIS), and others. This hardening would typically include removal of 2.2.4
unnecessary accounts, as well as the disabling or removal of
unnecessary services. Such hardening also involves, among other
measures, applying patches, closing open and unused network
ports, implementing intrusion detection systems and/or intrusion
prevention systems, and erecting host-based firewalls.

C3.4 Any deviations from the standard build or updates to the standard - N 0
build should be documented and approved in a change
management system.

C3.5 Organizations should negotiate contracts to buy systems - N 0

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.

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

configured servers, with integrity checking tools and change
management to ensure that only authorized changes to the images
are possible. Alternatively, these master images can be stored in
offline machines, air-gapped from the production network, with
images copied via secure media to move them between the image
storage servers and the production network.

C3.7 Run the last version of software and make sure it is fully patched. 6.1 F 1
C3.7.1 Remove outdated or older software from the system. - N 0 No specific requirements but ASV
scans must fail targetsiff the
version of the operating system is
an older version no longer
supported by the vendo

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

sample of systems to determine which ones are configured
according to the secure configuration guidelines.

C3.9 Utilize file integrity checking tools on at least a weekly basis to 11.5 F 1
ensure that critical system files (including sensitive system and
application executables, libraries, and configurations) have not
been altered. All alterations to such files should be automatically
reported to security personnel. The reporting system should have
the ability to account for routine and expected changes,
highlighting unusual or unexpected alterations.

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

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

systems that match configuration guidelines versus those that do
not match, illustrating the change of such numbers month by
month for each organizational unit.
C4 Critical Control 4: Continuous Vulnerability 20.00% 2
Assessment and Remediation
C4.1 Organizations should run automated vulnerability scanning tools 11.2 P 0.5 PCI requirements less restrictive
against all systems on their networks on a weekly or more frequent 11.2.1 (once a quarter or after major
basis. Where feasible, vulnerability scanning should occur on a 11.2.2 changes
daily basis using an up-to-date vulnerability scanning tool. 11.2.3

C4.1.1 Any vulnerability identified should be remediated in a timely 6.1 P 0.5 PCI less restrictive in terms of
manner, with critical vulnerabilities fixed within 48 hours. critical vulnerabilities fixing period
(One month)

C4.2 Event logs should be correlated with information from vulnerability - N 0

scans to fulfill two goals. First, personnel should verify that the
activity of the regular vulnerability scanning tools themselves is
logged. Second, personnel should be able to correlate attack
detection events with earlier vulnerability scanning results to
determine whether the given exploit was used against a known-
vulnerable target

C4.3 Organizations should deploy automated patch management tools - N 0

and software update tools for all systems for which such tools are
available and safe.

C4.4 In order to overcome limitations of unauthenticated vulnerability - N 0 11.2 requires ASV to run
scanning, organizations should ensure that all vulnerability unauthenticated scans with the
scanning is performed in authenticated mode either with agents known limitations. PCI rules should
running locally on each end system to analyze the security align on Top 20.
configuration or with remote scanners that are given
administrative rights on the system being tested.
C4.5 Organizations should compare the results from back-to-back 6.2 F 1 For the risk approach. Nothing
vulnerability scans to verify that vulnerabilities were addressed about validation /control process
either by patching, implementing a compensating control, or
documenting and accepting a reasonable business risk. Such
acceptance of business risks for existing vulnerabilities should be
periodically reviewed to determine if newer compensating controls
or subsequent patches can address vulnerabilities that were
previously accepted, or if conditions have changed increasing the
risk.

C4.6 Vulnerability scanning tools should be tuned to compare services - N 0 Checking services and
that are listening on each machine against a list of authorized configuration as part of a scan isn't
services. The tools should be further tuned to identify changes explicitely required by PCI.
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.

C4.7 Security personnel should chart the numbers of unmitigated, - N 0

critical vulnerabilities for each department/division.

C4.8 Security personnel should share vulnerability reports indicating - N 0

critical issues with senior management to provide effective
incentives for mitigation.

C4.9 Organizations should measure the delay in patching new - N 0

vulnerabilities and ensure that the delay is equal to or less than the
benchmarks set forth by the organization. The timeframe should
be no more than a week for critical patches, unless a mitigating
control that blocks exploitation is available.
C4.10 Critical patches must be evaluated in a test environment before - N 0
being pushed into production on enterprise systems. If such
patches break critical business applications on test machines, the
organization must devise other mitigating controls that block
exploitation on systems where the patch cannot be deployed
because of its impact on business functionality.

C5 Critical Control 5: Malware Defenses 37.50% 3

C5.1 Organizations should monitor workstations, servers, and mobile 5.1 P 0.5 PCI doesn't mention ati-malware
devices for active, up-to-date anti-malware protection with anti- protection.
virus, anti-spyware,

C5.1.1 personal firewalls 1.4 F 1

C5.1.2 and host-based IPS functionality. 11.4 P 0.5 11.4 requires the use of network
based IPS/IDS. PCI doesn't require
host based IPS

C5.1.3 All malware detection events should be sent to enterprise anti- - N 0 PCI doesn't address the
malware administration tools and event log servers. centralization of malware event
management. The closest
requirement is 5.2 requiring
generation of audit logs

C5.2 Organizations should employ anti-malware software and signature 5.2 F 1 5.2 is the closest requirement:
auto update features or have administrators manually push (Anti-virus must be current)
updates to all machines on a daily basis.

C5.2.1 After applying an update, automated systems should verify that - N 0

each system has received its signature update.
C5.3 Organizations should configure laptops, workstations, and servers - N 0
so that they will not auto-run content from USB tokens (i.e.,
“thumb drives”), USB hard drives, CDs/DVDs, Firewire devices,
external serial advanced technology attachment devices, mounted
network shares, or other removable media.

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

automated anti-malware scan of removable media when it is
inserted.

C5.5 All attachments entering the organization’s e-mail gateway should - N 0 Should be part of 5.2 but email
be scanned and blocked if they contain malicious code. This servers could not be within the
scanning should be done before the e-mail is placed in the user’s scope.
inbox.

C5.6 Behavioral-based anomaly detection should be used to - N 0

complement and enhance traditional signature-based detection.

C5.7 Organizations should deploy network access control tools to verify - N 0

security configuration and patch-level compliance before granting
access to a network.

C5.8 Continuous monitoring should be performed on outbound traffic. - N 0

Any large transfers of data or unauthorized encrypted traffic
should be flagged and, if validated as malicious, the computer
should be moved to an isolated VLAN.

C6 Critical Control 6: Application Software Security 50.00% 4.5

C6.1 Organizations should protect web applications by deploying web 6.6 P 0.5 Code review OR WAF
application firewalls that inspect all traffic flowing to the web
application for common web application attacks, including but not
limited to cross-site scripting, SQL injection, command injection,
and directory traversal attacks. For applications that are not web-
based, specific application firewalls should be deployed if such
tools are available for the given application type. If the traffic is
encrypted, the device should either sit behind the encryption or be
capable of decrypting the traffic prior to analysis. If neither option
is appropriate, a host-based web application firewall should be
deployed.

C6.2 At a minimum, explicit error checking should be done for all input. - N 0
Whenever a variable is created in source code, the size and type
should be determined. When input is provided by the user it
should be verified that it does not exceed the size or the data type
of the memory location in which it is stored or moved in the future.

C6.3 Organizations should test in-house-developed and third-party- 6.3.2 F 1 No mention of automated static
procured web and other application software for coding errors and 6.4.5.3 code analysis software
malware insertion, including backdoors prior to deployment using 6.6
automated static code analysis software. If source code is not
available, these organizations should test compiled code using
static binary analysis tools. In particular, input validation and
output encoding routines of application software should be
carefully reviewed and tested.
C6.4 Organizations should test in-house-developed and third-party- 11.2 F 1
procured web applications for common security weaknesses using 11.2.3
automated remote web application scanners prior to deployment, 11.3.2
whenever updates are made to the application
and on a regular recurring basis.

C6.5 For applications that rely on a database, organizations should - N 0

conduct a configuration review of both the operating system
housing the database and the database software itself, checking
settings to ensure that the database system has been hardened
using standard hardening templates.

C6.6 Organizations should verify that security considerations are taken 6.3 F 1
into account throughout the requirements, design,
implementation, testing, and other phases of the software
development life cycle of all applications.

C6.7 Organizations should ensure that all software development 6.5 F 1 Testing procedure 6.5.a require to
personnel receive training in writing secure code for their specific verify training requirement t
development environment.

C6.8 Require that all in-house-developed software include white-list - N 0

filtering capabilities for all data input and output associated with
the system. These white lists should be configured to allow in or
out only the types of data needed for the system, blocking other
forms of data that are not required.

C6.9 Sample scripts, libraries, components, compilers, or any other - N 0 6.3.1 talks about account removal
unnecessary code that is not being used by an application should 6.4.4 talks about test data removal
be uninstalled or removed from the system. but no mention of scripts,
librairies,...
C7 Critical Control 7: Wireless Device Control 28.13% 4.5
C7.1 Organizations should ensure that each wireless device connected 2.1.1 P 0.5 No mention of documented
to the network matches an authorized configuration and security 4.1.1 configuration
profile, with a documented owner of the connection and a defined 11.1
business need. Organizations should deny access to those wireless
devices that do not have such a configuration and profile.

C7.2 Organizations should ensure that all wireless access points are - N 0
manageable using enterprise management tools. Access points
designed for home use often lack such enterprise management
capabilities, and should therefore be avoided in enterprise
environments.

C7.3 Network vulnerability scanning tools should be configured to 11.1 F 1

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.

C7.4 Organizations should use wireless intrusion detection systems - N 0

(WIDS) to identify rogue wireless devices and detect attack
attempts and successful compromises. In addition to WIDS, all
wireless traffic should be monitored by a wired IDS as traffic passes
into the wired network.

C7.5 802.1x should be used to control which devices are allowed to - N 0

connect to the wireless network.
C7.6 A site survey should be performed to determine what areas within - N 0
the organization need coverage. After the wireless access points
are strategically placed, the signal strength should be tuned to
minimize leakage to areas that do not need coverage.

C7.7 Where a specific business need for wireless access has been - N 0
identified, organizations should configure wireless access on client
machines to allow access only to authorized wireless networks.

C7.8 For devices that do not have an essential wireless business - N 0

purpose, organizations should disable wireless access in the
hardware configuration (basic input/output system or extensible
firmware interface), with password protections to lower the
possibility that the user will override such configurations.

C7.9 Organizations should regularly scan for unauthorized or 11.1 F 1

misconfigured wireless infrastructure devices, using techniques
such as “war driving” to identify access points and clients accepting
peer-to-peer connections. Such unauthorized or misconfigured
devices should be removed from the network, or have their
configurations altered so that they comply with the security
requirements of the organization.

C7.10 Organizations should ensure that all wireless traffic leverages at 4.1.1. F 1 PCI DSS doesn't specify an
least Advanced Encryption Standard (AES) encryption used with at encryption algorithm.
least WiFi Protected Access 2 protection.
C7.11 Organizations should ensure that wireless networks use - N 0
authentication protocols such as Extensible Authentication
Protocol-Transport Layer Security (EAP/TLS) or Protected
Extensible Authentication Protocol (PEAP), which provide
credential protection and mutual authentication.

C7.12 Organizations should ensure that wireless clients use strong, multi- - N 0
factor authentication credentials to mitigate the risk of
unauthorized access from compromised credentials.

C7.13 Organizations should disable peer-to-peer wireless network - N 0

capabilities on wireless clients, unless such functionality meets a
documented business need.

C7.14 Organizations should disable wireless peripheral access of devices - N 0

(such as Bluetooth), unless such access is required for a
documented business need.

C7.15 Wireless access points should never be directly connected to the 1.2.3 F 1
private network. They should either be placed behind a firewall or
put on a separate VLAN so all traffic can be examined and filtered.

C7.16 Organizations should configure all wireless clients used to access - N 0

agency networks or handle organization data in a manner so that
they cannot be used to connect to public wireless networks or any
other networks beyond those specifically allowed by the agency.

C8 Critical Control 8: Data Recovery Capability 40.00% 2

C8.1 - N 0 10.5.3 requires backup of audit
trail files

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.
C8.2 - N 0
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.
C8.3 - N 0

Key personal should be trained on both the backup and restoration

processes. To be ready in case a major incident occurs, alternative
personnel should also be trained on the restoration process just in
case the primary IT point of contact is not available.
C8.4 3.4 F 1
9.5
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.
C8.5 Backup media, such as hard drives and tapes, should be stored in 9.5 F 1
physically secure, locked facilities.

C9 Critical Control 9: Security Skills Assessment and 33.33% 2

Appropriate Training to Fill Gaps
C9.1 12.6 F 1
Organizations should develop security 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.
C9.2 12.6 F 1

Awareness should be carefully validated with policies and training.

Policies tell users what to do, training provides them the skills to
do it, and awareness changes their behavior so that they
understand the importance of following the policy.
C9.3 - N 0 could be included in 12.6
Metrics should be created for all policies and measured on a (awareness program).
regular basis. Awareness should focus on the areas that are
receiving the lowest compliance score.
C9.4 - N 0 No determination/validation of
level of understanding
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.
C9.5 - N 0

Organizations should conduct periodic exercises to verify that

employees and contractors are fulfilling their information security
duties by conducting tests to see whether employees will click on a
link from suspicious e-mail or provide sensitive information on the
telephone without following appropriate procedures for
authenticating a caller.
C9.6 - N 0
Provide awareness sessions for users who are not following
policies after they have received appropriate training.
C10 Critical Control 10: Secure Configurations for 50.00% 4
Network Devices such as Firewalls, Routers, and
Switches
C10.1 Compare firewall, router, and switch configuration against 1.2.2 F 1
standard secure configurations defined for each type of network 1.1.5
device in use in the organization. The security configuration of such 1.1.6
devices should be documented, reviewed, and approved by an 2.2
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.

C10.2 At network interconnection points—such as Internet gateways, 1.2 F 1

inter- organization connections, and internal network segments 1.2.1
with different security controls—implement ingress and egress 1.1.5
filtering to allow only those ports and protocols with an explicit
and documented business need. All other ports and protocols
should be blocked with default-deny rules by firewalls, network-
based IPS, and/or routers.

C10.3 Network devices that filter unneeded services or block attacks - N 0

(including firewalls, network-based IPS, routers with access control
lists, etc.) should be tested under laboratory conditions with each
given organization’s configuration to ensure that these devices
exhibit failure behavior in a closed/blocking fashion under
significant loads with traffic including a mixture of legitimate,
allowed traffic for that configuration intermixed with attacks at line
speeds.
C10.4 All new configuration rules beyond a baseline-hardened 1.1 F 1
configuration that allow traffic to flow through network security 1.1.1
devices, such as firewalls and network-based IPS, should be 1.1.2
documented and recorded in a configuration management system, 1.1.4
with a specific business reason for each change, a specific 1.1.5
individual’s name responsible for that business need, and an 1.1.6
expected duration of the need. At least once per quarter, these
rules should be reviewed to determine whether they are still
required from a business perspective. Expired rules should be
removed.

C10.5 Network filtering technologies employed between networks with - N 0

different security levels (firewalls, network-based IPS tools, and
routers with access controls lists) should be deployed with
capabilities to filter Internet Protocol version 6 (IPv6) traffic.
However, if IPv6 is not currently being used it should be disabled.
Since many operating systems today ship with IPv6 support
activated, filtering technologies need to take it into account.

C10.6 Network devices should be managed using two-factor 2.3 F 1

authentication and encrypted sessions. Only true two-factor 8.3
authentication mechanisms should be used, such as a password
and a hardware token, or a password and biometric device.
Requiring two different passwords for accessing a system is not
two-factor authentication.

C10.7 The latest stable version of a network device’s inter-network - N 0

operating system (IOS) or firmware must be installed within 30
days of the update being released from the device vendor.
C10.8 The network infrastructure should be managed across network - N 0
connections that are separated from the business use of that
network, relying on separate VLANs or, preferably, on entirely
different physical connectivity for management sessions for
network devices.

C11 Critical Control 11: Limitation and Control of 41.67% 2.5

Network Ports, Protocols, and Services

C11.1 Host-based firewalls or port filtering tools should be applied on - N 0

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 11.2.1 P 0.5 Part of the discovery phasis of a
against all key servers and compared to a known effective baseline. 11.2.2 newtork scan. Although, specific
If a new port is found open, an alert should be generated and 11.2.3 reports should be built to list these
reviewed. discrepencies.

C11.3 Any server that is visible from the Internet or an untrusted network - N 0
should be verified, and if it is not required for business purposes it
should be moved to an internal VLAN and given a private address.

C11.4 Services needed for business use across the internal network 1.1.5 P 0.5 1.1.5 is the closest requirement
should be reviewed quarterly via a change control group, and related to busines justification. No
business units should re- justify the business use. Sometimes mention of regular review.
services are turned on for projects or limited engagements, and
should be turned off when they are no longer needed.
C11.5 Operate critical services on separate physical host machines, such 2.2.1 F 1
as DNS, file, mail, web, and database servers.

C11.6 Application firewalls should be placed in front of any critical 6.6 P 0.5 PCI leaves the choice between a
servers to verify and validate the traffic going to the server. Any WAF or code-review.
unauthorized services or traffic should be blocked and an alert
generated.

C12 Critical Control 12: Controlled Use of 53.57% 7.5

Administrative Privileges
C12.1 Organizations should inventory all administrative passwords - N 0

C12.1. and validate that each person with administrative privileges on 7.1 P 0.5 General statement. Not talk
desktops, laptops, and servers is authorized by a senior executive specifically of Admin privileges.
C12.1. and that his/her administrative password has at least 12 semi- 8.5.10 P 0.5 General requirement of at least 7
random characters, consistent with the FDCC standard. characters. No specific req for
admin

C12.2 Before deploying any new devices in a networked environment, 2.1 F 1

organizations should change all default passwords for applications,
operating systems, routers, firewalls, wireless access points, and
other systems to a difficult-to-guess value.

C12.3 Organizations should configure all administrative-level accounts to 8.5.9 F 1 General requirement: 90 days. No
require regular password changes on a frequent interval of no specific requirement for admin
longer than 60 days. accounts.

C12.4 Organizations should ensure all service accounts have long and - N 0 Service account passwords aren't
difficult-to- guess passwords that are changed on a periodic basis, addressed.
as is done for traditional user and administrator passwords, at a
frequent interval of no longer than 90 days.
C12.5 Passwords for all systems should be stored in a well-hashed or 8.4 F 1
encrypted format.
C12.5. Furthermore, files containing these encrypted or hashed - N 0
passwords required for systems to authenticate users should be
readable only with superuser privileges.

C12.6 Organizations should ensure that administrator accounts are used - N 0

only for system administration activities, and not for reading e-
mail, composing documents, or surfing the Internet.

C12.6. Web browsers and e-mail clients especially must be configured to - N 0

never run as administrator.
C12.7 Through policy and user awareness, organizations should require - N 0
that administrators establish unique, different passwords for their
administrator and nonadministrative accounts. Each person
requiring administrative access should be given his/her own
separate account. Administrative accounts should never be shared.
Users should only use the Windows “administrator” or Unix “root”
accounts in emergency situations.

C12.8 Organizations should configure operating systems so that 8.5.12 P 0.5

passwords cannot be re-used within a certain timeframe, such as
six months.

C12.9 Organizations should implement focused auditing on the use of 10.2.2 F 1

administrative privileged functions and monitor for anomalous
behavior (e.g., system reconfigurations during the night shift).

C12.10 Organizations should configure systems to issue a log entry and 10.2.2 P 0.5 10.2.2 is the closest requirement
alert when an account is added to or removed from a domain
administrators group.
C12.11 All administrative access, including domain administrative access, - N 0 8.3 Two-factor only required for
should use two-factor authentication. remote access.
C12.12 Access to a machine (either remotely or locally) should be blocked - N 0
for administrator-level accounts. Instead, administrators should be
required to access a system using a fully logged and
nonadministrative account. Then, once logged in to the machine
without administrative privileges, the administrator should then
transition to administrative privileges using tools such as sudo on
Linux/UNIX, Runas on Windows, and other similar facilities for
other types of systems.

C12.13 If services are outsourced to third parties, language should be 12.8.2 F 1

included in the contracts to ensure that they properly protect and
control administrative access. It should be validated that they are
not sharing passwords and have accountability to hold
administrators liable for their actions.

C12.14 Organizations should segregate administrator accounts based on 7.2 P 0.5

defined roles within the organization. For example, “Workstation 7.2.2
admin” accounts should only be allowed administrative access of
workstations, laptops, etc.

C13 Critical Control 13: Boundary Defense 50.00% 6.5

C13.1 Organizations should deny communications with (or limit data flow - N 0
to) known malicious IP addresses (black lists) or limit access to
trusted sites (white lists). Lists of bogon addresses (unroutable or
otherwise unused IP addresses) are publicly available on the
Internet from various sources, and indicate a series of IP addresses
that should not be used for legitimate traffic traversing the
Internet.

C13.1. Tests can be periodically carried out by sending packets from 1.1.1 P 0.5
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 11.4 F 1
systems and networks that look for unusual attack mechanisms
and detect compromise of these systems. These network-based
IDS sensors may detect attacks through the use of
signatures, network behavior analysis, or other mechanisms to
analyze traffic.

C13.3 Network-based IPS devices should be deployed to compliment IDS 11.4 F 1

by
blocking known bad signature or behavior of attacks. As attacks
become automated, methods such as IDS typically delay the
amount of time it takes for someone to react to an attack. A
properly configured network-based IPS can provide automation to
block bad traffic.
C13.4 On DMZ networks, monitoring systems (which may be built in to - N 0
the IDS sensors or deployed as a separate technology) should be
configured to record at least packet header information, and
preferably full packet header and payloads of the traffic destined
for or passing through the network border. This traffic should be
sent to a properly configured Security Event Information
Management (SEIM) system so that events can be correlated from
all devices on the network.

C13.5 Define a network architecture that clearly separates internal 1.1.3 F 1

systems from DMZ and extranet systems. DMZ systems are 1.3.7
machines that need to communicate with the internal network as
well as the Internet, while extranet systems are those whose
primary communication is with other systems at a business
partner. DMZ systems should never contain sensitive data and
internal systems should never be directly accessible from the
Internet.

C13.6 Design and implement network perimeters so that all outgoing - N 0

web, file transfer protocol (FTP), and secure shell traffic to the
Internet must pass through at least one proxy on a DMZ network.
The proxy should support logging individual TCP sessions; blocking
specific URLs, domain names, and IP addresses to implement a
black list; and applying white lists of allowed sites that can be
accessed through the proxy while blocking all other sites.
Organizations should force outbound traffic to the Internet
through an authenticated proxy server on the enterprise
perimeter. Proxies can also be used to encrypt all traffic leaving an
organization.
C13.7 Require all remote login access (including VPN, dial-up, and other 8.3 F 1
forms of access that allow login to internal systems) to use two-
factor authentication.

C13.8 All devices remotely logging into the internal network should be - N 0
managed by the enterprise, with remote control of their
configuration, installed software,
and patch levels.

C13.9 Organizations should periodically scan for back-channel 11.1 F 1 Discovery

connections to the Internet that bypass the DMZ, including 11.2
unauthorized VPN connections and dual-homed hosts connected 11.3
to the enterprise network and to other networks via wireless, dial-
up modems, or other mechanisms.

C13.10 To limit access by an insider or malware spreading on an internal 1.3.7 P 0.5

network, organizations should devise internal network
segmentation schemes to limit traffic to only those services
needed for business use across the internal network.

C13.11 Organizations should develop plans to rapidly deploy filters on - N 0

internal networks to help stop the spread of malware or an
intruder.

C13.12 To minimize the impact of an attacker pivoting between 6.6 P 0.5

compromised systems, only allow DMZ systems to communicate
with private network systems via application proxies or
application-aware firewalls over approved channels
C13.13 To help identify covert channels exfiltrating data through a firewall, - N 0
built-in firewall session tracking mechanisms included in many
commercial firewalls should be configured to identify TCP sessions
that last an unusually long time for the given organization and
firewall device, alerting personnel about the source and
destination addresses associated with these long sessions.

C14 Critical Control 14: Maintenance, Monitoring, and 68.75% 5.5

Analysis of Audit Logs
C14.1 Validate audit log settings for each hardware device and the 10.2 F 1
software installed on it, ensuring that logs include a date, 10.3
timestamp, source addresses, destination addresses, and various
other useful elements of each packet and/or transaction.

C14.1. Systems should record logs in a standardized format such as syslog - N 0

entries or those outlined by the Common Event Expression
initiative. If systems cannot generate logs in a standardized format,
log normalization tools can be deployed to convert logs into a
standardized format.

C.14.2 Ensure that all systems that store logs have adequate storage - N 0
space for the logs generated on a regular basis, so that log files will
not fill up between log rotation intervals.

C14.2. The logs must be archived and digitally signed on a periodic basis. 10.5 P 0.5 No requirement for digital
10.5.3 signature
C14.2 All remote access to a network, whether to the DMZ or the internal - N 0 Not specific requirement for
network (i.e., VPN, dial-up, or other mechanism), should be logged remote access
verbosely.
C.14.3 Operating systems should be configured to log access control 10.2.1 - F 1 Resource = CC data
events associated with a user attempting to access a resource (e.g., 10.2.7
a file or directory) without the appropriate permissions. Failed 10.3.4
logon attempts must also be logged.

C14.4 Security personnel and/or system administrators should run 10.6 F 1

biweekly reports that identify anomalies in logs. They should then
actively review the anomalies, documenting their findings.

C.14.5 Each organization should include at least two synchronized time 10.4 P 0.5 Don't mention about # of time
sources (i.e., Network Time Protocol – NTP) from which all servers (10.4.3) synchronization sources
and network equipment retrieve time information on a regular
basis so that timestamps in logs are consistent.

C14.6 Network boundary devices, including firewalls, network-based IPS, 10.2 P 0.5 No specific mention of such
and inbound and outbound proxies, should be configured to 10.6 devices
verbosely log all traffic (both allowed and blocked) arriving at the
device.

C14.7 For all servers, organizations should ensure that logs are written to 10.5.4 F 1
write-only devices or to dedicated logging servers running on
separate machines from hosts generating the event logs, lowering
the chance that an attacker can manipulate logs stored locally on
compromised machines.
C14.8 Organizations should deploy a SEIM system tool for log aggregation - N 0 No mention of SEIM
and consolidation from multiple machines and for log correlation
and analysis. Standard government scripts for analysis of the logs
should be deployed and monitored, and customized local scripts
should also be used. Using the SEIM tool, system administrators
and security personnel should devise profiles of common events
from given systems so that they can tune detection to focus on
unusual activity, avoid false positives, more rapidly identify
anomalies, and prevent overwhelming analysts with insignificant
alerts.

C15 Critical Control 15: Controlled Access Based on the 28.57% 2

Need to Know
C15.1 Organizations should establish a multi-level data - N 0 Could be part of a risk assessment
identification/classification scheme (e.g., a three- or four-tiered methodology.
scheme with data separated into categories based on the impact
of exposure of the data).

C15.2 Organizations should ensure that file shares have defined controls - N 0
(such as Windows share access control lists) that specify at least
that only “authenticated users” can access the share.

C15.3 Organizations should enforce detailed audit logging for access to 7.2 P 0.5 7.2 is the closest requiremement
nonpublic data and special authentication for sensitive data.

C15.4 The network should be segmented based on the trust levels of the 1.2 P 0.5
information stored on the servers. 1.3
C15.4. Whenever information flows over a network of lower trust level, 4.1 F 1
the information should be encrypted.
C15.5 The use of portable USB drives should either be limited or data - N 0
should automatically be encrypted before it is written to a portable
drive.

C15.6 Host-based data loss prevention (DLP) should be used to enforce - N 0

ACLs even when data is copied off a server. In most organizations,
access to the data is controlled by ACLs that are implemented on
the server. Once the data have been copied to a desktop system
the ACLs are no longer enforced and the users can send the data to
whomever they want.

C15.7 Deploy honeytokens on key servers to identify users who might be - N 0

trying to access information that they should not access.

C16 Critical Control 16: Account Monitoring and Control 68.18% 7.5
C16.1 Review all system accounts and disable any account that cannot be - N 0
associated with a business process and owner.
C16.2 Systems should automatically create a report on a daily basis that - N 0
includes a list of locked-out accounts, disabled accounts, accounts
with passwords that exceed the maximum password age, and
accounts with passwords that never expire. This list should be sent
to the associated system administrator in a secure fashion.

C16.3 Organizations should establish and follow a process for revoking 8.5.4 F 1
system access by disabling accounts immediately upon termination
of an employee or contractor.
C16.4 Organizations should regularly monitor the use of all accounts, 8.5.6 F 1
automatically 8.5.15
logging off users after a standard period of inactivity.

C16.5 Organizations should monitor account usage to determine 8.5.5 F 1 PCI less restrictive (90 days)
dormant accounts
that have not been used for a given period, such as 30 days,
notifying the user or user’s manager of the dormancy. After a
longer period, such as 60 days, the account should be disabled.

C16.6 When a dormant account is disabled, any files associated with that - N 0
account should be encrypted and moved to a secure file server for
analysis by security or management personnel.

C16.7 All nonadministrator accounts should be required to have a 8.5.10 P 0.5 PCI les restrictive (7 characters)
minimum length of 12 characters,
C16.7. contain letters, numbers, and special characters 8.5.11 P 0.5 PCI less restrictive (No special
characters)
C16.7. be changed at least every 90 days, have a minimal age of one day, 8.5.9 F 1 PCI is also 90 days

C1.7.3 and not be allowed to use the previous 15 passwords as a new 8.5.12 P 0.5 PCI less restrictive (the last 4)
password.
C16.8 After eight failed logon attempts within a 45-minute period, the 8.5.13 F 1 PCI more restrictive (6 attempts)
account should be locked
C16.8. for 120 minutes. 8.5.14 P 0.5 PCI less restrictive (30 minutes or
unlocked by administrator)
C16.9 On a periodic basis, such as quarterly or at least annually, 12.2 P 0.5 Partially covered through the
organizations should require that managers match active requirement for a User account
employees and contractors with each account belonging to their maintenance procedure.
managed staff. Security or system administrators should then
disable accounts that are not assigned to active employees or
contractors.

C16.10 Organizations should monitor attempts to access deactivated - N 0

accounts through audit logging.
C16.11 Organizations should profile each user’s typical account usage by - N 0
determining normal time-of-day access and access duration for
each user. Daily reports should be generated that indicate users
who have logged in during unusual hours or have exceeded their
normal login duration by 150 percent.

C17 Critical Control 17: Data Loss Prevention 30.00% 3

C17.1 Organizations should deploy approved hard drive encryption - N 0
software to mobile machines that hold sensitive data.

C17.2 Network monitoring tools should analyze outbound traffic looking 10.0 F 1
for a variety of anomalies, including large file transfers, long-time
persistent connections, connections at regular repeated intervals,
unusual protocols and ports in use, and possibly the presence of
certain keywords in the data traversing the network perimeter.
C17.3 Deploy an automated tool on network perimeters that monitors - N 0
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
security personnel.

C17.4 Conduct periodic scans of server machines using automated tools - N 0

to determine whether sensitive data (i.e., personally identity,
health, credit card, and classified information) is present on the
system in clear text. These tools, which search for patterns that
indicate the presence of sensitive information, can help identify if a
business or technical process is leaving behind or otherwise leaking
sensitive information in data at rest.

C17.5 Use outbound proxies to be able to monitor and control all - N 0

information leaving an organization.
C17.6 Data should be moved between networks using secure, 4.00 F 1 PCI requires encryption only
authenticated, and encrypted mechanisms. through public network
C17.7 Data stored on removable and easily transported storage media 3.4 F 1
such as USB tokens (i.e., “thumb drives”), USB portable hard drives,
and CDs/DVDs should be encrypted. Systems should be configured
so that all data written to such media are automatically encrypted
without user intervention.
C17.8 If there is no business need for supporting such devices, - N 0
organizations should configure systems so that they will not write
data to USB tokens or USB hard drives. If such devices are
required, enterprise software should be used that can configure
systems to allow only specific USB devices (based on serial number
or other unique property) to be accessed, and that can
automatically encrypt all data placed on such devices. An inventory
of all authorized devices must be maintained.

C17.9 Use network-based DLP solutions to monitor and control the flow - N 0
of data within the network. Any anomalies that exceed the normal
traffic patterns should be noted and appropriate action taken to
address them,.

C17.1 Monitor all traffic leaving the organization and detect any - N 0
0 unauthorized use of encryption. Attackers often use an encrypted
channel to bypass network security devices. Therefore it is
essential that organizations are able to detect rogue connections,
terminate the connection, and remediate the infected system.

C18 Critical Control 18: Incident Response Capability 100.00% 6

C18.1 12.5.3 F 1
12.9
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 12.9.1 F 1
Organizations should assign job titles and duties for handling
computer and network incidents to specific individuals.
C18.3 12.9.1 F 1
Organizations should define management personnel who will
support the incident handling process by acting in key decision-
making roles.
C18.4 12.9.1 F 1

Organizations should devise organization-wide standards for the

time required for system administrators and other personnel to
report anomalous events to the incident handling team, the
mechanisms for such reporting, and the kind of information that
should be included in the incident notification. This reporting
should also include notifying the appropriate US Community
Emergency Response Team in accordance with all government
requirements for involving that organization in computer incidents.
C18.5 12.9.4 F 1
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.
C18.6 12.9.4 F 1

Organizations should conduct periodic incident scenario sessions

for personnel associated with the incident handling team to ensure
that they understand current threats and risks, as well as their
responsibilities in supporting the incident handling team.

C19 Critical Control 19: Secure Network Engineering 50.00% 2.5

C19.1 The network should be designed using a minimum of a three-tier 1.3 F 1
architecture (DMZ, middleware, and private network). Any system 1.3.1
accessible from the Internet should be on the DMZ, but DMZ 1.3.2
systems never contain sensitive data. Any system with sensitive 1.3.3
data should reside on the private network and never be directly
accessible from the Internet. DMZ systems should communicate
with private network systems through an application proxy
residing on the middleware tier.

C19.2 To support rapid response and shunning of detected attacks, the - N 0

network architecture and the systems that make it up should be
engineered for rapid deployment of new access control lists, rules,
signatures, blocks, blackholes, and other defensive measures.

C19.3 DNS should be deployed in a hierarchical, structured fashion, with - N 0

all internal network client machines configured to send requests to
intranet DNS servers, not to DNS servers located on the Internet.
These internal DNS servers should be configured to forward
requests they cannot resolve to DNS servers located on a
protected DMZ. These DMZ servers, in turn, should be the only
DNS servers allowed to send requests to the Internet.

C19.4 Security should be built into all phases of the software 6.3 F 1
development lifecycle, ensuring that any security issues are
addressed as early as possible.

C19.5 Organizations should segment the enterprise network into 1.3 P 0.5 Network segmentation is
multiple, separate trust zones to provide more granular control of addressed as a way to reduce the
system access and additional intranet boundary defenses. scope of the assessment.
C20 Critical Control 20: Penetration Tests and Red 35.71% 2.5
Team Exercises
C20.1 Organizations should conduct regular external and internal 11.3 F 1
penetration tests to identify vulnerabilities and attack vectors that
can be used to exploit enterprise systems successfully. Penetration
testing should occur from outside the network perimeter (i.e., the
Internet or wireless frequencies around an organization) as well as
from within its boundaries (i.e., on the internal network) to
simulate both outsider and insider attacks.

C20.2 Organizations should perform periodic red team exercises to test - N 0

the readiness of organizations to identify and stop attacks or to
respond quickly and effectively.

C20.3 Organizations should ensure that systemic problems discovered in 11.3b F 1 Noted exploitable vulnerabilities
penetration tests and red team exercises are fully mitigated. must be corrected
C20.4 - N 0

Organizations should measure how well the organization has

reduced the significant enablers for attackers by setting up
automated processes to find:
o Cleartext e-mails and documents with “password” in the
filename or body o Critical network diagrams stored online and in
cleartext
o Critical configuration files stored online and in cleartext
o Vulnerability assessment, penetration test reports, and red team
finding
documents stored online and in cleartext
o Other sensitive information identified by management personnel
as critical to the
operation of the enterprise during the scoping of a penetration
test or red team
exercise.
C20.5 Supplement P 0.5 Social engineering is mentionned
within the Supplemental document
Social engineering should be included within a penetration test. about pen test
The human element is often the weakest link in an organization
and one that attackers
often target.
C20.6 - N 0

Organizations should devise a scoring method for determining the

results of
red team exercises so that results can be compared over time.
C20.7 - N 0
Organizations should create a test bed that mimics a production
environment
for specific penetration tests and red team attacks against
elements that are not typically tested in production, such as
attacks against supervisory control and data acquisition and other
control systems.
Return to Table of content
Report here under all vulnerability scans executed.

Date Int/Ext Scanning solution Operator or ASV's IP’s (FAIL/PASS) Report

location
Return to Table of content
Report here under all penetration tests executed.

Date Int/Ext Tests provider IP’s # exploitable Report location

vulnerabilities
Training and other knowledge
evidences required by PCI DSS V3.0. Use this sheet to list the training evidences

Return to table of content

Security Awareness sessions (all staff)
Training Provided Audience Date

Secure Coding training for developers and code reviewers 6.5

Training Provided Audience Date

Training for Point-on-Sale personel on tampering and substitution of devices.

Training Provided Audience Date 9.9.3

Training for staff with Security breach response responsibilities 10.4

Training Provided Audience Date
Training and other knowledge
evidences required by PCI DSS V3.0. Use this sheet to list the training evidences

Others PCI Req Yes/No Evidences

System administrators and security managers have knowledge of common security 2.2.4b
parameter settings for system components they are responsible for

Personnel knows security policies and operational procedures for managing vendor defaults 2.2.5
and other security parameters

Cryptographic key custodians understand and accept their key-custodian responsibilities. 3.6.8

Security policies and operational procedures for protecting stored cardholder data are 3.7
known to all affected parties.

Security policies and operational procedures for encrypting transmissions of cardholder data 4.3
are known to all affected parties.

Security policies and operational procedures for protecting systems against malware are 5.4
known to all affected parties.

Security policies and operational procedures for developing and maintaining secure systems 6.7
and applications are known to all affected parties.

Security policies and operational procedures for restricting access to cardholder data are 7.3
known to all affected parties.

Security policies and operational procedures for identification and authentication are known 8.8
to all affected parties.
Training and other knowledge
evidences required by PCI DSS V3.0. Use this sheet to list the training evidences

Security policies and operational procedures for restricting physical access to cardholder 9.10
data are known to all affected parties.

Security policies and operational procedures for monitoring all access to network resources 10.8
and cardholder data are known to all affected parties.

Security policies and operational procedures for security monitoring and testing are known 11.6
to all affected parties.

Personnel understands the security policies, their roles and responsibilities 12.4
Return toare
Firewalls Table of content
devices Go tobetween
that control computer traffic allowed requirement 2 networks (internal) and untrusted networks (external),
an entity’s
A firewall examines all network traffic and blocks those transmissions that do not meet the specified security criteria.
Requirement
All systems must1:beInstall andfrom
protected maintain a firewall
unauthorized accessconfiguration to protect
from untrusted networks, cardholder
whether enteringdata
the system via the Internet as e-
Other system components may provide firewall functionality, provided they meet the minimum requirements for firewalls as provided

Major Observations from the Verizon 2014 PCI Compliance Report:

12.5% of organizations that suffered a data breach in 2013 were compliant with Requirement 1 at the time of their breach.
46.7% compliance with Requirement 1 in 2013.
most organizations ranked high in addressing thebasic security practices like 1.1.3.a, 1.2.1.b, and 1.3.6.
Compliance with 1.1.5 and 1.1.6.b addressing the documentation and reviewing of firewalls and routers was considerably low. Just 52

PCI DSS Requirement Guidance

1.1 Establish firewall and router configuration Firewalls and routers are key components of the
standards that include the following: architecture that controls entry to and exit from the
network. These devices are software or hardware
devices that block unwanted access and manage
authorized access into and out of the network. Without
policies and procedures in place to document how staff
should configure firewalls and routers, a business could
easily lose its first line of defense in data-protection. The
policies and procedures will help to ensure that the
organization’s first line of defense in the protection of its
data remains strong.
Virtual environments where data flows do not transit a
physical network should be assessed to ensure
appropriate network segmentation is achieved.

1.1.1 A formal process for approving and testing all A policy and process for approving and testing all
network connections and changes to the firewall connections and changes to the firewalls and
and router configurations routers will help prevent security problems caused
by misconfiguration of the network, router, or
firewall.
Data flows between virtual machines should be
included in policy and process
1.1.2 Current network diagram that identifies all Network diagrams describe how networks are
connections between the cardholder data configured, and identify the location of all network
environment and other networks, including any devices.
wireless networks. Without current network diagrams, devices could
be overlooked and be unknowingly left out of the
security controls implemented for PCI DSS and thus
be vulnerable to compromise.
1.1.3 Current diagram that shows all cardholder Cardholder data-flow diagrams identify the location
data flows across systems and networks of all cardholder data that is stored, processed, or
transmitted within the network.
Network and cardholder data-flow diagrams help
an organization to understand and keep track of the
scope of their environment, by showing how
cardholder data flows across networks and
between individual systems and devices.

1.1.4 Requirements for a firewall at each Internet Using a firewall on every connection coming into (and
connection and between any demilitarized zone out of) the network allows the organization to monitor
(DMZ) and the internal network zone and control access in and out, and to minimize the
chances of a malicious individual’s obtaining access to
the internal network.

1.1.5 Description of groups, roles, and This description of roles and assignment of responsibility
responsibilities for logical management of ensures that someone is clearly responsible for the
network components security of all components and is aware of their
responsibility, and that no devices are left unmanaged.
1.1.6 Documentation and business justification for Compromises often happen due to unused or insecure
use of all services, protocols, and ports allowed, service and ports, since these often have known
including documentation of security features vulnerabilities—and many organizations are vulnerable
implemented for those protocols considered to be to these types of compromises because they do not
insecure. Examples of insecure services, protocols, patch security vulnerabilities for services, protocols, and
or ports include but are not limited to FTP, Telnet, ports they don't use (even though the vulnerabilities are
POP3, IMAP, and SNMP. still present). Each organization should clearly decide
which services, protocols, and ports are necessary for
their business, document them for their records, and
ensure that all other services, protocols, and ports and
disabled or removed. Also, organizations should consider
blocking all traffic and only re-opening those ports once
a need has been determined and documented.
Additionally, there are many services, protocols, or ports
that a business may need (or have enabled by default)
that are commonly used by malicious individuals to
compromise a network. If these insecure services,
protocols, or ports are necessary for business, the risk
posed by use of these protocols should be clearly
understood and accepted by the organization, the use of
the protocol should be justified, and the security
features that allow these protocols to be used securely
should be documented and implemented. If these
insecure services, protocols, or ports are not necessary
for business, they should be disabled or removed.

1.1.7 Requirement to review firewall and router This review gives the organization an opportunity
rule sets at least every six months at least every six months to clean up any
unneeded, outdated, or incorrect rules, and ensure
that all rule sets allow only authorized services and
ports that match business justifications.
It is advisable to undertake these reviews on a
more frequent basis, such as monthly, to ensure
that the rule sets are current and match the needs
of the business without opening security holes and
running unnecessary risks.
1.2 Build firewall and router configurations that It is essential to install network protection, namely a
restrict connections between untrusted networks system component with (at a minimum) stateful
and any system components in the cardholder data inspection firewall capability, between the internal,
environment. trusted network and any other untrusted network that is
external and/or out of the entity’s ability to control or
Note: An “untrusted network” is any network that is manage. Failure to implement this measure correctly
external to the networks belonging to the entity means that the entity will be vulnerable to unauthorized
under review, and/or which is out of the entity's access by malicious individuals or software.
ability to control or manage.
If firewall functionality is installed but does not have
rules that control or limit certain traffic, malicious
individuals may still be able to exploit vulnerable
protocols and ports to attack your network.

1.2.1 Restrict inbound and outbound traffic to that This requirement is intended to prevent malicious
which is necessary for the cardholder data individuals from accessing the organization's network via
environment. unauthorized IP addresses or from using services,
protocols, or ports in an unauthorized manner (for
example, to send data they've obtained from within your
network out to an untrusted server.
All firewalls should include a rule that denies all inbound
and outbound traffic not specifically needed. This will
prevent inadvertent holes that would allow other,
unintended and potentially harmful traffic in or out.

1.2.2 Secure and synchronize router configuration While running configuration files are usually
files. implemented with secure settings, the start-up files
(routers run these files only upon re-start) may not be
implemented with the same secure settings because
they only run occasionally. When a router does re-start
without the same secure settings as those in the running
configuration files, it may result in weaker rules that
allow malicious individuals into the network, because the
start-up files may not be implemented with the same
secure settings as the running configuration files.
1.2.3 Install perimeter firewalls between any The known (or unknown) implementation and
wireless networks and the cardholder data exploitation of wireless technology within a network is a
environment, and configure these firewalls to deny common path for malicious individuals to gain access to
or control (if such traffic is necessary for business the network and cardholder data. If a wireless device or
purposes) any traffic from the wireless environment network is installed without a company’s knowledge, a
into the cardholder data environment. 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.

Firewalls must be installed between all wireless networks

and the CDE, regardless of the purpose of the
environment to which the wireless network is
connected. This may include, but is not limited to,
corporate networks, retail stores, warehouse
environments, etc.

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

1.3.2 Limit inbound Internet traffic to IP Termination of IP connections at the DMZ provides
addresses within the DMZ. opportunity for inspection and restriction of
source/destination, and/or inspection / blocking of
content, thus preventing unfiltered access between
untrusted and trusted environments.

1.3.3 Do not allow any direct connections Termination of IP connections both inbound and
inbound or outbound for traffic between the outbound provides opportunity for inspection and
Internet and the cardholder data environment. restriction of source/destination, and/or inspection /
blocking of content, thus preventing unfiltered access
between untrusted and trusted environments. This helps
prevent, for example, malicious individuals from sending
data they've obtained from within your network out to
an external untrusted server in an untrusted network.

1.3.4 Implement anti-spoofing measures to Normally a packet contains the IP address of the
detect and block forged source IP addresses from computer that originally sent it so other computers in
entering the network. the network know where the packet came from.
Malicious individuals will often try to spoof (or imitate)
(For example, block traffic originating from the the sending IP address so that the target system
Internet with an internal source address.) believes the packet is from a trusted source.
Filtering packets coming into the network helps to,
among other things, ensure packets are not
“spoofed” to look like they are coming from an
organization’s own internal network.
1.3.5 Do not allow unauthorized outbound traffic All traffic outbound from inside the cardholder data
from the cardholder data environment to the environment should be evaluated to ensure that
Internet. outbound traffic follows established, authorized rules.
Connections should be inspected to restrict traffic to
only authorized communications (for example by
restricting source/destination addresses/ports, and/or
blocking of content).
Where environments have no inbound connectivity
allowed, outbound connections may be achieved via
architectures or system components that interrupt
and inspect the IP connectivity.

1.3.6 Implement stateful inspection, also known A firewall that performs stateful packet inspection
as dynamic packet filtering. (That is, only keeps "state" (or the status) for each connection to
“established” connections are allowed into the the firewall. By keeping "state," the firewall knows
network.) whether what appears to be a response to a previous
connection is truly a response (since it "remembers"
the previous connection) or is a malicious individual or
software trying to spoof or trick the firewall into
allowing the connection.

1.3.7 Place system components that store Cardholder data requires the highest level of
cardholder data (such as a database) in an information protection. If cardholder data is located
internal network zone, segregated from the DMZ within the DMZ, access to this information is easier for
and other untrusted networks. an external attacker, since there are fewer layers to
penetrate.
Note: the intent of this requirement does not include
storage in volatile memory.

1.3.8 Do not disclose private IP addresses and Restricting the broadcast of IP addresses is essential to
routing information to unauthorized parties. prevent a hacker “learning” the IP addresses of the
internal network, and using that information to access
Note: Methods to obscure IP addressing may the network.
include, but are not limited to:
Effective means to meet the intent of this requirement
- Network Address Translation (NAT) may vary depending on the specific networking
- Placing servers containing cardholder data technology being used in your environment. For
behind proxy servers/firewalls or content caches, example, the controls used to meet this requirement
- Removal or filtering of route advertisements for may be different for IPv4 networks than for IPv6
private networks that employ registered networks.
addressing,
- Internal use of RFC1918 address space instead of One technique to prevent IP address information from
registered addresses. being discovered on an IPv4 network is to implement
Network Address translation (NAT). NAT, which is
typically managed by the firewall, allows an organization
to have internal addresses that are visible only inside the
network and external address that are visible externally.
If a firewall does not “hide” or mask the IP addresses of
the internal network, a malicious individual could
discover internal IP addresses and attempt to access the
network with a spoofed IP address.
For IPv4 networks, the RFC1918 address space is
reserved for internal addressing, and should not be
routable on the Internet. As such, it is preferred for IP
addressing of internal networks. However, organizations
may have reasons to utilize non-RFC1918 address space
on the internal network. In these circumstances,
prevention of route advertisement or other techniques
should be used to prevent internal address space being
broadcast on the Internet or disclosed to unauthorized
parties.
behind proxy servers/firewalls or content caches, example, the controls used to meet this requirement
- Removal or filtering of route advertisements for may be different for IPv4 networks than for IPv6
private networks that employ registered networks.
addressing,
- Internal use of RFC1918 address space instead of One technique to prevent IP address information from
registered addresses. being discovered on an IPv4 network is to implement
Network Address translation (NAT). NAT, which is
typically managed by the firewall, allows an organization
to have internal addresses that are visible only inside the
network and external address that are visible externally.
If a firewall does not “hide” or mask the IP addresses of
the internal network, a malicious individual could
discover internal IP addresses and attempt to access the
network with a spoofed IP address.

For IPv4 networks, the RFC1918 address space is

reserved for internal addressing, and should not be
routable on the Internet. As such, it is preferred for IP
addressing of internal networks. However, organizations
may have reasons to utilize non-RFC1918 address space
on the internal network. In these circumstances,
prevention of route advertisement or other techniques
should be used to prevent internal address space being
broadcast on the Internet or disclosed to unauthorized
parties.

1.4 Install personal firewall software on If a computer does not have a firewall or anti-virus
any mobile and/or employee-owned program installed, spyware, Trojans, viruses, worms and
rootkits (malware) may be downloaded and/or installed
devices that connect to the Internet unknowingly. The computer is even more vulnerable
when outside the network (for example, when directly connected to the Internet and not behind
laptops used by employees), and which the corporate firewall. Malware loaded on a computer
are also used to access the network. when not behind the corporate firewall can then
Firewall configurations include: -Specific maliciously target information within the network when
configuration settings are defined for the computer is re-connected to the corporate network.
personal firewall software.
-Personal firewall software is actively Note: The intent of this requirement applies to remote
running. access computers regardless of whether they are
-Personal firewall software is not employee owned or company owned. Systems that
alterable by users of mobile and/or cannot be managed by corporate policy introduce
employee-owned devices. weaknesses to the perimeter and provide opportunities
that malicious individuals may exploit.
1.5 Ensure that security policies and operational Personnel need to be aware of and following security
procedures for managing firewalls are policies and operational procedures to ensure
documented, in use, and known to all affected firewalls and routers are continuously managed to
parties. prevent unauthorized access to the network.
and untrusted networks (external),Executive
as well assummary
traffic into and out of more sensitive areas within an entity’s internal trusted networks. The cardholde
d security criteria.
r data
ng the system via the Internet as e-commerce, employee Internet access through desktop browsers, employee e-mail access, dedicated connection
quirements for firewalls as provided in Requirement 1. Where other system components are used within the cardholder data environment to provi

the time of their breach.

.3.6.
outers was considerably low. Just 52.5% of companies comply with 1.1.6.b.

SANS Testing Procedure

Top 20 Critical
Security
Controls
C10.4 1.1 Inspect the firewall and router configuration standards and other documentation
specified below and verify that standards are complete and implemented as follows:

C10.4 1.1.1.a Examine documented procedures to verify there is a formal process for
C13.1.1 testing and approval of all:
Network connections, and
Changes to firewall and router configurations.

1.1.1.b For a sample of network connections, interview responsible personnel and

examine records to verify that network connections were approved and tested.
 1.1.1.c Identify a sample of actual changes made to firewall and router,
configurations, compare to the change records, and interview responsible
personnel to verify the changes were approved and tested.

C10.4 1.1.2.a Examine diagram(s) and observe network configurations to verify that a
current network diagram exists and that it documents all connections to cardholder
data, including any wireless networks.

1.1.2.b Interview responsible personnel to verify that the diagram is kept current.
 1.1.3 Examine data-flow diagram and interview personnel to verify the diagram:
􏰁 Shows all cardholder data flows across systems and networks.
􏰁 Is kept current and updated as needed upon changes to the environment.

C13.5 1.1.4.a Examine the firewall configuration standards and verify that they include
requirements for a firewall at each Internet connection and between any DMZ and
the internal network zone.

1.1.4.b Verify that the current network diagram is consistent with the firewall
configuration standards.

1.1.4.c Observe network configurations to verify that a firewall is in place at each

Internet connection and between any demilitarized zone (DMZ) and the internal
network zone, per the documented configuration standards and network diagrams.

C10.4 1.1.5 Verify that firewall and router configuration standards include a description of
groups, roles, and responsibilities for logical management of network components.

1.1.5.b Interview personnel responsible for management of network components to

confirm that roles and responsibilities are assigned as documented.
C10.1 1.1.6.a Verify that firewall and router configuration standards include a
C10.2 documented list of services, protocols and ports necessary for business—for
C10.4 example, hypertext transfer protocol (HTTP) and Secure Sockets Layer (SSL), Secure
C11.4 Shell (SSH), and Virtual Private Network (VPN) protocols.

1.1.6.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.c Examine firewall and router configurations to verify that the documented
security features are implemented for each insecure service, protocol, and port.

C10.1 1.1.7.a Verify that firewall and router configuration standards require review of
C10.4 firewall and router rule sets at least every six months.

1.1.7.b Examine documentation relating to rule set reviews and interview

responsible personnel to verify that the rule sets are reviewed at least every six
months.
C10.2 Left Blank by PCIco
C15.4

C10.2 1.2.1.a Examine firewall and router configurations and perform the following to verify
that connections are restricted between untrusted networks and system components
in the cardholder data environment:

1.2.1.b Examine firewall and router configurations to verify that inbound and
outbound traffic is limited to that which is necessary for the cardholder data
environment.

1.2.1.c Examine firewall and router configurations to verify that all other inbound
and outbound traffic is specifically denied, for example by using an explicit “deny
all” or an implicit deny after allow statement.

C10.1 1.2.2.a Examine router configuration files to verify they are secured from
unauthorized access.

1.2.2.b Examine router configurations to verify they are synchronized—for example,

the running (or active) configuration matches the start-up configuration (used when
machines are booted).
C15.4 1.2.3.a Examine firewall and router configurations to verify that there are perimeter
C7.15 firewalls installed between all wireless networks and the cardholder data
environment.

1.2.3.b Verify that the firewalls deny or, if traffic is necessary for business purposes,
permit only authorized traffic between the wireless environment and the
cardholder data environment.

C19.1
C19.5
C19.1 1.3.1 Examine firewall and router configurations to verify that a DMZ is
implemented to limit inbound traffic to only system components that provide
authorized publicly accessible services, protocols, and ports.

C19.1 1.3.2 Examine firewall and router configurations to verify that inbound Internet
traffic is limited to IP addresses within the DMZ.

C19.1 1.3.3 Examine firewall and router configurations to verify direct connections
inbound or outbound are not allowed for traffic between the Internet and the
cardholder data environment.

C13.5 1.3.4 Examine firewall and router configurations to verify that anti-spoofing
measures are implemented, for example internal addresses cannot pass from the
Internet into the DMZ.
C10.2 1.3.5 Examine firewall and router configurations to verify that outbound traffic from
the cardholder data environment to the Internet is explicitly authorized.

NC 1.3.6 Examine firewall and router configurations to verify that the firewall performs
stateful inspection (dynamic packet filtering). (Only established connections should
be allowed in, and only if they are associated with a previously established session.)

C13.5 1.3.7 Examine firewall and router configurations to verify that system components
C13.10 that store cardholder data are on an internal network zone, segregated from the
DMZ and other untrusted networks.

NC 1.3.8.a Examine firewall and router configurations to 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 Interview personnel and examine documentation to verify that any
disclosure of private IP addresses and routing information to external entities is
authorized.

C5.1.1 1.4.a Examine policies and configuration standards to verify:

Personal firewall software is required for all mobile and/or employee-owned devices
that connect to the Internet (for example, laptops used by employees) when outside
the network, and which are also used to access the network.
Specific configuration settings are defined for personal firewall software.
Personal firewall software is configured to actively run.
Personal firewall software is configured to not be alterable by users of mobile and/or
employee-owned devices.
1.4.b Inspect a sample of mobile and/or employee-owned devices to verify that:

Personal firewall software is installed and configured per the organization’s specific
configuration settings.
Personal firewall software is actively running.
Personal firewall software is not alterable by users of mobile and/or employee-owned
devices.

1.5 Examine documentation and interview personnel to verify that security policies
and operational procedures for managing firewalls are:
Documented,
In use, and
Known to all affected parties
nternal trusted networks. The cardholder data environment is an example of a more sensitive area within an entity’s trusted network.

ee e-mail access, dedicated connections such as business-to-business connections, via wireless networks, or via other sources. Often, seemingly ins
e cardholder data environment to provide firewall functionality, these devices must be included within the scope and assessment of Requirement 1

Selected Merchant Type:

Validation instruction for QSA/ISA Priority A A-EP PE2P

(For In-Place Requirements)

Left Blank by PCIco 0 0 0

Identify the document(s) reviewed to verify procedures define the formal processes 0 0 0
for:

Testing and approval of all network connections.
<Report Findings Here>
 6
Testing and approval of all changes to firewall and router configurations.
<Report Findings Here>

Identify the sample of records for network connections that were examined. 0 0 0
<Report Findings Here>

Identify the responsible personnel interviewed who confirm that network

connections were approved and tested.
<Report Findings Here> 6
Identify the responsible personnel interviewed who confirm that changes made to 0 0 0
firewall and router configurations were approved and tested.
<Report Findings Here>

Describe how change records were compared to actual changes made to firewall
and router configurations to verify the changes were:

Approved
<Report Findings Here>
 6
Tested
<Report Findings Here>

Identify the current network diagram(s) examined. 0 0 0

<Report Findings Here>

Describe how network connections were observed and compared to the diagram(s)
to verify that the diagram:

Is current.
<Report Findings Here>

Includes all connections to cardholder data.
<Report Findings Here>
 1
Includes any wireless network connections.
<Report Findings Here>

Identify the document examined to verify processes require that the network 0 0 0
diagram is kept current.
<Report Findings Here>

Identify the responsible personnel interviewed for this testing procedure.
<Report Findings Here>

For the interview, summarize the relevant details discussed to verify that the
diagram is kept current. 1
<Report Findings Here>
Identify the data-flow diagram(s) examined. 0 0 0
<Report Findings Here>

Identify the responsible personnel interviewed

for this testing procedure.
<Report Findings Here>
For the interview, summarize the relevant details discussed to verify the diagram:

Shows all cardholder data flows across systems and networks.
<Report Findings Here>
 1
Is kept current and updated as needed upon changes to the environment.
<Report Findings Here>

Identify the firewall configuration standards document examined to verify 0 1 0

requirements for a firewall:
At each Internet connection.
Between any DMZ and the internal network zone.
<Report Findings Here> 2

Provide the name of the assessor who attests that the current network diagram 0 1 0
identified at 1.1.2.a was compared to the firewall configuration standards identified
at 1.1.4.a to verify they are consistent with each other.
<Report Findings Here> 2

Describe how network configurations were observed to verify that, per the 0 1 0
documented configuration standards and network diagrams, a firewall is in place:

At each Internet connection.
<Report Findings Here>

Between any DMZ and the internal network zone. 2
<Report Findings Here>

Identify the firewall and router configuration standards document(s) reviewed to 0 0 0

verify they include a description of groups, roles and responsibilities for
management of network components. 6
<Report Findings Here>

Identify the personnel responsible for management of network components 0 0 0

interviewed for this testing procedure.
<Report Findings Here>

For the interview, summarize the relevant details discussed to verify that roles and
responsibilities are assigned as documented for management of firewall and router
components.
<Report Findings Here>
Identify the firewall configuration standards document(s) reviewed to verify the 0 1 0
document(s) contains a list of all services, protocols and ports necessary for
business, including a business justification for each.
<Report Findings Here>

Identify the router configuration standards document(s) reviewed to verify the

document contains a list of all services, protocols and ports necessary for business,
including a business justification for each. 2
<Report Findings Here>

Identify whether any insecure services, protocols or ports are allowed. (yes/no) 0 1 0
<Report Findings Here>

If “yes,” complete the instructions below for EACH insecure service, protocol, and
port allowed: (add rows as needed)
Identify the documented justification.
<Report Findings Here>
2
Identify the firewall and router configuration standards reviewed to verify that
security features are documented for each insecure service/protocol/port.
<Report Findings Here>

If “yes” at 1.1.6.b, complete the following for each insecure service, protocol, 0 1 0
and/or port present (add rows as needed):

Describe how the firewall and router configurations were examined to verify that
the documented security features are implemented for each insecure service,
protocol and/or port.
<Report Findings Here> 2

Identify the firewall and router configuration standards reviewed to verify they 0 0 0
require a review of firewall rule sets at least every six months.
<Report Findings Here>

Identify the document(s) relating to rule set reviews that were examined to verify 0 0 0
that rule sets are reviewed at least every six months for firewall and router rule
sets.
<Report Findings Here>

Identify the responsible personnel interviewed who confirm that rule sets are
completed at least every six months:
 6
Identify the responsible personnel interviewed who confirm that rule sets are
reviewed at least every six months for firewall and router rule sets.
<Report Findings Here>
Left Blank by PCIco 0 1 0

Identify the firewall and router configuration standards reviewed to verify they 0 1 0
identify inbound and outbound traffic necessary for the cardholder data environment.
<Report Findings Here>
2

Describe how firewall and router configurations were examined to verify that the 0 1 0
following traffic is limited to that which is necessary for the cardholder data
environment:

Inbound traffic
<Report Findings Here>
 2
Outbound traffic
<Report Findings Here>

Describe how firewall and router configurations were examined to verify the 0 0 0
following is specifically denied:

All other inbound traffic
<Report Findings Here>

All other outbound traffic 2
<Report Findings Here>

Describe how router configuration files were examined to verify they are secured 0 0 0
from unauthorized access.
<Report Findings Here>

Describe how router configuration files were examined to verify they are 0 0 0
synchronized.
<Report Findings Here> 2
Describe how firewall and router configurations were examined to verify perimeter 0 0 0
firewalls are in place between all wireless networks and the cardholder data
environment.
<Report Findings Here>

Identify whether traffic between the wireless environment and the cardholder data 0 0 0
environment is necessary for business purposes. (yes/no)
<Report Findings Here>

If “no”:

Describe how firewall and/or router configurations were observed to verify firewalls
deny all traffic from any wireless environment into the cardholder environment.
<Report Findings Here>


If “yes”:

Describe how firewall and/or router configurations were observed to verify firewalls 2
permit only authorized traffic from any wireless environment into the cardholder
environment.
<Report Findings Here>

0 0 0

2
Describe how the firewall and router configurations were examined to verify that 0 0 0
the DMZ is implemented to limit inbound traffic to only system components that
provide authorized publicly accessible services, protocols, and ports.
<Report Findings Here>

Describe how the firewall and router configurations were examined to verify that 0 0 0
configurations limit inbound Internet traffic to IP addresses within the DMZ.
<Report Findings Here>
2

Describe how the examined firewall and router configurations were observed to 0 0 0
prevent direct connections between the Internet and the cardholder data
environment:

Inbound
<Report Findings Here>
 2
Outbound
<Report Findings Here>

Describe how observed firewall/router configurations prevent internal addresses 0 1 0

passing from the Internet into the DMZ.
<Report Findings Here>

Describe how observed traffic from the Internet into the DMZ confirms that internal
addresses cannot pass from the Internet into the DMZ.
<Report Findings Here>
2
Describe how firewall and router configurations were examined to verify that 0 1 0
outbound traffic from the cardholder data environment to the Internet is explicitly
authorized.
<Report Findings Here>

Describe how firewall and router configurations were examined to verify that the 0 1 0
firewall performs stateful inspection.
<Report Findings Here>

Describe how observed firewall configurations implement stateful inspection
<Report Findings Here> 2

Identify whether any system components store cardholder data. (yes/no) 0 0 0

<Report Findings Here>

If “yes”:

Describe how firewall and router configurations were examined to verify that the
system components that store cardholder data are located on an internal network 2
zone, and are segregated from the DMZ and other untrusted networks.
<Report Findings Here>

Describe the methods in place to prevent the disclosure of private IP addresses and 0 1 0
routing information from internal networks to the Internet.
<Report Findings Here>

Describe how firewall and router configurations were examined to verify that
methods are in place to prevent the disclosure of private IP addresses and routing
information from internal networks to the Internet. 2
<Report Findings Here>
 Identify the document reviewed that specifies whether any disclosure of private IP 0 1 0
addresses and routing information to external parties is permitted.
<Report Findings Here>

For each permitted disclosure, identify the responsible personnel interviewed who
confirm that the disclosure is authorized.
<Report Findings Here>

Identify whether mobile and/or employee- owned computers with direct connectivity 0 0 0
to the Internet are used to access the organization’s network. (yes/no)
<Report Findings Here>

If “no,” identify the document reviewed that explicitly prohibits mobile and/or
employee- owned computers with direct connectivity to the Internet from being used
to access the organization’s network
<Report Findings Here>

If “yes,” identify the documented policies and configuration standards that define the
following:
Personal firewall software is required for all mobile and/or employee-owned devices
that connect to the Internet when outside the network, and which are also used to
access the network.
Specific configuration settings are defined for personal firewall software. 2
Personal firewall software is configured to actively run.
Personal firewall software is configured to not be alterable by users of mobile and/or
employee-owned devices.
<Report Findings Here>
Identify the sample of mobile and/or employee-owned devices selected for this 0 0 0
testing procedure.
<Report Findings Here>

Describe how the sample of mobile and/or employee-owned devices was inspected to
verify that personal firewall software is:
Installed and configured per the organization’s specific configuration settings.
<Report Findings Here>

Actively running.
<Report Findings Here> 2
Not alterable by users of mobile and/or employee-owned devices.
<Report Findings Here>

Identify the document reviewed to verify that security policies and operational 0 0 0
procedures for managing firewalls are documented.
<Report Findings Here>

Identify responsible personnel interviewed who confirm that the above documented
security policies and operational procedures for managing firewalls are:
 In use 6
 Known to all affected parties
<Report Findings Here>

103 0 14 0
trusted network.

r sources. Often, seemingly insignificant paths to and from untrusted networks can provide unprotected pathways into key systems. Firewalls are a
assessment of Requirement 1.

Merchant Type: D

B B-IP C-VT C D S In Place ? Severity in Proofs /

case of non Documentation links
compliance
0 0 0 0 1 1 N 1

0 0 0 0 1 1 C 0

0 0 0 0 1 1 N 1
0 0 0 0 1 1 N 1

0 1 0 0 1 1 Y 0

0 1 0 0 1 1 Y 0
0 0 0 0 1 1 C 0

0 1 0 0 1 1 N 5

0 1 0 0 1 1 N 5

0 1 0 0 1 1 N 5

0 0 0 0 1 1 N 1

0 0 0 0 1 1 N 7
0 1 0 0 1 1 N 5

0 1 0 0 1 1 Y 0

0 1 0 0 1 1 Y 0

0 0 0 0 1 1 Y 0

0 0 0 0 1 1 Y 0
0 1 1 1 1 1 Y 0

0 1 1 1 1 1 Y 0

0 1 1 1 1 1 Y 0

0 1 1 1 1 1 Y 0

0 0 0 0 1 1 Y 0

0 0 0 0 1 1 Y 0
0 1 1 1 1 1 Y 0

0 1 1 1 1 1 Y 0

0 1 1 1 1 1 Y 0
0 0 0 0 1 1 Y 0

0 0 0 0 1 1 Y 0

0 1 1 1 1 1 Y 0

0 1 0 0 1 1 Y 0
0 1 1 1 1 1 Y 0

0 1 1 1 1 1 Y 0

0 0 0 0 1 1 Y 0

0 0 0 0 1 1 Y 0
0 0 0 0 1 1 Y 0

0 0 1 0 1 1 Y 0
0 0 1 0 1 1 Y 0

0 0 0 0 1 1 1

0 19 12 10 38 38 Y 32
N
C
NT
NA
nprotected pathways into key systems. Firewalls are a key protection mechanism for any computer network.

Stage of implementation Remediation plan Estimated date for completion

Comments Owner

Name
 Go to requirement 1
Return to Table of content
Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters
Malicious individuals (external and internal to an entity) often use vendor default passwords and other vendor default settings to com

Major observations from the 2014 Verizon PCI Compliance Report

Only 38.8% of organizations suffering a breach had Requirement 2 in place.
90.1% of assessed organizations managed to comply with 2.2.3.a, which involves verifying that system administrators and security ma
50.5% were complying with subcontrol 2.2.2: Enable only necessary and secure services, protocols
Only 55.4% of companies were in compliance with 2.2.2.a. This subcontrol requires that organizations document all services and proto
51.5% of companies complied with 2.2.2b, indicating that organizations still find it challenging to provide valid business justifications f

PCI DSS Requirement Guidance

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

System configuration standards must also be kept

up to date to ensure that newly identified
weaknesses are corrected prior to a system being
installed on the network.
2.2.1 Implement only one primary function per This is intended to ensure your organization's
server to prevent functions that require different system configuration standards and related
security levels from co-existing on the same processes address server functions that need to
server. (For example, web servers, database have different security levels, or that may introduce
servers, and DNS should be implemented on security weaknesses to other functions on the same
separate servers.) server. For example:

Note: Where virtualization technologies are in 1. A database, which needs to have strong security
use, implement only one primary function per measures in place, would be at risk sharing a server
virtual system component. with a web application, which needs to be open and
directly face the Internet.

2. Failure to apply a patch to a seemingly minor

function could result in a compromise that impacts
other, more important functions (such as a
database) on the same server.
This requirement is meant for all servers within the
cardholder data environment (usually Unix, Linux,
or Windows based). This requirement may not
apply to systems which have the ability to natively
implement security levels on a single server (e.g.
mainframe).

Where virtualization technologies are used, each

virtual component (e.g. virtual machine, virtual
switch, virtual security appliance, etc.) should be
considered a “server” boundary. Individual
hypervisors may support different functions, but a
single virtual machine should adhere to the “one
primary function” rule. Under this scenario,
compromise of the hypervisor could lead to the
compromise of all system functions. Consequently,
consideration should also be given to the risk level
when locating multiple functions or components on
a single physical system.
2.2.2 Enable only necessary and secure services, As stated in Requirement 1.1.5, there are many
protocols, daemons, etc., as required for the protocols that a business may need (or have
function of the system. Implement security enabled by default) that are commonly used by
features for any required services, protocols or malicious individuals to compromise a network. To
daemons that are considered to be insecure—for ensure that only the necessary services and
example, use secured technologies such as SSH, protocols are enabled and that all insecure services
S-FTP, SSL, or IPSec VPN to protect insecure and protocols are adequately secured before new
services such as NetBIOS, file-sharing, Telnet, FTP, servers are deployed, this requirement should be
etc. part of your organization's configuration standards
and related processes.

2.2.3 Implement additional security features Enabling security features before new servers are
for any required services, protocols, or deployed will prevent servers being installed into
daemons that are considered to be insecure the environment with insecure configurations.
—for example, use secured technologies Ensuring that all insecure services, protocols, and
daemons are adequately secured with appropriate
such as SSH, S-FTP, SSL, or IPSec VPN to security features makes it more difficult for
protect insecure services such as NetBIOS, malicious individuals to take advantage of
file-sharing, Telnet, FTP, etc. commonly used points of compromise within a
network.

2.2.4 Configure system security parameters to This is intended to ensure your organization’s
prevent misuse. system configuration standards and related
processes specifically address security settings and
parameters that have known security implications.
 2.2.5 Remove all unnecessary functionality, such The server-hardening standards must include
as scripts, drivers, features, subsystems, file processes to address unnecessary functionality with
systems, and unnecessary web servers. specific security implications (like
removing/disabling FTP or the web server if the
server will not be performing those functions).

2.3 Encrypt all non-console administrative access If remote administration is not done with secure
using strong cryptography. Use technologies such as authentication and encrypted communications,
SSH, VPN, or SSL/TLS for webbased management sensitive administrative or operational level
and other nonconsole administrative access. information (like administrator’s passwords) can be
revealed to an eavesdropper. A malicious individual
could use this information to access the network,
become administrator, and steal data.
revealed to an eavesdropper. A malicious individual
could use this information to access the network,
become administrator, and steal data.
 2.4 Maintain an inventory of system Maintaining a current list of all system components
components that are in scope for PCI DSS. will enable an organization to accurately and
efficiently define the scope of their environment for
implementing PCI DSS controls. Without an
inventory, some system components could be
forgotten, and be inadvertently excluded from the
organization’s configuration standards.

2.5 Ensure that security policies and Personnel need to be aware of and following
operational procedures for managing vendor security policies and daily operational procedures to
defaults and other security parameters are ensure vendor defaults and other security
documented, in use, and known to all affected parameters are continuously managed to prevent
insecure configurations.
parties.

2.6 Shared hosting providers must protect each This is intended for hosting providers that provide
entity’s hosted environment and cardholder data. shared hosting environments for multiple clients on
These providers must meet specific requirements as the same server. When all data is on the same
detailed in Appendix A: Additional PCI DSS server and under control of a single environment,
Requirements for Shared Hosting Providers. often the settings on these shared servers are not
manageable by individual clients, allow clients to
add insecure functions and scripts that impact the
security of all other client environments; and
thereby make it easy for a malicious individual to
compromise one client's data and thereby gain
access to all other clients' data.
 Go to requirement 3 Executive Summary

d other security parameters

nd other vendor default settings to compromise systems. These passwords and settings are well known by hacker communities and are easily deter

t system administrators and security managers have knowledge of common security parameter settings for system components.
ocols
izations document all services and protocols enabled on their system components, justify why they’re active, and verify that controls are implemen
to provide valid business justifications for the use of insecure services, daemons, and protocols, and presenting the documentation for it.

SANS Testing Procedure

Top 20 Critical
Security Controls
C3.3 2.1 Choose a sample of system components, and attempt to log on (with system
C12.2 administrator help) to the devices using default vendor-supplied accounts and
passwords, to verify that default accounts and passwords have been changed. (Use
vendor manuals and sources on the Internet to find vendor-supplied
accounts/passwords.)

2.1.b For the sample of system components, verify that all unnecessary default
accounts (including accounts used by operating systems, security software,
applications, systems, POS terminals, SNMP, etc.) are removed or disabled.
 2.1.c Interview personnel and examine supporting documentation to verify that:

All vendor defaults (including default passwords on operating systems, software

providing security services, application and system accounts, POS terminals, Simple
Network Management Protocol (SNMP) community strings, etc.) are changed before a
system is installed on the network.
Unnecessary default accounts (including accounts used by operating systems, security
software, applications, systems, POS terminals, SNMP, etc.) are removed or disabled
before a system is installed on the network.

C11.5 2.1.1.a Interview responsible personnel and examine

C7.1 supporting documentation to verify that:
Encryption keys were changed from default at installation
2.1.1.b Interview personnel and examine policies and procedures to
verify:
Default SNMP community strings are required to be changed upon
installation.
Default passwords/phrases on access points are required to be
changed upon installation.

2.1.1.c Examine vendor documentation and login to wireless devices, with system
admin help

2.1.1.d Examine vendor documentation and observe

wireless configuration settings to verify firmware on
wireless devices is updated to support strong encryption
for:
Authentication over wireless networks
Transmission over wireless networks

2.1.1.e Examine vendor documentation and observe wireless configuration

settings to verify other security-related wireless vendor defaults were changed, if
applicable..
C3.1 2.2.a Examine the organization’s system configuration standards for all types of
C3.2 system components and verify the system configuration standards are consistent with
C3.3 industry-accepted hardening standards.
C10.1

2.2.b Verify that system configuration standards are updated as new vulnerability
issues are identified, as defined in Requirement 6.1.

2.2.c Examine policies and interview personnel to verify that system configuration
standards are applied when new systems are configured and verified as being in place
before a system is installed on the network.
 2.2.d Verify that system configuration standards include the
following procedures for all types of system components:
Changing of all vendor- supplied defaults and elimination of
unnecessary default accounts
Implementing only one primary function per server to prevent
functions that require different security levels from co-
existing on the same server
Enabling only necessary services, protocols, daemons, etc.,
as required for the function of the system
Implementing additional security features for any required
services, protocols or daemons that are considered to be
insecure
Configuring system security parameters to prevent misuse
Removing all unnecessary functionality, such as scripts,
drivers, features, subsystems, file systems, and unnecessary
web servers

NC 2.2.1.a Select a sample of system components and inspect the system

configurations to verify that only one primary function is implemented per server.

2.2.1.b If virtualization technologies are used, verify that only one primary function
is implemented per virtual system component or device.
C3.3 2.2.2.a Select a sample of system components and inspect enabled system services,
C10.1 daemons, and protocols to verify that only necessary services or protocols are
enabled.

2.2.2.b Identify any enabled insecure services, daemons, or protocols and interview
personnel to verify they are justified per documented configuration standards..

2.2.3 Inspect configuration settings to verify that security features are documented
and implemented for all insecure services, daemons, or protocols.

C3.3 2.2.4.a Interview system administrators and/or security managers to verify that
C10.6 they have knowledge of common security parameter settings for system
components.

2.2.4.b Examine the system configuration standards to verify that common security
parameter settings are included.
 2.2.4.c Select a sample of system components and inspect the common security
parameters to verify that they are set appropriately and in accordance with the
configuration standards.

C3.3 2.2.5.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.5.b. Examine the documentation and security parameters to verify enabled

functions are documented and support secure configuration.

2.2.5.c. Examine the documentation and security parameters to verify that only
documented functionality is present on the sampled system components.

C10.6 2.3 Select a sample of system components and 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 administrator’s password is requested.

2.3.b Review services and parameter files on systems to determine that Telnet and
other insecure remote-login commands are not available for non-console access.

2.3.c Observe an administrator log on to each system to verify that administrator

access to any web-based management interfaces is encrypted with strong
cryptography.

2.3.d Examine vendor documentation and interview personnel to verify that strong
cryptography for the technology in use is implemented according to industry best
practices and/or vendor recommendations.
 2.4.a Examine system inventory to verify that a list of hardware and software
components is maintained and includes a description of function/use for each.

2.4.b Interview personnel to verify the documented inventory is kept current.

2.5 Examine documentation and interview personnel to verify that security policies
and operational procedures for managing vendor defaults and other security
parameters are:
􏰁 Documented,
􏰁 In use, and
􏰁 Known to all affected parties.

NC 2.6 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.
r communities and are easily determined via public information.

m components.

verify that controls are implemented.

he documentation for it. Selected Merchant Type:

Validation Instructions for QSA/ISA Priority A A-EP PE2P

(For In-Place Requirements)

Identify the sample of system components selected. 0 1 0

<Report Findings Here>

Identify the vendor manuals and sources on the Internet used to find vendor-supplied
accounts/passwords.
<Report Findings Here>

For each item in the sample, describe how attempts to log on (with system
administrator help) to the sample of devices and applications using default vendor- 2
supplied accounts and passwords were performed to verify that all default passwords
have been changed.
<Report Findings Here>

For each item in the sample of system components indicated at 2.1.a, describe how all 0 1 0
unnecessary default accounts were verified to be either:

Removed
<Report Findings Here>
Disabled 2
<Report Findings Here>
Identify responsible personnel interviewed who verify that: 0 0 0

All vendor defaults (including default passwords on operating systems, software

providing security services, application and system accounts, POS terminals, Simple
Network Management Protocol (SNMP) community strings, etc.) are changed before a
system is installed on the network.
Unnecessary default accounts (including accounts used by operating systems, security
software, applications, systems, POS terminals, SNMP, etc.) are removed or disabled
before a system is installed on the network.
<Report Findings Here>

Identify supporting documentation examined for this testing procedure.

<Report Findings Here>

Describe how the supporting documentation was examined to verify that:


All vendor defaults are changed before a system is installed on the network. 2
<Report Findings Here>

Unnecessary default accounts are removed or disabled before a system is installed on

the network.
<Report Findings Here>

Identify whether there are wireless environments connected to the cardholder data 0 0 0
environment or transmitting cardholder data. (yes/no)
If “no,” mark 2.1.1 as “Not Applicable” and proceed
to 2.2.
<Report Findings Here>

If “yes”:
Identify responsible personnel interviewed who verify that encryption keys are
changed:
From default at installation
Anytime anyone with knowledge of the keys leaves the company or changes
positions.
<Report Findings Here>

Identify supporting documentation examined for this testing procedure.
<Report Findings Here>
Describe how the supporting documentation was examined to verify that
encryption keys are changed:
2
From default at installation
<Report Findings Here>

Anytime anyone with knowledge of the keys leaves the company or changes
positions.

<Report Findings Here>
Identify responsible personnel interviewed who verify that: 0 0 0
Default SNMP community strings are required to be changed upon installation.
Default passwords/phrases on access points are required to be changed upon
installation.
<Report Findings Here>

Identify policies and procedures examined to verify that:

Default SNMP community strings are required to be changed upon installation.
Default passwords/phrases on access points are required to be changed upon 2
installation.
<Report Findings Here>

Identify vendor documentation examined for this testing procedure. 0 0 0

<Report Findings Here>

Describe how examined vendor documentation was used to attempt to login to

wireless devices (with system administrator help) to verify:

Default SNMP community strings are not used.
<Report Findings Here>
Default passwords/passphrases on access points are not used. 2
<Report Findings Here>

Identify vendor documentation examined for this testing procedure. 0 0 0

<Report Findings Here>
Describe how wireless configuration settings were observed with examined vendor
documentation to verify that firmware on wireless devices is updated to support
strong encryption for:

Authentication over wireless networks.
<Report Findings Here> 2
Transmission over wireless networks.
<Report Findings Here>

Identify vendor documentation examined for this testing procedure. 0 0 0

<Report Findings Here>

Describe how wireless configuration settings were observed with examined vendor
documentation to verify other security-related wireless vendor defaults were
changed, if applicable. 2
<Report Findings Here>
Identify the documented system configuration standards for all types of system 0 1 0
components examined.
<Report Findings Here>

Identify the industry-accepted hardening standards the system configuration

standards were verified to be consistent with. 3
<Report Findings Here>

Identify the policy documentation verified to define that system configuration 0 1 0

standards are updated as new vulnerability issues are identified
<Report Findings Here>

Identify the personnel interviewed for this testing procedure.

<Report Findings Here>

For the interview, summarize the relevant details discussed that verify that the 3
process is implemented.
<Report Findings Here>

Identify the policy documentation examined to verify it defines that system 0 1 0

configuration standards are applied when new systems are configured and verified as
being in place before a system is installed on the network
<Report Findings Here>

Identify the personnel interviewed for this testing procedure.

<Report Findings Here>
For the interview, summarize the relevant details discussed that verify:
System configuration standards are applied when new systems are configured
<Report Findings Here>

System configuration standards are verified as being in place before a system is 3

installed on the network.
<Report Findings Here>
Identify the system configuration standards for all types of system components that 0 1 0
include the following procedures:
Changing of all vendor-supplied defaults and elimination of unnecessary default
accounts
Implementing only one primary function per server to prevent functions that require
different security levels from co-existing on the same server
Enabling only necessary services, protocols, daemons, etc., as required for the
function of the system
Implementing additional security features for any required services, protocols or
daemons that are considered to be insecure
Configuring system security parameters to prevent misuse 3
Removing all unnecessary functionality, such as scripts, drivers, features, subsystems,
file systems, and unnecessary web servers
<Report Findings Here>

Identify the sample of system components observed. 0 1 0

<Report Findings Here>

For each item in the sample, describe how system configurations were inspected to
verify that only one primary function per server is implemented. 3
<Report Findings Here>

Identify whether virtualization technologies are used. (yes/no) 0 1 0

<Report Findings Here>

IIf “no,” describe how systems were observed to verify that no virtualization
technologies are used.
<Report Findings Here>
If “yes”:

Identify the functions for which virtualization technologies are used.
<Report Findings Here>
Identify the sample of virtual system components or devices observed.
<Report Findings Here>

For each virtual system component and device in the sample, describe how the
system configurations were inspected to verify that only one primary function is
implemented per virtual system component or device.
<Report Findings Here>

3
Identify the sample of system components selected. 0 1 0
<Report Findings Here>

For each item in the sample, describe how the enabled system services, daemons,
and protocols were inspected to verify that only necessary services or protocols are
enabled.
<Report Findings Here> 3

For each item in the sample of system components from 2.2.2.a, identify if any 0 1 0
insecure services, daemons, or protocols are enabled. (yes/no)
If “no,” mark the remainder of 2.2.2.b and 2.2.3 as “Not Applicable.”
<Report Findings Here>
IIf “yes,” identify responsible personnel interviewed who confirm that a
documented business justification was present for each insecure service, daemon, 3
or protocol
<Report Findings Here>

If “yes” at 2.2.b, perform the following: 0 1 0


Identify configuration settings inspected.
<Report Findings Here>

Describe how configuration settings were inspected to verify that security features
for all insecure services, daemons, or protocols are:

Documented
<Report Findings Here> 3
Implemented
<Report Findings Here>

Identify the system administrators and/or security managers interviewed for this 0 1 0
testing procedure.
<Report Findings Here>

For the interview, summarize the relevant details discussed to verify that they have
knowledge of common security parameter settings for system components. 3
<Report Findings Here>

Identify the system configuration standards examined to verify that common 0 1 0

security parameter settings are included.
<Report Findings Here> 3
 Identify the sample of system components selected. 0 1 0
<Report Findings Here>

For each item in the sample, describe how the common security parameters were
inspected to verify that they are set appropriately and in accordance with the
configuration standards. 3
<Report Findings Here>

Identify the sample of system components selected. 0 1 0

<Report Findings Here>

For each item in the sample, describe how the configurations were inspected to
verify that all unnecessary functionality is removed.
<Report Findings Here> 3

Describe how the security parameters were examined with relevant documentation 0 1 0
to verify that enabled functions are:

Documented
<Report Findings Here>

Support secure configuration 3
<Report Findings Here>

Identify documentation examined for this testing procedure. 0 1 0

<Report Findings Here>

Describe how the security parameters were examined with relevant documentation
to verify that only documented functionality is present on the sampled system
components from 2.2.5.a.
<Report Findings Here> 3

Identify the sample of system components selected for 2.3.a-2.3.d to verify that non- 0 1 0
console administrative access is encrypted
<Report Findings Here>

2
For each item in the sample from 2.3: 0 1 0

Describe how the administrator log on for each system was observed to verify that a
strong encryption method is invoked before the administrator’s password is
requested.
<Report Findings Here>
Describe how system configurations for each system were examined to verify that a
strong encryption method is invoked before the administrator’s password is
requested. 2
<Report Findings Here>

Identify the strong encryption method used for non-console administrative access.
<Report Findings Here>

For each item in the sample from 2.3: 0 1 0

Describe how services on systems were reviewed to determine that Telnet and other
insecure remote-login commands are not available for non-console access.
<Report Findings Here>

Describe how parameter files on systems were reviewed to determine that Telnet and
other insecure remote-login commands are not available for non-console access. 2
<Report Findings Here>

For each item in the sample from 2.3: 0 1 0

Describe how the administrator log on to each system was observed to verify that
administrator access to any web-based management interfaces was encrypted with
strong cryptography.
<Report Findings Here>

Identify the strong encryption method used for any web-based management 2
interfaces.
<Report Findings Here>

Identify the vendor documentation examined to verify that strong cryptography for 0 1 0
the technology in use is implemented according to industry best practices and/or
vendor recommendations.
<Report Findings Here>

Identify the personnel interviewed for this testing procedure.

<Report Findings Here>
For the interview, summarize the relevant details discussed that verify that strong 2
cryptography for the technology in use is implemented according to industry best
practices and/or vendor recommendations.
<Report Findings Here>
Describe how the system inventory was examined to verify that a list of hardware and 0 0 0
software components is:

Maintained
<Report Findings Here>

Includes a description of function/use for each

<Report Findings Here> 2

Identify the personnel interviewed for this testing procedure. 0 0 0

<Report Findings Here>

For the interview, summarize the relevant details discussed that verify that the
documented inventory is kept current.
<Report Findings Here> 2

Identify the document reviewed to verify that security policies and operational 0 0 0
procedures for managing vendor defaults and other security parameters are
documented.
<Report Findings Here>

Identify responsible personnel interviewed who confirm that the above documented
security policies and operational procedures for managing vendor defaults and other
security parameters are:
In use 6
Known to all affected parties
<Report Findings Here>

Identify whether the assessed entity is a shared hosting provider. (yes/no) 0 0 0

<Report Findings Here>

If “yes,” provide the name of the assessor who attests that Appendix A: Additional PCI
DSS Requirements for Shared Hosting Providers has been completed.
<Report Findings Here>

84 0 22 0
Merchant Type: D

B B-IP C-VT C D S In place? Severity Proofs / Documentation links

0 1 1 1 1 1 Y 0

0 1 1 1 1 1 N 5
0 1 0 1 1 1 N 5

0 1 1 1 1 1 N 5
0 1 1 1 1 1 N 5

0 1 1 1 1 1 N 5

0 1 1 1 1 1 N 5

0 1 1 1 1 1 N 5
0 0 0 1 1 1 Y 0

0 0 0 1 1 1 N 4

0 0 0 1 1 1 N 4
0 0 0 1 1 1 N 4

0 0 0 1 1 1 N 4

0 0 0 1 1 1 Y 0
0 0 1 1 1 1 N 4

0 0 1 1 1 1 N 4

0 0 1 1 1 1 N 4

0 0 1 1 1 1 N 4

0 0 1 1 1 1 N 4
0 0 1 1 1 1 N 4

0 0 1 1 1 1 N 4

0 0 1 1 1 1 N 4

0 0 1 1 1 1 N 4

0 1 1 1 1 1 N 5
0 1 1 1 1 1 N 5

0 1 1 1 1 1 N 5

0 1 1 1 1 1 N 5

0 1 1 1 1 1 N 5
0 0 0 0 1 1 NT 5

0 0 0 0 1 1 NT 5

0 0 0 1 1 1 NT 1

0 0 0 0 0 1 N 0

0 13 21 29 31 32 Y 123
N
C
NT
NA
Stage of implementation Remediation plan
Estimated date for completion Comments Owner
Return to Table of content Go to requirement 2
Requirement 3: Protect stored cardholder data
Protection methods such as encryption, truncation, masking, and hashing are critical components of cardholder data protection. If an
needed, and not sending unprotected PANs using end-user messaging technologies, such as e-mail and instant messaging.

Please refer to the PCI DSS and PA-DSS Glossary of Terms, Abbreviations, and Acronyms for definitions of “strong cryptography” and o

Major observations from the 2014 Verizon PCI Compliance report

According to the 2013 DBIR, of all the breaches studied by the Verizon Investigative Response team, not a single one involved cardhol
18.2% of organizations suffering a breach had Requirement 3 in place in 2013.
32.7% of companies complied with Requirement 3 in 2013
Many organizations failed to comply with 3.4, which demands that they confirm that the PAN is rendered unreadable via hashes, trun

PCI DSS Requirement Guidance

3.1 Keep cardholder data storage to a minimum by A formal data retention policy identifies what data
implementing data retention and disposal policies, needs to be retained, and where that data resides
procedures and processes, as follows. so it can be securely destroyed or deleted as soon
as it is no longer needed. In order to define
appropriate retention requirements, an entity first
needs to understand their own business needs as
well as any legal or regulatory obligations that apply
to their industry, and/or that apply to the type of
data being retained.

Extended storage of cardholder data that exceeds

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

Implementing secure deletion methods ensure that

the data cannot be retrieved when it is no longer
needed

3.1.1 Implement a data retention and disposal

policy that includes:

- Limiting data storage amount and retention time

to that which is required for legal, regulatory, and
business requirements
- Processes for secure deletion of data when no
longer needed
- Specific retention requirements for cardholder
data
- A quarterly automatic or manual process for
identifying and securely deleting stored
cardholder data that exceeds defined retention
requirements
3.2 Do not store sensitive authentication data after Sensitive authentication data consists of magnetic
authorization (even if encrypted). stripe (or track) data6, card validation code or
Sensitive authentication data includes the data as value7, and PIN data8. Storage of sensitive
cited in the following Requirements 3.2.1 through authentication data after authorization is
3.2.3: prohibited! This data is very valuable to malicious
individuals as it allows them to generate counterfeit
Note: It is permissible for issuers and companies that payment cards and create fraudulent transactions.
support issuing services to store sensitive See PCI DSS and PA-DSS Glossary of Terms,
authentication data if there is a business justification Abbreviations, and Acronyms for the full definition
and the data is stored securely. of “sensitive authentication data.”
Note: It is allowable for companies that perform,
facilitate, or support issuing services to store
sensitive authentication data ONLY IF they have a
legitimate business need to store such data. It
should be noted that all PCI DSS requirements apply
to issuers, and the only exception for issuers and
issuer processors is that sensitive authentication
data may be retained if there is a legitimate reason
to do so. A legitimate reason is one that is necessary
for the performance of the function being provided
for the issuer and not one of convenience.

Any such data must be stored securely and in

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

Note: In the normal course of business, the

following data elements from the magnetic stripe
may need to be retained:

- The cardholder’s name

- Primary account number (PAN)
- Expiration date
- Service code
To minimize risk, store only these data elements
as needed for business.
3.2.2 Do not store the card verification code or The purpose of the card validation code is to
value (three-digit or four-digit number printed on protect "card-not-present" transactions—Internet
the front or back of a payment card) used to or mail order/telephone order (MO/TO)
verify card-notpresent transactions. transactions—where the consumer and the card are
not present. These types of transactions can be
authenticated as coming from the card owner only
by requesting this card validation code, since the
card owner has the card in-hand and can read the
value. If this prohibited data is stored and
subsequently stolen, malicious individuals can
execute fraudulent Internet and MO/TO
transactions.

3.2.3 Do not store the personal identification These values should be known only to the card
number (PIN) or the encrypted PIN block. owner or bank that issued the card. If this
prohibited data is stored and subsequently stolen,
malicious individuals can execute fraudulent PIN-
based debit transactions (for example, ATM
withdrawals).
3.3 Mask PAN when displayed (the first six and last The display of full PAN on items such as computer
four digits are the maximum number of digits to be screens, payment card receipts, faxes, or paper
displayed). reports can result in this data being obtained by
unauthorized individuals and used fraudulently. The
Notes: PAN can be displayed in full form on the “merchant
- This requirement does not apply to employees and copy” receipts; however the paper receipts should
other parties with a legitimate business need to see adhere to the same security requirements as
the full PAN. electronic copies and follow the guidelines of the
- This requirement does not supersede stricter PCI Data Security Standard, especially Requirement
requirements in place for displays of cardholder data 9 regarding physical security. The full PAN can also
—for example, for point-of-sale (POS) receipts. be displayed for those with a legitimate business
need to see the full PAN.

This requirement relates to protection of PAN

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

1) A direct association with the operating system, or

2) Decryption keys that are associated with user
accounts.

3.5 Protect any keys used to secure cardholder data Cryptographic keys must be strongly protected
against disclosure and misuse: because those who obtain access will be able to
decrypt data. Key-encrypting keys, if used, must be
Note: This requirement also applies to key- at least as strong as the data-encrypting key in
encrypting keys used to protect dataencrypting keys order to ensure proper protection of the key that
—such key-encrypting keys must be at least as encrypts the data as well as the data encrypted with
strong as the data-encrypting key. that key.

The requirement to protect keys from disclosure

and misuse applies to both data- encrypting keys
and key-encrypting keys. Because one key-
encrypting key may grant access to many data-
encrypting keys, the key-encrypting keys require
strong protection measures. Methods for secure
storage of key-encrypting keys include but are not
limited to hardware security modules (HSMs) and
tamper evident storage with dual control and split
knowledge.
3.5.1 Restrict access to cryptographic keys to the There should be very few who have access to
fewest number of custodians necessary. cryptographic keys, usually only those who have key
custodian responsibilities.

3.5.2 Store secret and private keys used to Cryptographic keys must be stored securely to
encrypt/decrypt cardholder data in one (or more) of prevent unauthorized or unnecessary access that
the following forms at all times: could result in the exposure of cardholder data.
-Encrypted with a key-encrypting key that is at least It is not intended that the key-encrypting keys be
as strong as the data-encrypting key, and that is encrypted, however they are to be protected
stored separately from the data- encrypting key against disclosure and misuse as defined in
-Within a secure cryptographic device (such as a Requirement 3.5. If key-encrypting keys are used,
host security module (HSM) or PTS-approved point- storing the key-encrypting keys in physically and/or
of-interaction device) logically separate locations from the data-
-As at least two full-length key components or key encrypting keys reduces the risk of unauthorized
shares, in accordance with an industry- accepted access to both keys.
method
3.5.3 Store cryptographic keys securely in the Cryptographic keys must be stored securely, usually
fewest possible locations and forms. encrypted with key-encrypting keys, and stored in
very few locations. It is not intended that the key-
encrypting keys be encrypted, however they are to
be protected against disclosure and misuse as
defined in Requirement 3.5. Storing key-encrypting
keys in physically and/or logically separate locations
from data-encrypting keys reduces the risk of
unauthorized access to both keys.

3.6 Fully document and implement all key- The manner in which cryptographic keys are
management processes and procedures for managed is a critical part of the continued security
cryptographic keys used for encryption of of the encryption solution. A good key management
cardholder data, including the following: process, whether it is manual or automated as part
of the encryption product, is based on industry
Note: Numerous industry standards for key standards and addresses all key elements at 3.6.1
management are available from various resources through 3.6.8.
including NIST, which can be found at
http://csrc.nist.gov.

3.6.1 Generation of strong cryptographic keys The encryption solution must generate strong keys,
as defined in the PCI DSS and PA-DSS Glossary of
Terms, Abbreviations, and Acronyms under "strong
cryptography."

3.6.2 Secure cryptographic key distribution The encryption solution must distribute keys
securely, meaning the keys are not distributed in
the clear, and only to custodians identified in 3.5.1.

3.6.3 Secure cryptographic key storage The encryption solution must store keys securely,
meaning the keys are not stored in the clear
(encrypt them with a key-encryption key).
3.6.4 Cryptographic key changes for keys that have A cryptoperiod is the time span during which a
reached the end of their cryptoperiod (for example, particular cryptographic key can be used for its
after a defined period of time has passed and/or defined purpose. Considerations for defining the
after a certain amount of ciphertext has been cryptoperiod include, but are not limited to, the
produced by a given key), as defined by the strength of the underlying algorithm, size or length
associated application vendor or key owner, and of the key, risk of key compromise, and the
based on industry best practices and guidelines (for sensitivity of the data being encrypted.
example, NIST Special Publication 800-57). Periodic changing of encryption keys when the keys
have reached the end of their cryptoperiod is
imperative to minimize the risk of someone’s
obtaining the encryption keys, and being able to
decrypt data.
If provided by encryption application vendor, follow
the vendor’s documented processes or
recommendations for periodic changing of keys.
The designated key owner or custodian can also
refer to industry best practices on cryptographic
algorithms and key management, for example NIST
Special Publication 800-57, for guidance on the
appropriate cryptoperiod for different algorithms
and key lengths.
The intent of this requirement applies to keys used
to encrypt stored cardholder data, and any
respective key-encrypting keys.

3.6.5 Retirement or replacement (for example, Old keys that are no longer used or needed should
archiving, destruction, and/or revocation) of keys be retired and destroyed to ensure that the keys
as deemed necessary when the integrity of the can no longer be used. If old keys need to be kept
key has been weakened (for example, departure (to support archived, encrypted data, for example)
of an employee with knowledge of a clear-text they should be strongly protected. (See 3.6.6
key), or keys are suspected of being below.) The encryption solution should also allow
compromised. for and facilitate a process to replace keys that are
known to be, or suspected of being, compromised.
Note: If retired or replaced cryptographic keys
need to be retained, these keys must be securely
archived (for example, by using a key encryption
key). Archived cryptographic keys should only be
used for decryption/verification purposes.
3.6.6 If manual clear-text cryptographic key Split knowledge and dual control of keys are used to
management operations are used, these operations eliminate the possibility of one person’s having
must be managed using split knowledge and dual access to the whole key. This control is applicable
control (for example, requiring two or three people, for manual key management operations, or where
each knowing only their own key component, to key management is not implemented by the
reconstruct the whole key). encryption product.
Note: Examples of manual key management
operations include, but are not limited to: key
generation, transmission, loading, storage and
destruction.

3.6.7 Prevention of unauthorized substitution of The encryption solution should not allow for or
cryptographic keys. accept substitution of keys coming from
unauthorized sources or unexpected processes.

3.6.8 Requirement for cryptographic key custodians This process will ensure individuals that act as key
to formally acknowledge that they understand and custodians commit to the key- custodian role and
accept their key-custodian responsibilities. understand the responsibilities.
3.7 Ensure that security policies and Personnel need to be aware of and following
operational procedures for protecting stored security policies and documented operational
cardholder data are documented, in use, and procedures for managing the secure storage of
known to all affected parties. cardholder data on a continuous basis.
 Go to requirement 4Executive Summary

ents of cardholder data protection. If an intruder circumvents other security controls and gains access to encrypted data, without the proper crypto
-mail and instant messaging.

efinitions of “strong cryptography” and other PCI DSS terms.

team, not a single one involved cardholder data “in transit” between systems. However, two-thirds of data breaches involved data “at rest.”

is rendered unreadable via hashes, truncation, strong encryption or tokenization. Just 47.5% of companies were compliant with all four validation t

SANS Testing Procedure

Top 20 Critical
Security Controls

NC 3.1 Obtain and examine the policies, procedures and processes for data retention and
disposal, and perform the following:

NC 3.1.1.a Verify that policies and procedures are implemented and include legal,
regulatory, and business requirements for data retention, including specific
requirements for retention of cardholder data (for example, cardholder data needs
to be held for X period for Y business reasons).
3.1.1.b Verify that policies and procedures include provisions for secure disposal of
data when no longer needed for legal, regulatory, or business reasons, including
disposal of cardholder data.

3.1.1.c Verify that policies and procedures include coverage for all storage of
cardholder data.
NA 3.2.a For issuers and/or companies that support issuing services and store sensitive
authentication data, verify there is a business justification for the storage of sensitive
authentication data, and that the data is secured.

3.2.b For issuers and/or companies that support issuing services and store sensitive
authentication data, examine data stores and system configurations to verify that the
sensitive authentication data is secured.

3.2.c For all other entities, if sensitive authentication data is received, review policies
and procedures, and examine system configurations to verify the data is not retained
after authorization.
 3.2.d For all other entities, if sensitive authentication data is received, review
procedures and examine the processes for securely deleting the data to verify that the
data is unrecoverable.

NA 3.2.1 For a sample of system components, examine data sources, including but not
limited to the following, and verify that the full contents of any track from the
magnetic stripe on the back of card or equivalent data on a chip are not stored
under any circumstance:

- Incoming transaction data

- All logs (for example, transaction, history, debugging, error)
- History files
- Trace files
- Several database schemas
- Database contents
NA 3.2.2 For a sample of system components, examine data sources, including but not
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:

- Incoming transaction data

- All logs (for example, transaction, history, debugging, error)
- History files
- Trace files
- Several database schemas
- Database contents

NA 3.2.3 For a sample of system components, examine data sources, including but not
limited to the following and verify that PINs and encrypted PIN blocks 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
NA 3.3.a Examine written policies and procedures for masking the display of PANs to
verify:
A list of roles that need access to displays of full PAN is documented, together with a
legitimate business need for each role to have such access.
PAN must be masked when displayed such that only personnel with a legitimate
business need can see the full PAN.
All other roles not specifically authorized to see the full PAN must only see masked
PANs..

3.3.b Examine system configurations to verify that full PAN is only displayed for
users/roles with a documented business need, and that PAN is masked for all other
requests.

3.3.c Examine displays of PAN for example, on screen, on paper receipts) to verify that
PANs are masked when displaying cardholder data, and that only those with a
legitimate business need are able to see full PAN.
C17.7 3.4.a Examine documentation about the system used to protect the PAN, including the
C8.4 vendor, type of system/process, and the encryption algorithms (if applicable) to verify
that the PAN is rendered unreadable using any of the following methods:
􏰀 One-way hashes based on strong cryptography,
􏰀 Truncation
􏰀 Index tokens and pads, with the pads being securely stored
􏰀 Strong cryptography, with associated key- management processes and procedures.

3.4.b Examine several tables or files from a sample of data repositories to verify the
PAN is rendered unreadable (that is, not stored in plain-text).

3.4.c Examine a sample of removable media (for example, back-up tapes) to confirm
that the PAN is rendered unreadable.

3.4.d Examine a sample of audit logs to confirm that the PAN is rendered unreadable
or removed from the logs.
NC 3.4.1.a If disk encryption is used, verify that logical access to encrypted file systems
is implemented via a mechanism that is separate from the native operating systems
mechanism (for example, not using local user account databases).

3.4.1.b Verify that cryptographic keys are stored securely (for example, stored on
removable media that is adequately protected with strong access controls).

3.4.1.c Examine the configurations and observe the processes to verify that
cardholder data on removable media is encrypted wherever stored.

NC 3.5 Examine key-management policies and procedures to verify

processes are specified to protect keys used for encryption of
cardholder data against disclosure and misuse and include at least
the following:
􏰀 Access to keys is restricted to the fewest number of custodians
necessary.
􏰀 Key-encrypting keys are at least as strong as the data- encrypting
keys they protect.
􏰀 Key-encrypting keys are stored separately from data- encrypting
keys.
􏰀 Keys are stored securely in the fewest possible locations and forms.
NC 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 documented procedures to verify that cryptographic keys used to

encrypt/decrypt cardholder data must only exist in one (or more) of the following
forms at all times.
Encrypted with a key-encrypting key that is at least as strong as the data-encrypting
key, and that is stored separately from the data-encrypting key
Within a secure cryptographic device (such as a host security module (HSM) or PTS-
approved point-of- interaction device)
As key components or key shares, in accordance with an industry-accepted method

3.5.2.b Examine system configurations and key storage locations to verify that
cryptographic keys used to encrypt/decrypt cardholder data exist in one (or more) of
the following form at all times.

Encrypted with a key-encrypting key

Within a secure cryptographic device (such as a host security module (HSM) or PTS-
approved point-of- interaction device)
As key components or key shares, in accordance with an industry-accepted method

3.5.2.c Wherever key-encrypting keys are used, examine system configurations and
key storage locations to verify:
Key-encrypting keys are at least as strong as the data- encrypting keys they protect
Key-encrypting keys are stored separately from data- encrypting keys.
NC 3.5.3 Examine key storage locations and observe processes to verify that keys are
stored in the fewest possible locations.

NC 3.6.a Additional Procedure for service providers: If the service provider shares keys
with their customers for transmission or storage of cardholder data, examine the
documentation that the service provider provides to their customers to verify that it
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.bExamine the key-management procedures and processes for keys used for
encryption of cardholder data and perform the following:

NC 3.6.1.a Verify that key- management procedures specify how to generate strong
keys.

3.6.1.b Observe the method for generating keys to verify that strong keys are
generated

NC 3.6.2.a Verify that key- management procedures specify how to securely distribute
keys.

3.6.2.b Observe the method for distributing keys to verify that keys are distributed
securely.

NC 3.6.3.a Verify that key- management procedures specify how to securely store keys.

3.6.3.b Observe the method for storing keys to verify that keys are stored securely.
NC 3.6.4.a Verify that key-management procedures are implemented to require
periodic key changes at the end of the defined cryptoperiod.

3.6.4.b Interview personnel to verify that keys are changed at the end of the
defined cryptoperiod(s).

NC 3.6.5.a Verify that key- management procedures specify processes

for the following:
The retirement or replacement of keys when the integrity of the key
has been weakened.
The replacement of known or suspected compromised keys.
Any keys retained after retiring or replacing are not used for
encryption operations.

3.6.5.b Interview personnel to verify the following processes are

implemented:
Keys are retired or replaced as necessary when the integrity of the
key has been weakened, including when someone with knowledge
of the key leaves the company.
Keys are replaced if known or suspected to be compromised.
Any keys retained after retiring or replacing are not used for
encryption operations.
NC 3.6.6.a Verify that manual clear- text key-management procedures specify
processes for the use of the following:

Split knowledge of keys, such that key components are under the control
of at least two people who only have knowledge of their
own key components; AND
Dual control of keys, such that at least two people are
required to perform any key- management operations and
no one person has access to the authentication materials
(for example, passwords or keys) of another.

3.6.6 b Interview personnel and/or observe processes to verify that manual clear-
text keys are managed with:
Split knowledge, AND
Dual control

NC 3.6.7.a Verify that key- management procedures specify processes to prevent

unauthorized substitution of keys.

3.6.7.b Interview personnel and/or observe process to verify that unauthorized

substitution of keys is prevented.

NC 3.6.8.a Verify that key- management procedures specify processes for key
custodians to acknowledge (in writing or electronically) that they understand and
accept their key-custodian responsibilities.

3.6.8.b Observe documentation or other evidence showing that key custodians have
acknowledged (in writing or electronically) that they understand and accept their
key-custodian responsibilities.
3.7 Examine documentation interview personnel to verify that security policies and
operational procedures for protecting stored cardholder data are:
􏰁 Documented,
􏰁 In use, and
􏰁 Known to all affected parties.
pted data, without the proper cryptographic keys, the data is unreadable and unusable to that person. Other effective methods of protecting stored

aches involved data “at rest.”

Selected Merchant Typ
e compliant with all four validation testing requirements:

Validation Instructions for QSA/ISA Priority A

(For In-Place Requirements)

left blank by pcico 1 0

Identify the data-retention and disposal documentation examined to verify policies, 1 0

procedures, and processes define:
􏰀 Legal, regulatory, and business requirements for data retention, including:
- Specificrequirementsforretentionof
cardholder data (for example, cardholder data needs to be held for X period for Y
business reasons).
- Securedeletionofcardholderdatawhen no longer needed for legal, regulatory, or
business reasons.
- Coverageforallstorageofcardholder data.
􏰀 A quarterly process for identifying and securely deleting stored cardholder data that
exceeds defined retention requirements.
<Report Findings Here>
Identify the personnel interviewed who confirm that: 1 0
􏰀 All locations of stored cardholder data are included in the data-retention and
disposal processes.
􏰀 Either a quarterly automatic or manual process is in place to identify and securely
delete stored cardholder data.
􏰀 The quarterly automatic or manual process is performed for all locations of
cardholder data.
<Report Findings Here>

For the interview, summarize the relevant details discussed that verify the following:
All locations of stored cardholder data are included in the data-retention and disposal
process.
<Report Findings Here>

Either a quarterly automatic or manual process is in place to identify and securely

delete stored cardholder data.
<Report Findings Here>

The quarterly automatic or manual process is performed for all locations of cardholder
data.
<Report Findings Here>

Describe the quarterly process in place to identify and securely delete stored
cardholder data, including whether it is an automatic or manual process.
<Report Findings Here>

Identify the sample of system components selected. 1 0

<Report Findings Here>

For each item in the sample, describe how files and system records were examined to
verify that the data stored does not exceed the requirements defined in the data-
retention policy.
<Report Findings Here>

Describe how the deletion mechanism was observed to verify data is deleted securely.
<Report Findings Here>
Identify whether the assessed entity is an issuer or supports issuing service. (yes/no) 1 0
<Report Findings Here>

If “yes,” complete the responses for 3.2.a and 3.2.b and mark 3.2.c and 3.2.d as “Not
Applicable.” If “no,” mark the remainder of 3.2.a and 3.2.b as “Not Applicable” and
proceed to 3.2.c and 3.2.d.
Identify the documentation reviewed to verify there is a documented business
justification for the storage of sensitive authentication data.
<Report Findings Here>
Identify the interviewed personnel who confirm there is a documented business
justification for the storage of sensitive authentication data.
<Report Findings Here>

For the interview, summarize the relevant details of the business justification
described.
<Report Findings Here>

If “yes” at 3.2.a, 1 0

Identify data stores examined.

<Report Findings Here>

Identify the system configurations examined.

<Report Findings Here>

Describe how the data stores and system configurations were examined to verify that
the sensitive authentication data is secured.
<Report Findings Here>

Identify whether sensitive authentication data is received. (yes/no) 1 0

<Report Findings Here>
If “yes,” complete 3.2.c and 3.2.d.
If “no,” mark the remainder of 3.2.c and 3.2.d as “Not Applicable” and proceed to
3.2.1.
Identify the document(s) reviewed to verify that it defines that data is not retained
after authorization.
<Report Findings Here>

Describe how system configurations were examined to verify the data is not retained
after authorization.
<Report Findings Here>
Identify the document(s) reviewed to verify that it defines processes for securely 2 0
deleting the data to verify that the data is unrecoverable.
<Report Findings Here>

Describe how the processes for securely deleting the data were examined to verify
that the data is unrecoverable.
<Report Findings Here>

Identify the sample of system components selected for 3.2.1-3.2.3. 1 0

<Report Findings Here>

For each data source type below from the sample of system of components examined,
summarize the specific examples of each data source type observed to 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 after authorization. If that type of data source is not
present, indicate that in the space.

Incoming transaction data
<Report Findings Here>

All logs (for example, transaction, history, debugging error)

<Report Findings Here>
History files
<Report Findings Here>

Trace files
<Report Findings Here>

Database schemas
<Report Findings Here>

Database contents
<Report Findings Here>

If applicable, any other output observed to be generated

<Report Findings Here>
For each data source type below from the sample of system of components at 3.2.1, 1 0
summarize the specific examples of each data source type observed to verify that the
three-digit 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 after authorization.
If that type of data source is not present, indicate that in the space.

Incoming transaction data
<Report Findings Here>

All logs (for example, transaction, history, debugging error)
<Report Findings Here>

History files
<Report Findings Here>

Trace files
<Report Findings Here>

Database schemas
<Report Findings Here>

Database contents
<Report Findings Here>

If applicable, any other output observed to be generated
<Report Findings Here>

For each data source type below from the sample of system of components at 3.2.1, 1 0
summarize the specific examples of each data source type observed. If that type of
data source is not present, indicate that in the space.

Incoming transaction data

<Report Findings Here>

All logs (for example, transaction, history,debugging error) 􏰁 History files

<Report Findings Here>

Trace files
<Report Findings Here>
Database schemas
<Report Findings Here>

Database contents
<Report Findings Here>

If applicable, any other output observed to be generated

<Report Findings Here>
Identify the document(s) reviewed to verify that written policies and procedures for 5 0
masking the displays of PANs include the following:

A list of roles that need access to displays of full PAN is documented, together with a
legitimate business need for each role to have such access.
PAN must be masked when displayed such that only personnel with a legitimate
business need can see the full PAN.
All other roles not specifically authorized to see the full PAN must only see masked
PANs.
<Report Findings Here>

Describe how system configurations were examined to verify that: 5 0


Full PAN is only displayed for users/roles with a documented business need.
<Report Findings Here>

PAN is masked for all other requests.
<Report Findings Here>

Describe how displays of PAN were examined to verify that: 5 0

PANs are masked when displaying cardholder data.

<Report Findings Here>

Only those with a legitimate business need are able to see full PAN.
<Report Findings Here>
Identify the documentation about the system used to protect the PAN 5 0
examined.
<Report Findings Here>

Briefly describe the documented methods— including the vendor, type of

system/process, and then encryption algorithms (if applicable)— used to
protect the PAN.
<Report Findings Here>

Identify which of the following methods is used to render the PAN unreadable:
One-way hashes based on strong cryptography
Truncation
Index token and pads, with the pads being
securely stored
Strong cryptography, with associated key- management processes and
procedures
<Report Findings Here>

Identify the sample of data repositories selected. 5 0

<Report Findings Here>

Identify the tables or files examined for each item in the sample of data
repositories.
<Report Findings Here>

For each item in the sample, describe how the table or file was examined to
verify the PAN is rendered unreadable.
<Report Findings Here>

Identify the sample of removable media selected. 5 0

<Report Findings Here>

For each item in the sample, describe how the sample of removable media
was examined to confirm that the PAN is rendered unreadable.
<Report Findings Here>

Identify the sample of audit logs selected. 5 0

<Report Findings Here>

For each item in the sample, describe how the sample of audit logs was
examined to confirm that the PAN is rendered unreadable or removed from
the logs.
<Report Findings Here>
Identify whether disk encryption is used. (yes/no) 5 0
<Report Findings Here>

If “yes,” complete the remainder of 3.4.1.a, 3.4.1.b, and 3.4.1.c.

If “no,” mark the remainder of 3.4.1.a, 3.4.1.b and 3.4.1.c as “Not Applicable.’

Describe the disk encryption mechanism(s) in use.

<Report Findings Here>

For each disk encryption mechanism in use, describe how the configuration
was inspected and the authentication process observed to verify that logical
access to encrypted file systems is separate from the native operating
system’s authentication mechanism.
<Report Findings Here>

Describe how processes were observed to verify that cryptographic keys are 5 0
stored securely.
<Report Findings Here>

Identify the personnel interviewed who confirm that cryptographic keys are
stored securely.
<Report Findings
Identify the Here> examined.
configurations 5 0
<Report Findings Here>

Identify the documented key-management policies and processes examined to verify 5 0

processes are defined to protect keys used for encryption of cardholder data against
disclosure and misuse and include at least the following:
Access to keys is restricted to the fewest number of custodians necessary.
Key-encrypting keys are at least as strong as the data-encrypting keys they protect.
Key-encrypting keys are stored separately from data-encrypting keys.
Keys are stored securely in the fewest possible locations and forms.
<Report Findings Here>
Identify user access lists examined. 5 0
<Report Findings Here>

Describe how user access lists were examined to verify that access to keys is
restricted to the fewest number of custodians necessary.
<Report Findings Here>

Identify the documented procedures examined to verify that cryptographic 5 0

keys used to encrypt/decrypt cardholder data must only exist in one (or more)
of the following forms at all times.
Encrypted with a key-encrypting key that is at least as strong as the data-
encrypting key, and that is stored separately from the data-encrypting key.
Within a secure cryptographic device (such as a host security module (HSM) or
PTS- approved point-of-interaction device).
As key components or key shares, in accordance with an industry-accepted
method.
<Report Findings Here>

Provide the name of the assessor who attests that all locations where keys are 5 0
stored were identified.
<Report Findings Here>

Describe how system configurations and key storage locations were examined
to verify that cryptographic keys used to encrypt/decrypt cardholder data
must only exist in one (or more) of the following forms at all times.
Encrypted with a key-encrypting key that is at least as strong as the data-
encrypting key, and that is stored separately from the data-encrypting key.
Within a secure cryptographic device (such as a host security module (HSM) or
PTS- approved point-of-interaction device).
As key components or key shares, in accordance with an industry-accepted
method.
<Report Findings Here>

Describe how system configurations and key storage locations were examined 5 0
to verify that, wherever key-encrypting keys are used:

Key-encrypting keys are at least as strong as the data-encrypting keys they
protect
<Report Findings Here>

Key-encrypting keys are stored separately from data-encrypting keys.

<Report Findings Here>
Describe how key storage locations were examined and processes were 5 0
observed to verify that keys are stored in the fewest possible locations.
<Report Findings Here>

Identify whether the assessed entity is a service provider that shares keys with their 5 0
customers for transmission or storage of cardholder data. (yes/no)
<Report Findings Here>

If “yes,”

Identify the document that the service provider provides to their customers examined
to verify that it includes guidance on how to securely transmit, store and update
customers’ keys, in accordance with Requirements 3.6.1 through 3.6.8 below.
<Report Findings Here>

left blank by PCIco 5 0

Identify the documented key-management procedures examined to verify procedures 5 0

specify how to generate strong keys.
<Report Findings Here>

Describe how the method for generating strong keys was observedto verify that 6 0
strong keys are generated
<Report Findings Here>

Identify the documented key-management procedures examined to verify procedures 5 0

specify how to securely distribute keys.
<Report Findings Here>

Describe how the method for distributing keys was observed to verify that keys are 6 0
distributed securely.
<Report Findings Here>

Identify the documented key-management procedures examined to verify procedures 5 0

specify how to securely store keys.
<Report Findings Here>

Describe how the method for storing keys was observed to verify that keys are stored 6 0
securely.
<Report Findings Here>
Identify the document that defines: 5 0
Key cryptoperiod(s) for each key type in use
A process for key changes at the end of the defined cryptoperiod(s)
<Report Findings Here>

Identify personnel interviewed for this testing procedure who confirm that keys are 6 0
changed at the end of the defined cryptoperiod(s).
<Report Findings Here>

Identify the key-management document examined to verify that key-management 5 0

processes specify the following:
The retirement or replacement of keys when the integrity of the key has been
weakened.
The replacement of known or suspected compromised keys.
Any keys retained after retiring or replacing are not used for encryption operations.
<Report Findings Here>

Identify the personnel interviewed for this testing procedure. 5 0

<Report Findings Here>

For the interview, summarize the relevant details discussed that verify the following
processes are implemented:

Keys are retired or replaced as necessary when the integrity of the key has been
weakened, including when someone with knowledge of the key leaves the company.
<Report Findings Here>

Keys are replaced if known or suspected to be compromised.

<Report Findings Here>

Any keys retained after retiring or replacing are not used for encryption operations.
<Report Findings Here>
Identify the document examined to verify that manual clear-text key-management 5 0
procedures define processes for the use of the following:

Split knowledge of keys, such that key components are under the control of at least
two people who only have knowledge of their own key components; AND
Dual control of keys, such that at least two people are required to perform any key-
management operations and no one person has access to the authentication materials
of another.
<Report Findings Here>

Identify the personnel interviewed for this testing procedure, if applicable. 5 0

<Report Findings Here>

For the interview, summarize the relevant details discussed and/or describe how
processes were observed to verify the following processes are implemented:

Split knowledge
<Report Findings Here>

Dual Control
<Report Findings Here>

Identify the document examined to verify that key-management procedures specify 5 0

processes to prevent unauthorized substitution of keys.
<Report Findings Here>

Identify the personnel interviewed for this testing procedure, if applicable. 5 0

<Report Findings Here>

For the interview, summarize the relevant details discussed and/or describe how
processes were observed to verify that unauthorized substitution of keys is prevented.
<Report Findings Here>

Identify the document examined to verify that key-management procedures specify 5 0

processes for key custodians to acknowledge that they understand and accept their
key- custodian responsibilities.
<Report Findings Here>

Describe how key custodian acknowledgements or other evidence were observed to 5 0

verify that key custodians have acknowledged that they understand and accept their
key-custodian responsibilities.
<Report Findings Here>
Identify the document reviewed to verify that security policies and operational 0
procedures for protecting stored cardholder data are documented.
<Report Findings Here>

Identify responsible personnel interviewed who confirm that the above documented
security policies and operational procedures for protecting stored cardholder data
are:
 In use 6
 Known to all affected parties
<Report Findings Here>

192 0
tive methods of protecting stored data should be considered as potential risk mitigation opportunities. For example, methods for minimizing risk in

ected Merchant Type:

D

A-EP PE2P B B-IP C-VT C D S In Place ? Severity Proofs /

Documentation links

0 0 0 0 0 0 1 1 N 6

0 1 0 0 0 0 1 1 Y 0
0 1 0 0 0 0 1 1 N 6

0 1 0 0 0 0 1 1 N 6
0 0 1 0 0 1 1 1 N 6

0 0 1 0 0 1 1 1 N 6

1 0 1 1 1 1 1 1 N 6
0 0 1 1 1 1 1 1 N 5

0 0 1 1 0 1 1 1 N 6
1 1 1 1 1 1 1 1 N 6

1 0 1 1 1 1 1 1 N 6
0 1 1 1 1 1 1 1 N 2

0 0 1 1 1 1 1 1 N 2

0 0 1 1 0 1 1 1 N 2
0 0 0 0 0 0 1 1 N 2

0 0 0 0 0 0 1 1 N 2

0 0 0 0 0 0 1 1 N 2

0 0 0 0 0 0 1 1 N 2
0 0 0 0 0 0 1 1 N 2

0 0 0 0 0 0 1 1 N 2

0 0 0 0 0 0 1 1 N 2

0 0 0 0 0 0 1 1 N 2
0 0 0 0 0 0 1 1 N 2

0 0 0 0 0 0 1 1 N 2

0 0 0 0 0 0 1 1 N 2

0 0 0 0 0 0 1 1 NT 2
0 0 0 0 0 0 1 1 N 2

0 0 0 0 0 0 0 1 N 0

0 0 0 0 0 0 1 1 N 2

0 0 0 0 0 0 1 1 N 2

0 0 0 0 0 0 1 1 N 1

0 0 0 0 0 0 1 1 N 2

0 0 0 0 0 0 1 1 N 1

0 0 0 0 0 0 1 1 N 2

0 0 0 0 0 0 1 1 N 1
0 0 0 0 0 0 1 1 N 2

0 0 0 0 0 0 1 1 N 1

0 0 0 0 0 0 1 1 N 2

0 0 0 0 0 0 1 1 N 2
0 0 0 0 0 0 1 1 N 2

0 0 0 0 0 0 1 1 N 2

0 0 0 0 0 0 1 1 N 2

0 0 0 0 0 0 1 1 N 2

0 0 0 0 0 0 1 1 N 2

0 0 0 0 0 0 1 1 N 2
0 1 0 0 0 0 1 1 N 1

3 6 10 8 6 10 45 46 Y 122
N
C
NT
NA
methods for minimizing risk include not storing cardholder data unless absolutely necessary, truncating cardholder data if full PAN is not

Stage of implementation Remediation plan

ely necessary, truncating cardholder data if full PAN is not

Estimated date for completion Comments Owner

Name 1
Return to Table of content Go to requirement 3
Requirement 4: Encrypt transmission of cardholder data across open, public networks
Sensitive information must be encrypted during transmission over networks that are easily accessed by malicious individuals. Misconfi

Major observations from the 2014 Verizon PCI Compliance Report:

The most-often complied-with subcontrols included 4.1.b on the use of trusted keys and certificates (84.2%) and 4.1.e on using HTTPS
The least complied-with subcontrol within Requirement 4 was 4.1.a [Implement and maintain a system and supporting processes to e

PCI DSS Requirement Guidance

4.1 Use strong cryptography and security protocols Sensitive information must be encrypted during
(for example, SSL/TLS, IPSEC, SSH, etc.) to safeguard transmission over public networks, because it is
sensitive cardholder data during transmission over easy and common for a malicious individual to
open, public networks, including the following: intercept and/or divert data while in transit.
-Only trusted keys and certificates are accepted. Secure transmission of cardholder data requires
-The protocol in use only supports secure versions using trusted keys/certificates, a secure protocol for
or configurations. transport, and proper encryption strength to
-The encryption strength is appropriate for the encrypt cardholder data. Connection requests from
encryption methodology in use. systems that do not support the required
encryption strength, and that would result in an
insecure connection, should not be accepted.
Note that some protocol implementations (such as
SSL v2.0, SSH v1.0 and TLS 1.0) have known
vulnerabilities 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 versions and configurations to prevent use of
an insecure connection. For example, TLS v1.1, or
later, certificates obtained from a recognized, public
certificate authority and supporting only strong
encryption, may be considered.
Verifying that certificates are trusted (for example,
have not expired and are issued from a trusted
source) helps ensure the integrity of the secure
connection.
 4.1.1 Ensure wireless networks transmitting Malicious users use free and widely available
cardholder data or connected to the cardholder tools to eavesdrop on wireless communications.
data environment, use industry best practices (for Use of strong cryptography can limit disclosure of
example, IEEE 802.11i) to implement strong sensitive information across the network. Many
encryption for authentication and transmission. known compromises of cardholder data stored
only in the wired network originated when a
Note: The use of WEP as a security control was malicious user expanded access from an insecure
prohibited as of 30 June 2010. wireless network. Examples of wireless
implementations requiring strong cryptography
include but are not limited to GPRS, GSM, WIFI,
satellite, and Bluetooth.

Strong cryptography for authentication and

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

Current wireless devices should be upgraded

(example: upgrade access point firmware to
WPA2) to support strong encryption. If current
devices cannot be upgraded, new equipment
should be purchased or other compensating
controls implemented to provide strong
encryption.

4.2 Never send unprotected PANs by end-user E-mail, instant messaging, and chat can be easily
messaging technologies (for example, e-mail, intercepted by packet-sniffing during delivery
instant messaging, chat, etc.). traversal across internal and public networks. Do
not utilize these messaging tools to send PAN unless
they provide strong encryption.
4.3 Ensure that security policies and Personnel need to be aware of and following
operational procedures for encrypting security policies and operational procedures for
transmissions of cardholder data are managing the secure transmission of cardholder
documented, in use, and known to all affected data on a continuous basis.
parties.
 Go to requirement 5 Executive Summary
etworks
cessed by malicious individuals. Misconfigured wireless networks and vulnerabilities in legacy encryption and authentication protocols continue to b

ficates (84.2%) and 4.1.e on using HTTPS in web sessions (83.2%).

a system and supporting processes to ensure that cardholder data is always encrypted during transit over unsecure networks], with 24.8% of organ

SANS Testing Procedure

Top 20 Critical
Security Controls
C15.4.1 4.1.a Identify all locations where cardholder data is transmitted or received over
C17.6 open, public networks. Examine documented standards and compare to system
configurations to verify the use of security protocols and strong cryptography for all
locations.

4.1.b Review documented policies and procedures to verify processes are specified for
the following:
􏰁 For acceptance of only trusted keys and/or certificates
􏰁 For the protocol in use to only support secure versions and configurations (that
insecure versions or configurations are not supported)
􏰁 For implementation of proper encryption strength per the encryption methodology
in use

4.1.c Select and observe a sample of inbound and outbound transmissions as they
occur to verify that all cardholder data is encrypted with strong cryptography during
transit.
4.1.d Examine keys and certificates to verify that only trusted keys and/or certificates
are accepted.

4.1.e Examine system configurations to verify that the protocol is implemented to use
only secure configurations and does not support insecure versions or configurations.

4.1.f Examine system configurations to verify that the proper encryption strength is
implemented for the encryption methodology in use. (Check vendor
recommendations/best practices.)

4.1.g.For SSL/TLS implementations, examine system configurations to verify that

SSL/TLS is enabled whenever cardholder data is transmitted or received.
C7.1 4.1.1 For wireless networks transmitting cardholder data or connected to the
C7.10 cardholder data environment, verify that industry best practices (for example, IEEE
802.11i) are used to implement strong encryption for authentication and
transmission.

NA 4.2.a If end-user messaging technologies are used to send cardholder data, observe
processes for sending PAN and examine a sample of outbound transmissions as they
occur to verify that PAN is rendered unreadable or secured with strong cryptography
whenever it is sent via end-user messaging technologies.
4.2.b Review written policies to verify the existence of a policy stating that
unprotected PANs are not to be sent via end-user messaging technologies.

4.3 Examine documentation interview personnel to verify that security policies and
operational procedures for encrypting transmissions of cardholder data are:
􏰁 Documented,
􏰁 In use, and
􏰁 Known to all affected parties.
hentication protocols continue to be targets of malicious individuals who exploit these vulnerabilities to gain privileged access to cardholder data e

ure networks], with 24.8% of organizations failing to pass muster.

Selected Merchant Type

Vaidation Instructions for QSA/ISA Priority A A-EP

(For In-Place Requirements)

Identify all locations where cardholder data is transmitted or received over open, 2 ### 1
public networks.
<Report Findings Here>

Identify the documented standards examined

<Report Findings Here>

Describe how the documented standards were examined and compared to system
configurations to verify the use of:
Security protocols observed in use
<Report Findings Here>

Strong cryptography for all locations

<Report Findings Here>

Identify the document reviewed to verify that processes are specified for the 2 ### 1
following:
 For acceptance of only trusted keys and/or certificates.
 For the protocol in use to only support secure versions and configurations (that
insecure versions or configurations are not supported).
 For implementation of proper encryption strength per the encryption
methodology in use.
<Report Findings Here>

Describe the sample of inbound and outbound transmissions observed as they 2 ### 1
occurred.
<Report Findings Here>

Describe how the samples of inbound and outbound transmissions were observed
as they occurred to verify that all cardholder data is encrypted with strong
cryptography during transit.
<Report Findings Here>
For all instances where cardholder data is transmitted or received over open, public 2 ### 1
networks:
Describe the mechanisms used to ensure that only trusted keys and/or certificates
are accepted.
<Report Findings Here>

Describe how the mechanisms were observed to accept only trusted keys and/or
certificates.
<Report Findings Here>

For all instances where cardholder data Is transmitted or received over open, public 2 ### 1
networks, describe how system configurations were observed to verify that the
protocol is implemented:
To use only secure configurations.
<Report Findings Here>

Does not support insecure versions or configurations.

<Report Findings Here>

For each encryption methodology in use, 2 ### 0

Identify vendor recommendations/best practices for encryption strength.
<Report Findings Here>

Identify the encryption strength observed to be implemented.

<Report Findings Here>

Identify whether SSL/TLS use to encrypt cardholder date over open, public networks 2 ### 0
at all in the cardholder date environment. (yes/no)
<Report Findings Here>

If “yes,” for all instances where SSL/TLS is used to encrypt cardholder data over
open, public networks, describe how system configurations were examined to verify
that SSL/TLS is enabled whenever cardholder data is transmitted or received, as
follows:
HTTPS appears as part of the browser URL.
<Report Findings Here>
Cardholder is only requested if HTTPS appears as part of the URL.
<Report Findings Here>
 identify all wireless networks transmitting cardholder data or connected to the 2 ### 0
cardholder data environment.
<Report Findings Here>

Identify the documented standards examined to verify processes define the

following for all wireless networks identified:
􏰀 Industry best practices (for example, IEEE 802.11i) are used to implement
strong encryption for authentication and transmission.
􏰀 Weak encryption (for example, WEP, SSL version 2.0 or older) is not used as a
security control for authentication or transmission.
<Report Findings Here>

Describe how documented standards were examined and compared to system

configuration settings to verify the following for all wireless networks identified:

Industry best practices are used to implement strong encryption for

authentication and transmission.
<Report Findings Here>

Weak encryption is not used as a security control for authentication or

transmission.
<Report Findings Here>

Identify whether end-user messaging technologies are used to send cardholder 2 ### 0
data. (yes/no)
<Report Findings Here>

f “no,” mark the remainder of 4.2.a as “Not Applicable” and proceed to 4.2.b. If
“yes,” complete the following:

Describe how processes for sending PAN were observed to verify that PAN is
rendered unreadable or secured with strong cryptography whenever it is sent via
end-user messaging technologies.
<Report Findings Here>
Describe the sample of outbound transmissions observed as they occurred to verify
that PAN is rendered unreadable or secured with strong cryptography whenever it
is sent via end-user messaging technologies.
<Report Findings Here>
If “no” at 4.2.a: 2 ### 1

Identify the policy document stating that unprotected PANs must not be sent via
end- user messaging technologies.
<Report Findings Here>

If “yes” at 4.2.a:
Identify the policy document that explicitly prohibits PAN from being sent via end-
user messaging technologies under any circumstance.
<Report Findings Here>

Identify the document reviewed to verify that security policies and operational ### 0
procedures for encrypting transmissions of cardholder data are documented.
<Report Findings Here>

Identify responsible personnel interviewed who confirm that the above

documented security policies and operational procedures for encrypting
transmissions of cardholder data are:
 In use 6
 Known to all affected parties
<Report Findings Here>
.

26 0 6
ed access to cardholder data environments.

ed Merchant Type: D

PE2P B B-IP C-VT C D S In Place? Severity Proofs /

Documentation links

0 0 1 1 1 1 1 N 5

0 0 1 1 1 1 1 Y 0

0 0 1 1 1 1 1 Y 0
0 0 1 1 1 1 1 N 5

0 0 1 1 1 1 1 N 5

0 0 0 0 1 1 1 N 5

0 0 0 0 0 1 1 N 5
0 0 1 1 1 1 1 N 5

0 1 0 0 0 1 1 N 5
1 1 1 1 1 1 1 NT 5

0 0 0 0 0 1 1 N 1

1 2 7 7 8 11 11 Y 41
N
C
NT
NA
Stage of implementation Remediation plan
Estimated date for completion Comments Owner
Return to Table of content Go to requirement 4
Requirement 5: Use and regularly update anti-virus software or programs
Malicious software, commonly referred to as “malware”—including viruses, worms, and Trojans—enters the network during many bu

Major Observations from the 2014 Verizon PCI Compliance Report:

Just 34.9% compliance with Requirement 5. The average compliance across all organizations was 56.4%.

PCI DSS Requirement Guidance

5.1 Deploy anti-virus software on all systems There is a constant stream of attacks using widely
commonly affected by malicious software published exploits, often "0 day" (published and
(particularly personal computers and servers). spread throughout networks within an hour of
discovery) against otherwise secured systems.
Without anti-virus software that is updated
regularly, these new forms of malicious software
can attack and disable your network.
Malicious software may be unknowingly
downloaded and/or installed from the internet, but
computers are also vulnerable when using
removable storage devices such as CDs and DVDs,
USB memory sticks and hard drives, digital cameras,
personal digital assistants (PDAs) and other
peripheral devices. Without anti-virus software
installed, these computers may become access
points into your network, and/or maliciously target
information within the network.

While systems that are commonly affected by

malicious software typically do not include
mainframes and most Unix systems (see more detail
below), each entity must have a process according
to PCI DSS Requirement 6.2 to identify and address
new security vulnerabilities and update their
configuration standards and processes accordingly.
If another type of solution addresses the identical
threats with a different methodology than a
signature-based approach, it may still be acceptable
to meet the requirement.
Trends in malicious software related to operating
systems an entity uses should be included in the
identification of new security vulnerabilities, and
methods to address new trends should be
incorporated into the company's configuration
standards and protection mechanisms as needed.
Typically, the following operating systems are not
commonly affected by malicious software:
mainframes, and certain Unix servers (such as AIX,
 5.1.1 Ensure that all anti-virus programs are It is important to protect against ALL types and
capable of detecting, removing, and protecting forms of malicious software.
against all known types of malicious software.

5.1.2 For systems considered to be not commonly Typically, mainframes, mid-range computers
affected by malicious software, perform periodic (such as AS/400) and similar systems may not
evaluations to identify and evaluate evolving currently be commonly targeted or affected by
malware threats in order to confirm whether malware. However, industry trends for malicious
such systems continue to not require anti-virus software can change quickly, so it is important for
software. organizations to be aware of new malware that
might affect their systems—for example, by
monitoring vendor security notices and anti-virus
news groups to determine whether their systems
might be coming under threat from new and
evolving malware.
Trends in malicious software 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

5.2 Ensure that all anti-virus mechanisms are Even the best anti-virus solutions are limited in
maintained as follows: effectiveness if they are not maintained and kept
􏰁 Are kept current, current with the latest security updates, signature
􏰁 Perform periodic scans files, or malware protections.
Audit logs provide the ability to monitor virus and
􏰁 Generate audit logs which are malware activity and anti-malware reactions. Thus,
retained per PCI DSS Requirement 10.7. it is imperative that anti-malware solutions be
configured to generate audit logs and that these
logs be managed in accordance with Requirement
10.
5.3 Ensure that all anti-virus mechanisms are Anti-virus that continually runs and is unable to be
current, actively running, and generating audit logs. altered will provide persistent security against
malware.
Use of policy-based controls on all systems to
ensure anti-malware protections cannot be altered
or disabled will help prevent system weaknesses
from being exploited by malicious software.
Additional security measures may also need to be
implemented for the period of time during which
anti-virus protection is not active—for example,
disconnecting the unprotected system from the
Internet while the anti-virus protection is disabled,
and running a full scan after it is re-enabled.
5.4 Ensure that security policies and Personnel need to be aware of and following
operational procedures for protecting systems security policies and operational procedures to
against malware are documented, in use, and ensure systems are protected from malware on a
known to all affected parties. continuous basis.
 Go to requirement 6 Executive Summary

ns—enters the network during many business approved activities including employee e-mail and use of the Internet, mobile computers, and storag

was 56.4%.

SANS Testing Procedure

Top 20 Critical
Security Controls
C5.1 5.1 For a sample of system components including all operating system types
commonly affected by malicious software, verify that anti-virus software is deployed if
applicable anti-virus technology exists.
C5.1 5.1.1 For a sample of system components, verify that all anti-virus programs detect,
C5.2 remove, and protect against all known types of malicious software (for example,
C5.3 viruses, Trojans, worms, spyware, adware, and rootkits).
C5.4
C5.5

5.1.2 Interview personnel to verify that evolving malware threats are monitored
and evaluated for systems not currently considered to be commonly affected by
malicious software, in order to confirm whether such systems continue to not
require anti-virus software.

5.2.a Examine policies and procedures to verify that anti-virus software and
definitions are required to be kept up to date.

5.2.b Examine anti-virus configurations, including the master installation of the

software to verify anti-virus mechanisms are:
􏰁 Configured to perform automatic updates, and
􏰁 Configured to perform periodic scans.
 5.2.c Examine a sample of system components, including all operating system types
commonly affected by malicious software, to verify that:
􏰁 The anti-virus software and definitions are current.
􏰁 Periodic scans are performed.

5.2.d Examine anti-virus configurations, including the master installation of the

software and a sample of system components, to verify that:
􏰁 Anti-virus software log generation is enabled, and
􏰁 Logs are retained in accordance with PCI DSS Requirement 10.7.

C5.2 5.3.a Examine anti-virus configurations, including the master installation of the
software and a sample of system components, to verify the anti-virus software is
actively running.

5.3.b Examine anti-virus configurations, including the master installation of the

software and a sample of system components, to verify that the anti-virus software
cannot be disabled or altered by users.

5.3.c Interview responsible personnel and observe processes to verify that anti-virus
software cannot be disabled or altered by users, unless specifically authorized by
management on a case-by-case basis for a limited time period.
5.4 Examine documentation and interview personnel to verify that security policies
and operational procedures for protecting systems against malware are:
􏰁 Documented,
􏰁 In use, and
􏰁 Known to all affected parties.
net, mobile computers, and storage devices, resulting in the exploitation of system vulnerabilities. Anti-virus software must be used on all systems c

Selected Merchant Type:

Validation Instructions for QSA/ISA Priority A A-EP PE2P

(For In-Place Requirements)

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

2
Identify the vendor documentation reviewed to verify that anti-virus programs: 0 1 0
Detect all known types of malicious software,
Remove all known types of malicious software, and
Protect against all known types of malicious software.
<Report Findings Here>

Describe how anti-virus configurations were examined to verify that anti-virus

programs:

Detect all known types of malicious software,

<Report Findings Here>

Remove all known types of malicious software 2

<Report Findings Here>

Protect against all known types of malicious software.

<Report Findings Here>

Identify the personnel interviewed for this testing procedure. 0 1 0

<Report Findings Here>
For the interview, summarize the relevant details discussed and/or describe how
processes were observed to verify that evolving malware threats are monitored and
evaluated for systems not currently considered to be commonly affected by
malicious software, and that such systems continue to not require anti-virus
software.
<Report Findings Here>

Identify the documented policies and procedures examined to verify that anti-virus 0 1 0
software and definitions are required to be kept up to date.
<Report Findings Here>
2

Describe how anti-virus configurations, including the master installation of the 0 1 0

software, were examined to verify anti-virus mechanisms are:

Configured to perform automatic updates,

<Report Findings Here>

Configured to perform periodic scans. 2

<Report Findings Here>
Identify the sample of system components, including all operating system types 0 1 0
commonly affected by malicious software, selected for this testing procedure.
<Report Findings Here>

Describe how system components were examined to verify that:

The anti-virus software and definitions are current.

<Report Findings Here>

Periodic scans are performed. 2

<Report Findings Here>

Identify the sample of system components selected for this testing procedure. 0 1 0
<Report Findings Here>

For each item in the sample, describe how anti-virus configurations, including the
master installation of the software, were examined to verify that:

Anti-virus software log generation is enabled

<Report Findings Here>
2
Logs are retained in accordance with PCI DSS Requirement 10.7
<Report Findings Here>

Identify the sample of system components selected. 0 1 0

<Report Findings Here>
For each item in the sample, describe how anti-virus configurations, including the
master installation of the software, were examined to verify that the anti-virus
software is actively running. 2
<Report Findings Here>

For each item in the sample from 5.3.a, describe how anti-virus configurations, 0 1 0
including the master installation of the software, were examined to verify that the
anti-virus software cannot be disabled or altered by users.
<Report Findings Here> 2

Identify the responsible personnel interviewed who confirm that anti-virus software 0 1 0
cannot be disabled or altered by users, unless specifically authorized by
management on a case-by-case basis for a limited time period.
<Report Findings Here>

Describe how the process was observed to verify that anti-virus software cannot be
disabled or altered by users, unless specifically authorized by management on a 2
case-by-case basis for a limited time period.
<Report Findings Here>
Identify the document reviewed to verify that security policies and operational 0 0 0
procedures for protecting systems against malware are documented.
<Report Findings Here>

Identify responsible personnel interviewed who confirm that the above

documented security policies and operational procedures for protecting systems
against malware are: 6
 In use
 Known to all affected parties
<Report Findings Here>

26 0 10 0
must be used on all systems commonly affected by malware to protect systems from current and evolving malicious software threats.

Merchant Type: D

B B-IP C-VT C D S In Place? Severity Proofs / Documentation

links

0 0 1 1 1 1 N 5
0 0 1 1 1 1 N 5

0 0 1 1 1 1 N 5

0 0 1 1 1 1 N 5

0 0 1 1 1 1 N 5
0 0 1 1 1 1 NT 5

0 0 1 1 1 1 N 5

0 0 1 1 1 1 N 5

0 0 1 1 1 1 N 5

0 0

1 1 1 1 Y 0
0 0 0 0 1 1 1

NT

0 0 10 10 11 11 Y 46
N
C
NT
NA
malicious software threats.

Stage of implementation Remediation plan

Estimated date for completion Comments Owner
Return to Table of content Go to requirement 5
Requirement 6: Develop and maintain secure systems and applications
Unscrupulous individuals use security vulnerabilities to gain privileged access to systems. Many of these vulnerabilities are fixed by ve
Note: Appropriate software patches are those patches that have been evaluated and tested sufficiently to determine that the patches d

Major observations from the 2014 Verizon PCI Compliance Report:

-The three most-often complied-with subcontrols were all met by at least three-quarters of the organizations we analyzed.
6.5.b [Interview a sample of developers and obtain evidence that they are knowledgeable in secure coding techniques] is relatively sim
Subcontrols 6.4.4 and 6.3.1 govern the process of moving a system into production; specifying that test data, accounts and user IDs ar
-The least-often complied-with subcontrols tended to be those related to the much more problematic areas of identifying and managi
the latest vendor security patches installed. This subcontrol ranked among our “Bottom 20,” with only 49.5% compliance.
-Patch management and associated vulnerability management processes represent the biggest problem areas, because they’re rarely
-6.4Change-management is also of significant problems specifically relating to documentation and verification of changes. Change-ma

PCI DSS Requirement Guidance

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

Classifying the risks (for example, as “high”,

“medium”, or “low”) allows organizations to identify
and address high priority risk items more quickly,
and reduce the likelihood that vulnerabilities posing
the greatest risk will be exploited

6.3 Develop software applications (internal and Without the inclusion of security during the
external, and including webbased administrative requirements definition, design, analysis, and
access to applications) in accordance with PCI DSS testing phases of software development, security
(for example, secure authentication and logging), vulnerabilities can be inadvertently or maliciously
and based on industry best practices. Incorporate introduced into the production environment.
information security throughout the software
development life cycle. These processes must
include the following:
6.3.1 Removal of custom application accounts, Custom application accounts, user IDs, and
user IDs, and passwords before applications passwords should be removed from production
become active or are released to customers code before the application becomes active or
is released to customers, since these items
may give away information about the
functioning of the application. Possession of
such information could facilitate compromise
of the application and related cardholder data.

6.3.2 Review custom code prior to release to Security vulnerabilities in custom code are
production or customers in order to identify any commonly exploited by malicious individuals to gain
potential coding vulnerability (using either access to a network and compromise cardholder
manual or automated processes) to include at data.
least the following:
- Code changes are reviewed by individuals Code reviews may be performed manually, or with
other than the originating code author, and by the assistance of automated review tools.
individuals knowledgeable about code-review Automated review tools have functionality that
techniques and secure coding practices. reviews code for common coding mistakes and
- Code reviews ensure code is developed vulnerabilities. While automated review is useful, it
according to secure coding guidelines should not generally be relied upon as the sole
- Appropriate corrections are implemented prior means of code review. An individual knowledgeable
to release. and experienced in code review should be involved
-Code-review results are reviewed and approved in the review process in order to identify code
by management prior to release. issues that are difficult or even impossible for an
automated tool to identify. Assigning code reviews
to someone other than the developer of the code
allows an independent, objective review to be
performed.
6.4 Follow change control processes and procedures Without proper change controls, security features
for all changes to system components. The could be inadvertently or deliberately omitted or
processes must include the following: rendered inoperable, processing irregularities could
occur, or malicious code could be introduced.

6.4.1 Separate development/test and production Due to the constantly changing state of
environments development and test environments, they tend to
be less secure than the production environment.
Without adequate separation between
environments it may be possible for the production
environment, and cardholder data, to be
compromised due to vulnerabilities in a test or
development environment.
 6.4.2 Separation of duties between Reducing the number of personnel with access to
development/test and production environments the production environment and cardholder data
minimizes risk and helps ensure that access is
limited to those individuals with a business need
to know.

The intent of this requirement is to ensure that

development/test functions are separated from
production functions. For example, a developer
may use an administrator-level account with
elevated privileges for use in the development
environment, and have a separate account with
user-level access to the production environment.
In environments where one individual performs
multiple roles (for example application
development and implementing updates to
production systems), duties should be assigned
such that no one individual has end-to-end
control of a process without an independent
checkpoint. For example, assign responsibility for
development, authorization and monitoring to
separate individuals.

6.4.3 Production data (live PANs) are not used for Security controls are usually not as stringent in the
testing or development development environment. Use of production data
provides malicious individuals with the opportunity
to gain unauthorized access to production data
(cardholder data).
Payment card brands and many acquires are able to
provide account numbers suitable for testing in the
event that you need realistic PANs to test system
functionality prior to release.
6.4.4 Removal of test data and accounts before Test data and accounts should be removed from
production systems become active production code before the application becomes
active, since these items may give away
information about the functioning of the
application. Possession of such information could
facilitate compromise of the application and
related cardholder data.

6.4.5 Change control procedures for the Without proper change controls, security features
implementation of security patches and software could be inadvertently or deliberately omitted or
modifications. Procedures must include the rendered inoperable, processing irregularities could
following: occur, or malicious code could be introduced.
Likewise, a change may negatively affect security
functionality of a system necessitating the change
to be backed out.

6.4.5.1 Documentation of impact. The impact of the change should be documented

so that all affected parties will be able to plan
appropriately for any processing changes.
 6.4.5.2 Documented change approval by Approval by authorized parties indicates that the
authorized parties. change is a legitimate and approved change
sanctioned by the organization.

6.4.5.3 Functionality testing to verify that the Thorough testing should be performed to verify that
change does not adversely impact the security of the security of the environment is not reduced by
the system. implementing a change. Testing should validate that
all existing security controls remain in place, are
replaced with equally strong controls, or are
strengthened after any change to the environment.
For custom code changes, testing includes verifying
that no coding vulnerabilities have been introduced
by the change.

6.4.5.4 Back-out procedures. For each change, there should be back-out

procedures in case the change fails, to allow for
restoring back to the previous state.

6.5 Address common coding vulnerabilities in The application layer is high-risk and may be
software-development processes as follows: targeted by both internal and external threats.
- Train developers in secure coding techniques, Requirements 6.5.1 through 6.5.10 are the
including how to avoid common coding minimum controls that should be in place, and
vulnerabilities, and understanding how sensitive organizations should incorporate the relevant
data is handled in memory. secure coding practices as applicable to the
- Develop applications based on secure coding particular technology in their environment.
guidelines.
Application developers should be properly trained
to identify and resolve issues related to these (and
other) common coding vulnerabilities. Having staff
knowledgeable of secure coding guidelines should
minimize the number of security vulnerabilities
introduced through poor coding practices. Training
for developers may be provided in-house or by third
parties and should be applicable for technology
used.
As industry-accepted secure coding practices
change, organizational coding practices and
developer training should likewise be updated to
address new threats—for example, memory
scraping attacks.

The vulnerabilities identified in 6.5.1 through 6.5.10

provide a minimum baseline. It is up to the
organization to remain up to date with vulnerability
trends and incorporate appropriate measures into
their secure coding practices.
 minimize the number of security vulnerabilities
introduced through poor coding practices. Training
for developers may be provided in-house or by third
parties and should be applicable for technology
used.
As industry-accepted secure coding practices
change, organizational coding practices and
developer training should likewise be updated to
address new threats—for example, memory
scraping attacks.

The vulnerabilities identified in 6.5.1 through 6.5.10

provide a minimum baseline. It is up to the
organization to remain up to date with vulnerability
trends and incorporate appropriate measures into
their secure coding practices.

6.5.1 Injection flaws, particularly SQL injection. Validate input to verify user data cannot modify
Also consider OS Command Injection, LDAP and meaning of commands and queries. Injection
XPath injection flaws as well as other injection flaws, particularly SQL injection, are a commonly
flaws. used method for compromising applications.
Injection occurs when user-supplied data is sent
to an interpreter as part of a command or query.
The attacker's hostile data tricks the interpreter
into executing unintended commands or
changing data, and allows the attacker to attack
components inside the network through the
application, to initiate attacks such as buffer
overflows, or to reveal both confidential
information and server application functionality.
This is also a popular way to conduct fraudulent
transactions on commerce-enabled web sites.
Information from requests should be validated
before being sent to the application – for
example, by checking for all alpha characters, mix
of alpha and numeric characters, etc.
6.5.2 Buffer overflow Ensure that applications are not vulnerable to
buffer overflow attacks. Buffer overflows happen
when an application does not have appropriate
bounds checking on its buffer space. To exploit a
buffer overflow vulnerability, an attacker would
send an application a larger amount of
information than one of its particular buffers is
able to handle. This can cause the information in
the buffer to be pushed out of the buffer’s
memory space and into executable memory
space. When this occurs, the attacker has the
ability to insert malicious code at the end of the
buffer and then push that malicious code into
executable memory space by overflowing the
buffer. The malicious code is then executed and
often enables the attacker remote access to the
application and/or infected system.

6.5.3 Insecure cryptographic storage Prevent cryptographic flaws. Applications that do

not utilize strong cryptographic functions
properly to store data are at increased risk of
being compromised and exposing cardholder
data. If an attacker is able to exploit weak
cryptographic processes, they may be able to gain
clear-text access to encrypted data.

6.5.4 Insecure communications Properly encrypt all authenticated and sensitive

communications. Applications that fail to
adequately encrypt network traffic using strong
cryptography are at increased risk of being
compromised and exposing cardholder data. If an
attacker is able to exploit weak cryptographic
processes, they may be able to gain control of an
application or even gain clear-text access to
encrypted data.
6.5.5 Improper error handling Do not leak information via error messages or
other means. Applications can unintentionally
leak information about their configuration,
internal workings, or violate privacy through a
variety of application problems. Attackers use this
weakness to steal sensitive data, or conduct more
serious attacks. Also, incorrect error handling
provides information that helps a malicious
individual compromise the system. If a malicious
individual can create errors that the application
does not handle properly, they can gain detailed
system information, create denial-of- service
interruptions, cause security to fail, or crash the
server. For example, the message "incorrect
password provided" tells them the user ID
provided was accurate and that they should focus
their efforts only on the password. Use more
generic error messages, like "data could not be
verified."

6.5.6 All “High” vulnerabilities identified in the Any high vulnerabilities noted per Requirement
vulnerability identification process (as defined in 6.2 that could affect the application should be
PCI DSS Requirement 6.2). accounted for during the development phase. For
example, a vulnerability identified in a shared
Note: This requirement is considered a best library or in the underlying operating system
practice until June 30, 2012, after which it should be evaluated and addressed prior to the
becomes a requirement. application being released to production.

6.5.7 Cross-site scripting (XSS) All parameters should be validated before

inclusion. XSS flaws occur whenever an
application takes user supplied data and sends it
to a web browser without first validating or
encoding that content. XSS allows attackers to
execute script in the victim's browser which can
hijack user sessions, deface web sites, possibly
introduce worms, etc.
6.5.8 Improper Access Control (such as insecure Do not expose internal object references to users.
direct object references, failure to restrict URL A direct object reference occurs when a
access, and directory traversal) developer exposes a reference to an internal
implementation object, such as a file, directory,
database record, or key, as a URL or form
parameter. Attackers can manipulate those
references to access other objects without
authorization.
Consistently enforce access control in
presentation layer and business logic for all URLs.
Frequently, the only way an application protects
sensitive functionality is by preventing the display
of links or URLs to unauthorized users. Attackers
can use this weakness to access and perform
unauthorized operations by accessing those URLs
directly.
Protect against directory traversal. An attacker
may be able to enumerate and navigate the
directory structure of a website thus gaining
access to unauthorized information as well as
gaining further insight into the workings of the
site for later exploitation.

6.5.9 Cross-site request forgery (CSRF) Do not reply on authorization credentials and
tokens automatically submitted by browsers. A
CSRF attack forces a logged-on victim's browser
to send a pre- authenticated request to a
vulnerable web application, which then forces the
victim's browser to perform a hostile action to
the benefit of the attacker. CSRF can be as
powerful as the web application that it attacks.
6.5.10 Broken authentication and session Secure authentication and session management
management prevents unauthorized individuals from
compromising legitimate account credentials,
keys, or session tokens that would otherwise
enable the intruder to assume the identity of an
authorized user.
6.6 For public-facing web applications, address Attacks on web-facing applications are common and
new threats and vulnerabilities on an ongoing often successful, and are allowed by poor coding
basis and ensure these applications are protected practices. This requirement for reviewing
against known attacks by either of the following applications or installing web-application firewalls is
methods: intended to greatly reduce the number of
compromises on public-facing web applications that
- Reviewing public-facing web applications via result in breaches of cardholder data.
manual or automated application vulnerability
security assessment tools or methods, at least Manual or automated vulnerability security
annually and after any changes assessment tools or methods that review and/or
- Installing a web-application firewall in front of scan for application vulnerabilities can be used to
public-facing web applications satisfy this requirement

Web-application firewalls filter and block non-

essential traffic at the application layer. Used in
conjunction with a network-based firewall, a
properly configured web-application firewall
prevents application-layer attacks if applications are
improperly coded or configured.
6.7 Ensure that security policies and operational Personnel need to be aware of and following
procedures for developing and maintaining security policies and operational procedures to
secure systems and applications are documented, ensure systems and applications are securely
in use, and known to all affected parties. developed and protected from vulnerabilities on a
continuous basis.
 Go to requirement 7 Executive Summary

y of these vulnerabilities are fixed by vendor provided security patches, which must be installed by the entities that manage the systems. All critical
fficiently to determine that the patches do not conflict with existing security configurations. For in-house developed applications, numerous vulnerabi

e organizations we analyzed.
ecure coding techniques] is relatively simple to comply with, given the wealth of resources in secure coding available from major vendors such as M
that test data, accounts and user IDs are removed before the system goes live — a one-off activity that’s relatively easy to incorporate into launch
blematic areas of identifying and managing vulnerabilities and the associated changes on an ongoing basis. For example, 6.1.a (renumbered 6.2 in D
with only 49.5% compliance.
t problem areas, because they’re rarely well documented and automated.
and verification of changes. Change-management features, such as functionality testing and change impact assessment documentation, were not i

SANS Testing Procedure

Top 20 Critical
Security Controls
C3.7 6.1.a For a sample of system components and related software, compare the list of
C4.1.1 security patches installed on each system to the most recent vendor security patch
list, to verify that current vendor patches are installed.

6.1.b Examine policies related to security patch installation to verify they require
installation of all critical new security patches within one month.
C4.5 6.2.a Interview responsible personnel to verify that processes are implemented to
identify new security vulnerabilities, and that a risk ranking is assigned to such
vulnerabilities. (At minimum, the most critical, highest risk vulnerabilities should be
ranked as “High.”)

6.2.b Verify that processes to identify new security vulnerabilities include using
outside sources for security vulnerability information.

C6.6 6.3.a Obtain and examine written software development processes to verify that the
C19.4 processes are based on industry standards and/or best practices.

6.3.b Examine written software development processes to verify that information

security is included throughout the life cycle.

6.3.c Examine written software development processes to verify that software

applications are developed in accordance with PCI DSS.

6.3.d From an examination of written software development processes, and

interviews of software developers, verify that:
C3.3 6.3.1 Custom application accounts, user IDs and/or passwords are removed before
system goes into production or is released to customers.

C6.3 6.3.2.a Examine written software-development procedures and interview

responsible personnel to verify 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.

Identify the documented policies and procedures examined to verify that the
following are defined:
 Development/test environments are separate from production environments with
access control in place to enforce separation.
 A separation of duties between personnel assigned to the development/test
environments and those assigned to the production environment.
 Production data (live PANs) are not used for testing or development.
 Test data and accounts are removed before a production system becomes active.
 Change-control procedures related to implementing security patches and software
modifications are documented.

C20.7 6.4.1.a Examine network documentation and network device configurations to verify
that the development/test environments are separate from the production
environment(s)

6.4.1.b Examine access controls settings to verify that access controls are in place to
enforce separation between the development/test environments and the production
environment(s).
 Identify the access control settings examined for this testing procedure.

 NC 6.4.2 There is a separation of duties between personnel assigned to the
development/test environments and those assigned to the production
environment.

NC 6.4.3.a Observe testing processes and interview personnel to verify procedures are
in place to ensure production data (live PANs) are not used for testing or
development.

6.4.3.b Examine a sample of test data to verify production data (live PANs) is not
used for testing or development.
NC 6.4.4.a Observe testing processes and interview personnel to verify test data and
accounts are removed before a production system becomes active.

6.4.4.b Examine a sample of data and accounts from production systems recently
installed or updated to verify test data and accounts are removed before the
system becomes active.

NC 6.4.5.a Verify that change-control procedures related to implementing security

patches and software modifications are documented and require items 6.4.5.1 –
6.4.5.4 below.

6.4.5.b For a sample of system components and recent changes/security patches,

trace those changes back to related change control documentation. For each
change examined, perform the following:

NC 6.4.5.1 Verify that documentation of impact is included in the change control

documentation for each sampled change.
 NC 6.4.5.2 Verify that documented approval by authorized parties is present for each
sampled change.

C6.3 6.4.5.3.a For each sampled change, verify that functionality testing is performed to
verify that the change does not adversely impact the security of the system.

6.4.5.3.b For custom code changes, verify that all updates are tested for compliance
with PCI DSS Requirement 6.5 before being deployed into production.

NC 6.4.5.4 Verify that back-out procedures are prepared for each sampled change.

C6.7 6.5.a Examine software-development policies and procedures to verify that training in
secure coding techniques is required 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 Examine records of training to verify that software developers received training
on secure coding techniques, including how to avoid common coding vulnerabilities,
and understanding how sensitive data is handled in memory.

6.5.d. Verify that processes are in place to protect applications from, at a minimum,
the following vulnerabilities:

C6.1 6.5.1 Injection flaws, particularly SQL injection. (Validate input to verify user data
cannot modify meaning of commands and queries, utilize parameterized queries,
etc.)
NC 6.5.2 Buffer overflow (Validate buffer boundaries and truncate input strings.)

NC 6.5.3 Insecure cryptographic storage (Prevent cryptographic flaws)

6.5.4 Insecure communications (Properly encrypt all authenticated and sensitive

communications)
NC 6.5.5 Improper error handling (Do not leak information via error messages)

NA 6.5.6 All “High” vulnerabilities as identified in PCI DSS Requirement 6.2.

C6.1 6.5.7 Cross-site scripting (XSS) (Validate all parameters before inclusion, utilize
context-sensitive escaping, etc.)
NC 6.5.8 Improper Access Control, such as insecure direct object references, failure to
restrict URL access, and directory traversal (Properly authenticate users and sanitize
input. Do not expose internal object references to users.)

C6.1 6.5.9 Cross-site request forgery (CSRF). (Do not reply on authorization credentials
and tokens automatically submitted by browsers.)
6.5.10 Examine software development policies and procedures and interview
responsible personnel to verify that broken authentication and session
management are addressed via coding techniques that commonly include:
-Flagging session tokens (for example cookies) as “secure”
-Not exposing session IDs in the URL
-Incorporating appropriate time-outs and rotation of session IDs after a successful
login.
C13.12 6.6 For public-facing web applications, ensure that either one of the following
C6.1 methods are in place as follows:
C6.3
C11.6 - Verify that public-facing web applications are reviewed (using either manual or
automated vulnerability security assessment tools or methods), as follows:
- At least annually
- After any changes
- By an organization that specializes in application security
- That all vulnerabilities are corrected
- That the application is re-evaluated after the corrections
- Verify that a web-application firewall is in place in front of public-facing web
applications to detect and prevent web-based attacks.

Note: “An organization that specializes in application security” can be either a third-
party company or an internal organization, as long as the reviewers specialize in
application security and can demonstrate independence from the development team.
6.7 Examine documentation and interview personnel to verify that security policies
and operational procedures for developing and maintaining secure systems and
applications are:
-Documented,
-In use, and
-Known to all affected parties.
hat manage the systems. All critical systems must have the most recently released, appropriate software patches to protect against exploitation and
d applications, numerous vulnerabilities can be avoided by using standard system development processes and secure coding techniques.

able from major vendors such as Microsoft and Oracle.

ely easy to incorporate into launch processes.
ample, 6.1.a (renumbered 6.2 in DSS 3.0) demands that systems and software are verified to have

Selected Merchant Ty
ssment documentation, were not in place in about half of the organizations assessed.

Validation Instructions for QSA/ISA Priority A A-EP

(For In-Place Requirements)

Identify the documented policies and procedures examined to confirm that 0 1

processes are defined:
 To identify new security vulnerabilities.
 To assign a risk ranking to vulnerabilities that includes identification of all “high
risk” and “critical” vulnerabilities.
 To include using reputable outside sources for security vulnerability information. 3
<Report Findings Here>

Identify the responsible personnel interviewed who confirm that: 0 1

 New security vulnerabilities are identified.
 A risk ranking is assigned to vulnerabilities that includes identification of all “high”
risk and “critical” vulnerabilities.
 Processes to identify new security vulnerabilities include using reputable outside
sources for security vulnerability information.
<Report Findings Here>

Describe the processes observed to verify that:


New security vulnerabilities are identified.
A risk ranking is assigned to vulnerabilities to include identification of all “high” risk
and “critical” vulnerabilities. 3
Processes to identify new security vulnerabilities include using reputable outside
sources for security vulnerability information.
Identify the outside sources used.
<Report Findings Here>
Identify the documented policies and procedures related to security-patch 0 1
installation examined to verify processes are defined for:
 Installation of applicable critical vendor- supplied security patches within one
month of release.
 Installation of all applicable vendor-supplied security patches within an
appropriate time frame. 3
<Report Findings Here>

Identify the sample of system components and related software selected for this 0 1
testing procedure.
<Report Findings Here>
Identify the vendor security patch list reviewed.
<Report Findings Here>
For each item in the sample, describe how the list of security patches installed on
each system was compared to the most recent vendor security-patch list to verify
that:
Applicable critical vendor-supplied security patches are installed within one month
of release.
All applicable vendor-supplied security patches are installed within an appropriate
time frame. 3
<Report Findings Here>

Identify the document that defines software development processes based on 0 0

industry standards and/or best practices.
<Report Findings Here>

Identify the industry standards and/or best practices used. 3

<Report Findings Here>

Identify the documented software development processes examined to verify that 0 0

information security is included throughout the life cycle.
<Report Findings Here> 3

Identify the documented software development processes examined to verify that 0 0

software applications are developed in accordance with PCI DSS.
<Report Findings Here> 3

Identify the software developers interviewed for this testing procedure. 0 0

<Report Findings Here>

For the interview, summarize the relevant details discussed to verify that written
software development processes are implemented. 3
<Report Findings Here>
Identify the documented software-development processes examined to verify 0 0
processes define that pre-production and/or custom application accounts, user IDs
and/or passwords are removed before an application goes into production or is
released to customers.
<Report Findings Here>

Identify the responsible personnel interviewed for this testing procedure.

<Report Findings Here>

For the interview, summarize the relevant details discussed to confirm that pre-
production and/or custom application accounts, user IDs and/or passwords are 3
removed before an application goes into production or is released to customers.
<Report Findings Here>

Identify the documented software-development processes examined to verify 0 0

processes define 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.
<Report Findings Here>

Identify the responsible personnel interviewed for this testing procedure who
confirm that all custom application code changes are reviewed 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). 3
 Appropriate corrections are implemented prior to release.
 Code-review results are reviewed and approved by management prior to release.

Describe how all custom application code changes must be reviewed, including
whether processes are manual or automated.
<Report Findings Here>
Identify the sample of recent custom application changes selected for this testing 0 0
procedure.
<Report Findings Here>

For each item in the sample, describe how code review processes were observed to
verify custom application code is reviewed as follows:
Code changes are reviewed by individuals other than the originating code author.
<Report Findings Here>

Code changes are reviewed by individuals who are knowledgeable in code-review

techniques and secure coding practices.
<Report Findings Here>
Code reviews ensure code is developed according to secure coding guidelines (see
PCI DSS Requirement 6.5).
<Report Findings Here>
3
Appropriate corrections are implemented prior to release.
<Report Findings Here>

Code-review results are reviewed and approved by management prior to release.

<Report Findings Here>

Left blank by PCIco 0 0

Identify the network documentation that illustrates that the development/test 0 0

environments are separate from the production environment(s).
<Report Findings Here>
Describe how network device configurations were examined to verify that the
development/test environments are separate from the production environment(s). 3
<Report Findings Here>

Identify the access control settings examined for this testing procedure. 0 0
<Report Findings Here>

Describe how the access control settings were examined to verify that access
controls are in place to enforce separation between the development/test
environments and the production environment(s). 3
<Report Findings Here>
Identify the personnel assigned to development/test environments interviewed 0 0
who confirm that separation of duties is in place between development/test
environments and the production environment.
<Report Findings Here>

Identify the personnel assigned to production environments interviewed who

confirm that separation of duties is in place between development/test
environments and the production environment.
<Report Findings Here>

Describe how processes were observed to verify that separation of duties is in place
between development/test environments and the production environment.
<Report Findings Here>

Identify the personnel interviewed who confirm that procedures are in place to 0 0
ensure production data (live PANs) are not used for testing or development.
<Report Findings Here>

Describe how testing processes were observed to verify procedures are in place to
ensure production data (live PANs) are not used for testing.
<Report Findings Here>

Describe how testing processes were observed to verify procedures are in place to 3
ensure production data (live PANs) are not used for development.
<Report Findings Here>

Describe how a sample of test data was examined to verify production data (live 0 0
PANs) is not used for testing.
<Report Findings Here>
Describe how a sample of test data was examined to verify production data (live
PANs) is not used for development. 3
<Report Findings Here>.
Identify the personnel interviewed who confirm that test data and accounts are 0 0
removed before a production system becomes active.
<Report Findings Here>

Describe how testing processes were observed to verify that test data is removed
before a production system becomes active.
<Report Findings Here>
Describe how testing processes were observed to verify that test accounts are 3
removed before a production system becomes active.
<Report Findings Here>

Describe how a sample of test data from production systems recently installed or 0 0
updated was examined to verify test data is removed before the system becomes
active.
<Report Findings Here>

Describe how a sample of test accounts from production systems recently installed
or updated was examined to verify test accounts are removed before the system 3
becomes active.
<Report Findings Here>

Identify the documented change-control procedures related to implementing 0 1

security patches and software modification examined to verify procedures are
defined for:
 Documentation of impact.
 Documented change approval by
authorized parties.
 Functionality testing to verify that the change does not adversely impact the
security of the system. 6
 Back-out procedures.
<Report Findings Here>

Identify the sample of system components selected. 0 0

<Report Findings Here>
Identify the responsible personnel interviewed to determine recent
changes/security patches.
<Report Findings Here>

For each item in the sample, identify the sample of changes and the related change 6
control documentation selected for this testing procedure (through 6.4.5.4)
<Report Findings Here>

For each change from 6.4.5.b, describe how the changes were traced back to the 0 1
identified related change control documentation to verify that documentation of
impact is included in the change control documentation for each sampled change.
<Report Findings Here> 6
For each change from 6.4.5.b, describe how the changes were traced back to the 0 1
identified related change control documentation to verify that documented
approval by authorized parties is present in the change control documentation for
each sampled change. 6
<Report Findings Here>

For each change from 6.4.5.b, describe how the changes were traced back to the 0 1
identified related change control documentation to verify that the change control
documentation for each sampled change includes evidence that functionality
testing is performed to verify that the change does not adversely impact the
security of the system.
<Report Findings Here> 6

Identify the sample of system components selected for this testing procedure. 0 1
<Report Findings Here>
For each item in the sample, identify the sample of custom code changes and the
related change control documentation selected for this testing procedure.
<Report Findings Here>
Describe how the custom code changes were traced back to the identified related
change control documentation to verify that the change control documentation for
each sampled custom code change includes evidence that all updates are tested for 6
compliance with PCI DSS Requirement 6.5 before being deployed into production.
<Report Findings Here>

For each change from 6.4.5.b, describe how the changes were traced back to the 0 1
identified related change control documentation to verify that back-out procedures
are prepared for each sampled change and present in the change control
documentation for each sampled change.
<Report Findings Here> 6

Identify the document requiring that developers are trained in secure coding 0 0
techniques. 
<Report Findings Here>
3
Identify the industry best practices and guidance that training is based on.
<Report Findings Here>

Identify the sample of developers interviewed. 0 0

<Report Findings Here>

For the interview, summarize the relevant details discussed to verify that they are
knowledgeable in secure coding techniques. 3
<Report Findings Here>
Identify the records of training that were examined to verify that software 0 0
developers received training on secure coding techniques, including how to avoid
common coding vulnerabilities, and understanding how sensitive data is handled in
memory.
<Report Findings Here>

Identify the software-development policies and procedures examined to verify that 0 0

processes are in place to protect applications from, at a minimum, the following
vulnerabilities:
<Report Findings Here>

Identify the responsible personnel interviewed to verify that processes are in place
to protect applications from, at a minimum, the following vulnerabilities:
<Report Findings Here>
3

IFor the interviews at 6.5.d, summarize the relevant interview details that confirm 0 1
processes are in place, consistent with the software development documentation at
6.5.d, to ensure that injection flaws are addressed by coding techniques that
include:

Validating input to verify user data cannot modify meaning of commands and
queries.
Utilizing parameterized queries.
<Report Findings Here>

3
For the interviews at 6.5.d, summarize the relevant interview details that confirm 0 1
processes are in place, consistent with the software development documentation at
6.5.d, to ensure that buffer overflows are addressed by coding techniques that
include:

Validating buffer boundaries.

Truncating input strings.
<Report Findings Here>

For the interviews at 6.5.d, summarize the relevant interview details that confirm 0 0
processes are in place, consistent with the software development documentation at
6.5.d, to ensure that insecure cryptographic storage is addressed by coding
techniques that:
3
Prevent cryptographic flaws.
Use strong cryptographic algorithms and keys.
<Report Findings Here>

For the interviews at 6.5.d, summarize the relevant interview details that confirm 0 0
processes are in place, consistent with the software development documentation at
6.5.d, to ensure that insecure communications are addressed by coding techniques
that properly:

Authenticate all sensitive communications.

Encrypt all sensitive communications. 3
<Report Findings Here>
For the interviews at 6.5.d, summarize the relevant interview details that confirm 0 0
processes are in place, consistent with the software development documentation at
6.5.d, to ensure that improper error handling is addressed by coding techniques
that do not leak information via error messages.
<Report Findings Here>

For the interviews at 6.5.d, summarize the relevant interview details that confirm 0 0
processes are in place, consistent with the software development documentation at
6.5.d, to ensure that applications are not vulnerable to “High” vulnerabilities, as
identified in PCI DSS Requirement 6.1.
<Report Findings Here> 3

Identify whether web applications and application interfaces are present. (yes/no) 0 1
<Report Findings Here>

If “no,” mark the below 6.5.8-6.5.11 as “Not Applicable.”

If “yes,” complete the following:

For the interviews at 6.5.d, summarize the relevant interview details that confirm
processes are in place, consistent with the software development documentation at
6.5.d, to ensure that cross-site scripting (XSS) is addressed by coding techniques
that include: 3

Validating all parameters before inclusion.

Utilizing context-sensitive escaping.
<Report Findings Here>
Identify whether web applications and application interfaces are present. (yes/no) 0 1
<Report Findings Here>

If “no,” mark the below 6.5.8-6.5.11 as “Not Applicable.”

If “yes,” complete the following:

For the interviews at 6.5.d, summarize the relevant interview details that confirm
processes are in place, consistent with the software development documentation at
6.5.d, to ensure that improper access control is addressed by coding techniques
that include:
Proper authentication of users.
Sanitizing input.
Not exposing internal object references to users.
User interfaces that do not permit access to unauthorized functions.
<Report Findings Here> 3

Identify whether web applications and application interfaces are present. (yes/no) 0 1
<Report Findings Here>

If “no,” mark the below 6.5.8-6.5.11 as “Not Applicable.”

If “yes,” complete the following:

For the interviews at 6.5.d, summarize the relevant interview details that confirm
processes are in place, consistent with the software development documentation at
6.5.d, to ensure that cross-site request forgery (CSRF) is addressed by coding
techniques that ensure applications do not rely on authorization credentials and 3
tokens automatically submitted by browsers.
<Report Findings Here>
Identify whether web applications and application interfaces are present. (yes/no) 0 1
<Report Findings Here>

If “no,” mark the below 6.5.8-6.5.11 as “Not Applicable.”

If “yes,” complete the following:

Indicate whether this ROC is being completed prior to June 30, 2015. (yes/no)
<Report Findings Here>

If “yes” AND the assessed entity does not have this in place ahead of the
requirement’s effective date, mark the remainder of 6.5.10 as “Not Applicable.”
If “no” OR if the assessed entity has this in place ahead of the requirement’s
effective date, complete the following:
For the interviews at 6.5.d, summarize the relevant interview details that confirm
processes are in place, consistent with the software development documentation at
6.5.d, to ensure that broken authentication and session management are addressed
via coding techniques that protect credentials and session IDs, including: 3

Flagging session tokens (for example cookies) as “secure.”

Not exposing session IDs in the URL.
Implementing appropriate time-outs and rotation of session IDs after a successful
login
<Report Findings Here>
For each public-facing web application, identify which of the two methods are 0 1
implemented:
 Web application vulnerability security assessments, AND/OR
 Automated technical solution that detects and prevents web-based attacks, such
as web application firewalls.
<Report Findings Here>
If application vulnerability security assessments are indicated above:

Describe the tools and/or methods used (manual or automated, or a combination

of both).
Identify the organization(s) confirmed to specialize in application security that is
performing the assessments.
<Report Findings Here>

Identify the documented processes that were examined to verify that public-facing
web applications are reviewed using the tools and/or methods indicated above, as
follows:
 At least annually.
 After any changes.
 By an organization that specializes in application security.
 That, at a minimum, all vulnerabilities in Requirement 6.5 are included in the
assessment.
 That all vulnerabilities are corrected
 That the application is re-evaluated after the corrections.
<Report Findings Here>

Identify the responsible personnel interviewed who confirm that public-facing web
applications are reviewed, as follows:
 At least annually.
 After any changes.
 By an organization that specializes in application security.
 That, at a minimum, all vulnerabilities in Requirement 6.5 are included in the
assessment.
 That all vulnerabilities are corrected.
 That the application is re-evaluated after the corrections.
<Report Findings Here>

3
 3
Identify the records of application security assessments examined for this testing
procedure.
<Report Findings Here>

Describe how the records of application security assessments were examined to

verify that public-facing web applications are reviewed as follows:
At least annually.
 After any changes.
 By an organization that specializes in application security.
 That, at a minimum, all vulnerabilities in Requirement 6.5 are included in the
assessment.
 That all vulnerabilities are corrected.
 That the application is re-evaluated after the corrections.
<Report Findings Here>

If an automated technical solution that detects and prevents web-based attacks (for
example, a web-application firewall) is indicated above:

Describe the automated technical solution in use that detects and prevents web-
based attacks.
Identify the responsible personnel interviewed who confirm that the above
automated technical solution in use to detect and prevent web-based attacks is in
place as follows:
 Is situated in front of public-facing web applications to detect and prevent web-
based attacks.
 Is actively running and up-to-date as applicable.
 Is generating audit logs.
 Is configured to either block web-based attacks, or generate an alert.
<Report Findings Here>

Describe how the system configuration settings were examined to verify that the
above automated technical solution is use to detect and prevent web-based attacks
is in place as follows:

 Is situated in front of public-facing web applications to detect and prevent web-

based attacks.
 Is actively running and up-to-date as applicable.
 Is generating audit logs.
 Is configured to either block web-based attacks, or generate an alert.
Identify the document reviewed to verify that security policies and operational 0 0
procedures for developing and maintaining secure systems and applications are
documented.
<Report Findings Here>
Identify responsible personnel interviewed who confirm that the above
documented security policies and operational procedures for developing and
maintaining secure systems and applications are:
 In use
 Known to all affected parties 6
<Report Findings Here>

150 0 17
ct against exploitation and compromise of cardholder data by malicious individuals and malicious software.
g techniques.

d Merchant Types D

PE2P B B-IP C-VT C D S In Place? Severity Proofs /

Documentation links

0 0 1 1 1 1 1

N 4

0 0 1 1 1 1 1

N 4
0 0 1 1 1 1 1

N 4

0 0 1 1 1 1 1

N 4

0 0 0 0 0 1 1

N 4

0 0 0 0 0 1 1
N 4

0 0 0 0 0 1 1
N 4

0 0 0 0 0 1 1

N 4
0 0 0 0 0 1 1

N 4

0 0 0 0 0 1 1

N 4
0 0 0 0 0 1 1

N 4

0 0 0 0 0 1 1

N 4

0 0 0 0 0 1 1

N 4

0 0 0 0 0 1 1

N 4
0 0 0 0 0 1 1

N 4

0 0 0 0 0 1 1

N 4

0 0 0 0 0 1 1

N 4
0 0 0 0 0 1 1

N 4

0 0 0 0 0 1 1

N 4

0 0 0 0 0 1 1

N 1

0 0 0 0 0 1 1

N 1

0 0 0 0 0 1 1

N 1
0 0 0 0 0 1 1

N 1

0 0 0 0 0 1 1

N 1

0 0 0 0 0 1 1

N 1

0 0 0 0 0 1 1

N 1

0 0 0 0 0 1 1

N 4

0 0 0 0 0 1 1

N 4
0 0 0 0 0 1 1

N 4

0 0 0 0 0 1 1

N 4

0 0 0 0 0 1 1

N 4
0 0 0 0 0 1 1

N 4

0 0 0 0 0 1 1

N 4

0 0 0 0 0 1 1

N 4
0 0 0 0 0 1 1

N 4

0 0 0 0 0 1 1

N 4

0 0 0 0 0 1 1

N 4
0 0 0 0 0 1 1

N 4

0 0 0 0 0 1 1

N 4
0 0 0 0 0 1 1

N 4
0 0 0 0 0 1 1

N 4
 N 4

0 0 0 0 0 1 1

Y 0

0 0 4 4 4 42 42 Y 143
N
C
NA
NT
Stage of implementation Remediation plan
Estimated date for completion Comments Owner
Return to Table of content Go to Req 6
Requirement 7: Restrict access to cardholder data by business need to know
To ensure critical data can only be accessed by authorized personnel, systems and processes must be in place to limit access based on
“Need to know” is when access rights are granted to only the least amount of data and privileges needed to perform a job.

Major Observations 2014 Verizon PCI Compliance Report:

-The subcontrols most-often complied with cover technical considerations: the implementation of automated access-control systems
-More than 80% of organizations were compliant with each of these subcontrols.
-The subcontrols least-often complied with showed that organizations are struggling with role-based access controls and defining leas
-Only73.3% of organizations met control 7.1.2,which requires that privileges are assigned to individuals based on job classification and
-Just 68.3% of companies complied with7.1.1,which requires that access rights for privileged user IDs are restricted to the least privile
-A mere 65.3% of companies were compliant with7.2.2,which requires that access-control systems are configured to enforce privilege

PCI DSS Requirement Guidance

7.1Limit access to system components and The more people who have access to cardholder
cardholder data to only those individuals whose job data, the more risk there is that a user’s account will
requires such access. Access limitations must be used maliciously. Limiting access to those with a
include the following: legitimate business reason for the access helps an
organization prevent mishandling of cardholder
data through inexperience or malice.

7.1.1 Define access needs for each role, including: In order to limit access to cardholder data to only
􏰁 System components and data resources that each those individuals who need such access, first it is
role needs to access for their job function necessary to define access needs for each role (for
􏰁 Level of privilege required (for example, user, example, system administrator, call center
administrator, etc.) for accessing resources. personnel, store clerk), the systems/devices/data
each role needs access to, and the level of privilege
each role needs to effectively perform assigned
tasks. Once roles and corresponding access needs
are defined, individuals can be granted access
accordingly.

7.1.2 Restrict access to privileged user IDs to least When assigning privileged IDs, it is important to
privileges necessary to perform job responsibilities. assign individuals only the privileges they need to
perform their job (the “least privileges”). For
example, the database administrator or backup
administrator should not be assigned the same
privileges as the overall systems administrator.
 example, the database administrator or backup
administrator should not be assigned the same
privileges as the overall systems administrator.

7.1.3 Assign access based on individual Once needs are defined for user roles (per PCI DSS
personnel’s job classification and function. requirement 7.1.1), it is easy to grant individuals
access according to their job classification and
function by using the already-created roles.

7.1.4 Require documented approval by Documented approval (for example, in writing or

authorized parties specifying required privileges. electronically) assures that those with access and
privileges are known and authorized by
management, and that their access is necessary for
their job function.

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

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

7.3 Ensure that security policies and operational

procedures for restricting access to cardholder
data are documented, in use, and known to all
affected parties.
 Go to Req 8 Executive Summary

must be in place to limit access based on need to know and according to job responsibilities.
ges needed to perform a job.

n of automated access-control systems (7.1.4) to cover all system components (7.2.1), with “deny all” set by default (7.2.3).

-based access controls and defining least privilege:

dividuals based on job classification and function.
ser IDs are restricted to the least privileges necessary to perform job responsibilities.
tems are configured to enforce privileges assigned to individuals based on job classification and function.

SANS Testing Procedure

Top 20 Critical
Security Controls

C12.1.1 7.1.a Examine written policy for access control, and verify that the policy incorporates
7.1.1 through 7.1.4 as follows:
- Defining access needs and privilege assignments for each role
- Restriction of access to privileged user IDs to least privileges
necessary to perform job responsibilities
- Assignment of access based on individual personnel’s job
classification and function
- Documented approval (electronically or in writing) by
authorized parties for all access, including listing of specific privileges approved.

7.1.1 Select a sample of roles and verify access needs for each role are defined and
include:
􏰁 System components and data resources that each role needs to access for their job
function
􏰁 Identification of privilege necessary for each role to perform their job function.

C12.6 7.1.2.a Interview personnel responsible for assigning access to verify that access to
C12.7 privileged user IDs is:
-Assigned only to roles that specifically require such privileged access
-Restricted to least privileges necessary to perform job responsibilities.
 7.1.2.b Select a sample of user IDs with privileged access and interview responsible
management personnel to verify that privileges assigned are:
􏰁 Necessary for that individual’s job function
􏰁 Restricted to least privileges necessary to perform job responsibilities.

NC 7.1.3 Select a sample of user IDs and interview responsible management personnel
to verify that privileges assigned are based on that individual’s job classification and
function.

NC 7.1.4 Select a sample of user IDs and compare with documented approvals to verify
that:
- Documented approval exists for the assigned privileges
- The approval was by authorized parties
-That specified privileges match the roles assigned to the individual.

C12.14 7.2 Examine system settings and vendor documentation to verify that an access
C15.3 control system is implemented as follows:
 NC 7.2.1 Confirm that access control systems are in place on all system components.

C12.14 7.2.2 Confirm that access control systems are configured to enforce privileges
assigned to individuals based on job classification and function.

NC 7.2.3 Confirm that the access control systems have a default “deny-all” setting.

7.3 Examine documentation interview personnel to verify that security policies and
operational procedures for restricting access to cardholder data are:
􏰁 Documented,
􏰁 In use, and
􏰁 Known to all affected parties.
efault (7.2.3).

Selected Merchant Ty

Validation Instructions for QSA/ISA Priority A

(For In-Place Requirements)

Identify the written policy for access control that was examined to verify the policy 4 0
incorporates 7.1.1 through 7.1.4 as follows:
 Defining access needs and privilege assignments for each role.
 Restriction of access to privileged user IDs to least privileges necessary to perform
job responsibilities.
 Assignment of access based on individual personnel’s job classification and
function
 Documented approval (electronically or in writing) by authorized parties for all
access, including listing of specific privileges approved.
<Report Findings Here>

Identify the selected sample of roles for this testing procedure. 4 0

<Report Findings Here>

For each role in the selected sample, describe how the role was examined to verify
access needs for each role are defined and include:
<Report Findings Here>

System components and data resources that each role needs to access for their job
function.
<Report Findings Here>
Identification of privilege necessary for each role to perform their job function.
<Report Findings Here>

Identify the responsible personnel interviewed who confirm that access to 4 0

privileged user IDs is:
 Assigned only to roles that specifically require such privileged access.
 Restricted to least privileges necessary to perform job responsibilities.
<Report Findings Here>
Identify the sample of user IDs with privileged access selected for this testing 4 0
procedure.
<Report Findings Here>

Identify the responsible management personnel interviewed to confirm that

privileges assigned are:
 Necessary for that individual’s job function.
 Restricted to least privileges necessary to perform job responsibilities.
<Report Findings Here>

For the interview, summarize the relevant details discussed to confirm that
privileges assigned to each user ID in the selected sample are:

Necessary for that individual’s job function.

Restricted to least privileges necessary to perform job responsibilities.
<Report Findings Here>

Identify the sample of user IDs examined for this testing procedure. 4 0
<Report Findings Here>

Identify the responsible management personnel interviewed who confirm that

privileges assigned are based on that individual’s job classification and function.
<Report Findings Here>
For the interview, summarize the relevant details discussed to confirm that
privileges assigned to each user ID in the selected sample are based on an
individual’s job classification and function.
<Report Findings Here>

Identify the sample of user IDs examined for this testing procedure. 4 0
<Report Findings Here>

Describe how each item in the sample of user IDs was compared with documented
approvals to verify that:
Documented approval exists for the assigned privileges.
<Report Findings Here>

The approval was by authorized parties.

<Report Findings Here>

That specified privileges match the roles assigned to the individual.

<Report Findings Here>

Left blank by PCIco 4 0

Identify vendor documentation examined. 4 0
<Report Findings Here>

Describe how system settings were examined with the vendor documentation to
verify that access control systems are in place on all system components.
<Report Findings Here>

Describe how system settings were examined with the vendor documentation at 4 0
7.2.1 to verify that access control systems are configured to enforce privileges
assigned to individuals based on job classification and function.
<Report Findings Here>

Describe how system settings were examined with vendor documentation at 7.2.1 4 0
to verify that access control systems have a default “deny-all” setting.
<Report Findings Here>

Identify the document reviewed to verify that security policies and operational 0
procedures for restricting access to cardholder data are documented.
<Report Findings Here>

Identify responsible personnel interviewed who confirm that the above

documented security policies and operational procedures for restricting access to
cardholder data are: 6
 Inuse
 Known to all affected parties
<Report Findings Here>

46 0
cted Merchant Type D

A-EP PE2P B B-IP C-VT C D S In place Severity Proofs /

Documentation links

0 0 1 1 1 1 1 1 NT 3

0 0 0 0 0 1 1 1 Y 0

1 0 1 1 1 1 1 1 C 0
1 0 1 1 1 1 1 1 C 0

1 0 1 1 1 1 1 1 C 0

0 0 0 0 0 0 1 1 N 3

0 0 0 0 0 0 1 1 C 0
0 0 0 0 0 0 1 1 C 0

0 0 0 0 0 0 1 1 C 0

0 0 0 0 0 0 1 1 C 0

0 0 0 0 0 0 1 1 N 1

3 0 4 4 4 5 11 11 Y 7
N
C
NA
NT
Stage of implementation Remediation plan
Estimated date for completion Comments Owner
Return to Table of content Go to Req 7
Requirement 8: Identify and authenticate access to system components
Assigning a unique identification (ID) to each person with access ensures that each individual is uniquely accoun
Major Observations from the 2014 Verizon PCI Compliance report:
-According to our RISK team’s assessments, only 24.2% of organizations that suffered a security breach were compliant with Requirem
-Average compliance with Requirement 8: 84,1%
-Seven of the subcontrols (8.5.10.b, 8.5.12.b, 8.5.13.b, 8.5.9.b, 8.4.b, 8.5.11.b, 8.5.7) are met with over 90% compliance.
-But a mere 57.4% of organizations complied with 8.5.1, which governs the addition, deletion, and modification of IDs and credentials
-62.4% of organizations complied with 8.5.15, which specifies that idle sessions expire after no more than 15 minutes
-62.4% of organizations complied with 8.5.13.a, which requires that users are locked out after no more than six failed login attempts
-55.4% complied with both (8.5.15 and 8.5.13.a ), 13.9% with just one, and 30.7% with neither.

PCI DSS Requirement Guidance

8.1 Define and implement policies and By ensuring each user is uniquely identified—
procedures to ensure proper user identification instead of using one ID for several employees—
management for non- consumer users and an organization can maintain individual
administrators on all system components as responsibility for actions and an effective audit
follows: trail per employee. This will help speed issue
resolution and containment when misuse or
malicious intent occurs.

8.1.1 Assign all users a unique ID before allowing

them to access system components or cardholder
data.
8.1.2 Control addition, deletion, and modification of To ensure users added to your systems are all valid
user IDs, credentials, and other identifier objects. 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.

8.1.3 Immediately revoke access for any terminated If an employee has left the company, and still has
users. access to the network via their user account,
unnecessary or malicious access to cardholder data
could occur. This access could happen from the
former employee or from a malicious user who
exploits the older and/or unused account. Consider
implementing a process with Human Resources for
immediate notification when an employee is
terminated so that the user account can be quickly
deactivated.

8.1.4 Remove/disable inactive user accounts at least Existence of inactive accounts allows an
every 90 days. unauthorized user exploit the unused account to
potentially access cardholder data.

8.1.5 Manage IDs used by vendors to access, Allowing vendors to have 24/7 access into your
support, or maintain system components via network in case they need to support your systems
remote access as follows: increases the chances of unauthorized access,
- Enabled only during the time period needed and either from a user in the vendor’s environment or
disabled when not in use. from a malicious individual who finds and uses this
- Monitored when in use. always-available external entry point into your
network. Enabling access only for the time periods
needed, and disabling it as soon as it is no longer
needed, helps prevent misuse of these connections.
Monitoring of vendor access provides assurance
that vendors are accessing only the systems
necessary and only during approved time frames.
8.1.6 Limit repeated access attempts by locking out Without account-lockout mechanisms in place, an
the user ID after not more than six attempts. attacker can continually attempt to guess a
password through manual or automated tools (for
example, password cracking), until they achieve
success and gain access to a user’s account.

8.1.7 Set the lockout duration to a minimum of 30 If an account is locked out due to someone
minutes or until administrator enables the user ID. 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.

8.1.8 If a session has been idle for more than 15 When users walk away from an open machine with
minutes, require the user to re-authenticate to re- access to critical network or cardholder data, that
activate the terminal or session. machine may be used by others in the user’s
absence, resulting in unauthorized account access
and/or account misuse.
8.2 In addition to assigning a unique ID, ensure These authentication methods, when used in
proper user-authentication management for non- addition to unique IDs, help protect users’ IDs from
consumer users and administrators on all system being compromised, since the one attempting the
components by employing at least one of the compromise needs to know both the unique ID and
following methods to authenticate all users: the password (or other authentication used). Note
-Something you know, such as a password or that a digital certificate is a valid option for
passphrase “something you have” as long as it is unique for a
-Something you have, such as a token device or particular user.
smart card Since one of the first steps a malicious individual
-Something you are, such as a biometric. will take to compromise a system is to exploit weak
or nonexistent passwords, it is important to
implement good processes for authentication
management.

8.2.1 Using strong cryptography, render all Many network devices and applications transmit the
authentication credentials (such as user ID and unencrypted password across the
passwords/phrases) unreadable during network and/or also store the passwords without
transmission and storage on all system encryption. A malicious individual can easily
intercept the unencrypted or readable user ID and
components. password during transmission using a “sniffer,” or
directly access the user IDs and unencrypted
passwords in files where they are stored, and use
this stolen data to gain unauthorized access. During
transmission, the user credentials can be encrypted
or the tunnel can be encrypted
8.2.2 Verify user identity before modifying any Many malicious individuals use "social
authentication credential—for example, engineering”—for example, calling a help desk and
performing password resets, provisioning new acting as a legitimate user—to have a password
tokens, or generating new keys. changed so they can utilize a user ID. Consider use
of a “secret question” that only the proper user can
answer to help administrators identify the user
prior to re-setting passwords. Ensure such questions
are secured properly and not shared.

8.2.3 Passwords/phrases must meet the following: Strong passwords/phrases are the first line of
-Require a minimum length of at least seven defense into a network since a malicious individual
characters. will often first try to find accounts with weak or
-Contain both numeric and alphabetic characters. non- existent passwords. If passwords are short or
simple to guess, it is relatively easy for a malicious
Alternatively, the passwords/phrases must have individual to find these weak accounts and
complexity and strength at least equivalent to the compromise a network under the guise of a valid
parameters specified above. user ID.
This requirement specifies that a minimum of seven
characters and both numeric and alphabetic
characters should be used for passwords/phrases.
For cases where this minimum cannot be met due
to technical limitations, entities can use “equivalent
strength” to evaluate their alternative. NIST SP 800-
63-1 defines “entropy” as “a measure of the
difficulty of guessing or determining a password or
key.” This document and others that discuss
“password entropy” can be referred to for more
information on applicable entropy value and for
understanding equivalent password strength
variability for passwords/phrases of different
formats.
8.2.4 Change user passwords at least every 90 Strong passwords are the first line of defense into a
days. network since a malicious individual will often first
try to find accounts with weak or non-existent
passwords. There is more time for a malicious
individual to find these weak accounts, and
compromise a network under the guise of a valid
user ID, if passwords are short, simple to guess, or
valid for a long time without a change. Strong
passwords can be enforced and maintained per
these requirements by enabling the password and
account security features that come with your
operating system (for example, Windows),
networks, databases and other platforms.

8.2.5 Do not allow an individual to submit a new If password history isn’t maintained, the
password that is the same as any of the last four effectiveness of changing passwords is reduced, as
passwords he or she has used. previous passwords can be reused over and over.
Requiring that passwords cannot be reused for a
period of time reduces the likelihood that
passwords that have been guessed or brute-forced
will be used in the future.

8.2.6 Set passwords for first-time use and resets If the same password is used for every new user set
to a unique value for each user and change up, an internal user, former employee, or malicious
immediately after the first use. individual may know or easily discover this
password, and use it to gain access to accounts.
8.3 Incorporate two-factor authentication for Two-factor authentication requires two forms of
remote network access originating from authentication for higher-risk accesses, such as
outside the network by personnel (including those originating from outside your network. For
users and administrators) and all third parties, additional security, your organization can also
consider using two-factor authentication when
(including vendor access for support or accessing networks of higher security from
maintenance). networks of lower security—for example, from
corporate desktops (lower security) to production
servers/databases with cardholder data (high
security).
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 entity’s own
network, either from the Internet or from an
“untrusted” network or system, such as a third
party or an employee accessing the entity’s 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 entity’s 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 entity’s
networks.

8.4 Document and communicate authentication Communicating password/authentication

procedures and policies to all users including: procedures to all users helps those users
-Guidance on selecting strong authentication understand and abide by the policies.
credentials For example, guidance on selecting strong
-Guidance for how users should protect their passwords may include suggestions to help
authentication credentials personnel select hard-to-guess passwords that
-Instructions not to reuse previously used don’t contain dictionary words, and that don’t
passwords contain information about the user (such as the
-Instructions to change passwords if there is any user ID, names of family members, date of birth,
suspicion the password could be compromised. etc.). Guidance for protecting authentication
credentials may include not writing down
passwords or saving them in insecure files, and
being alert for malicious individuals who may
attempt to exploit their passwords (for example, by
calling an employee and asking for their password
so the caller can “troubleshoot a problem”).
Instructing users to change passwords if there is a
chance the password is no longer secure can
prevent malicious users from using a legitimate
authentication credentials personnel select hard-to-guess passwords that
-Instructions not to reuse previously used don’t contain dictionary words, and that don’t
passwords contain information about the user (such as the
-Instructions to change passwords if there is any user ID, names of family members, date of birth,
suspicion the password could be compromised. etc.). Guidance for protecting authentication
credentials may include not writing down
passwords or saving them in insecure files, and
being alert for malicious individuals who may
attempt to exploit their passwords (for example, by
calling an employee and asking for their password
so the caller can “troubleshoot a problem”).
Instructing users to change passwords if there is a
chance the password is no longer secure can
prevent malicious users from using a legitimate
password to gain unauthorized access.

8.5 Do not use group, shared, or generic accounts If multiple users share the same authentication
and passwords, or other authentication methods. credentials (for example, user account and
password), it becomes impossible to trace system
access and activities to an individual. This in turn
prevents an entity from assigning accountability for,
or having effective logging of, an individual’s
actions, since a given action could have been
performed by anyone in the group that has
knowledge of the authentication credentials.
8.5.1 Additional requirement for service providers: To prevent the compromise of multiple customers
Service providers with remote access to customer through the use of a single set of credentials,
premises (for example, for support of POS systems vendors with remote access accounts to customer
or servers) must use a unique authentication environments should use a different authentication
credential (such as a password/phrase) for each credential for each customer.
customer. Technologies, such as two-factor mechanisms, that
provide a unique credential for each connection (for
example, via a single-use password) could also meet
the intent of this requirement.

8.6 Where other authentication mechanisms are If user authentication mechanisms such as tokens,
used (for example, physical or logical security smart cards, and certificates can be used by
tokens, smart cards, certificates, etc.), use of these multiple accounts, it may be impossible to identify
mechanisms must be assigned as follows: the individual using the authentication mechanism.
-Authentication mechanisms must be assigned to an Having physical and/or logical controls (for example,
individual account and not shared among multiple a PIN, biometric data, or a password) to uniquely
accounts. identify the user of the account will prevent
-Physical and/or logical controls must be in place to unauthorized users from gaining access through use
ensure only the intended account can use that of a shared authentication mechanism.
mechanism to gain access.

8.7 All access to any database containing cardholder Without user authentication for access to databases
data (including access by applications, and applications, the potential for unauthorized or
administrators, and all other users) is restricted as malicious access increases, and such access cannot
follows: be logged since the user has not been authenticated
- All user access to, user queries of, and user actions and is therefore not known to the system. Also,
on databases are through programmatic methods. database access should be granted through
-Only database administrators have the ability to programmatic methods only (for example, through
directly access or query databases. stored procedures), rather than via direct access to
- Application IDs for database applications can only the database by end users (except for DBAs, who
be used by the applications (and not by individual may need direct access to the database for their
users or other non-application processes). administrative duties).
on databases are through programmatic methods. database access should be granted through
-Only database administrators have the ability to programmatic methods only (for example, through
directly access or query databases. stored procedures), rather than via direct access to
- Application IDs for database applications can only the database by end users (except for DBAs, who
be used by the applications (and not by individual may need direct access to the database for their
users or other non-application processes). administrative duties).

8.8 Ensure that security policies and operational Personnel need to be aware of and following
procedures for identification and authentication are security policies and operational procedures for
documented, in use, and known to all affected managing identification and authorization on a
parties. continuous basis.
 Go To Req 9 Executive Summary

each individual is uniquely accountable for his or her actions. When such accountability is in place, actions taken on critical d

y breach were compliant with Requirement 8 at the time of their breach.

with over 90% compliance.

, and modification of IDs and credentials.
o more than 15 minutes
no more than six failed login attempts
.

SANS Testing Procedure

Top 20 Critical
Security Controls
C12.7 8.1.a Review procedures and confirm they define processes for each of the
items below at 8.1.1 through 8.1.8

8.1.b Verify that procedures are implemented for user identification

management, by performing the following:

8.1.1 Interview administrative personnel to confirm that all users are assigned
a unique ID for access to system components or cardholder data.
C16.9 8.1.2 For a sample of privileged user IDs and general user IDs, examine
associated authorizations and observe system settings to verify each user ID
and privileged user ID has been implemented with only the privileges specified
on the documented approval.

C16.3 8.1.3.a Select a sample of users terminated in the past six months, and review
current user access lists—for both local and remote access—to verify that
their IDs have been deactivated or removed from the access lists.

8.1.3.b Verify all physical authentication methods—such as, smart cards, tokens, etc.
—have been returned or deactivated.

C16.5 8.1.4 Observe user accounts to verify that any inactive accounts over 90 days old are
either removed or disabled.

8.1.5.a Interview personnel and observe processes for managing accounts used by
vendors to access, support, or maintain system components to verify that accounts
used by vendors for remote access are:
􏰁 Disabled when not in use
􏰁 Enabled only when needed by the vendor, and disabled when not in use.
 8.1.5.b Interview personnel and observe processes to verify that vendor remote
access accounts are monitored while being used.

C16.8 8.1.6.a For a sample of system components, obtain and inspect system configuration
settings to verify that authentication parameters are set to require that a user’s
account be locked out after not more than six invalid logon attempts.

8.1.6.b Additional testing procedure for service providers: Review internal

processes and customer/user documentation, and observe implemented
processes to verify that non- consumer user accounts are temporarily locked-
out after not more than six invalid access attempts.

C16.8.1 8.1.7 For a sample of system components, obtain and inspect system configuration
settings to verify that password parameters are set to require that once a user account
is locked out, it remains locked for a minimum of 30 minutes or until a system
administrator resets the account.

C16.4 8.1.8 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.2 To verify that users are authenticated using unique ID and additional
authentication (for example, a password/phrase) for access to the cardholder data
environment, perform the following:
􏰁 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).

C12.5 8.2.1.a Examine vendor documentation and system configuration settings to

verify that passwords are protected with strong cryptography during
transmission and storage.

8.2.1.b For a sample of system components, examine password files to verify

that passwords are unreadable during storage.

8.2.1.c For a sample of system components, examine data transmissions to verify that
passwords are unreadable during transmission.

8.2.1.d Additional testing procedure for service providers: Observe password files to
verify that customer passwords are unreadable during storage.

8.2.1.e Additional testing procedure for service providers: Observe data transmissions
to verify that customer passwords are unreadable during transmission.
NC 8.2.2 Examine authentication procedures for modifying authentication
credentials and observe security personnel to verify that, if a user requests a
reset of an authentication credential by phone, e-mail, web, or other non-face-
to-face method, the user’s identity is verified before the authentication
credential is modified.

8.2.3a For a sample of system components, inspect system configuration settings to

verify that user password parameters are set to require at least the following
strength/complexity:
-Require a minimum length of at least seven characters.
-Contain both numeric and alphabetic characters.

8.2.3.b Additional testing procedure for service providers: Review internal processes
and customer/user documentation to verify that non-consumer user passwords are
required to meet at least the following strength/complexity:
-Require a minimum length of at least seven characters.
-Contain both numeric and alphabetic characters.
 C12.3 8.2.4.a For a sample of system components, obtain and inspect system
C16.7.2 configuration settings to verify that user password parameters are set to require
users to change passwords at least every 90 days.

8.2.4.b Additional testing procedure for service providers: Review internal

processes and customer/user documentation to verify that:

Non-consumer user passwords are required to change periodically; and

Non-consumer users are given guidance as to when, and under what circumstances,
passwords must change.

C12.8 8.2.5.a For a sample of system components, obtain and inspect system
C1.7.3 configuration settings to verify that password parameters are set to require that
new passwords cannot be the same as the four previously used passwords.

8.2.5.b Additional testing procedure for service providers: Review internal

processes and customer/user documentation to verify that new non-
consumer user passwords cannot be the same as the previous four
passwords.

NC 8.2.6 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.
C10.6 8.3.a Examine system configurations for remote access servers and systems to verify
C13.7 two-factor authentication is required for:
􏰁 All remote access by personnel
􏰁 All third-party/vendor remote access (including access to
applications and system components for support or maintenance purposes).

8.3.b Observe a sample of personnel (for example, users and administrators)

connecting remotely to the network and verify that at least two of the three
authentication methods are used.

8.4.a Examine procedures and interview personnel to verify that authentication

procedures and policies are distributed to all users.
8.4.b Review authentication procedures and policies that are distributed to users and
verify they include:
􏰁 Guidance on selecting strong authentication credentials
􏰁 Guidance for how users should protect their authentication
credentials.
􏰁 Instructions for users not to reuse previously used passwords
􏰁 Instructions to change passwords if there is any suspicion the
password could be compromised.

8.4.c Interview a sample of users to verify that they are familiar with authentication
procedures and policies.

8.5.a For a sample of system components, examine user ID lists to verify the following:
-Generic user IDs 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.b Examine authentication policies/procedures to verify that use of group and

shared IDs and/or passwords or other authentication methods are explicitly
prohibited.

8.5.c Interview system administrators to verify that group and shared IDs and/or
passwords or other authentication methods are not distributed, even if requested.
8.5.1 Additional testing procedure for service providers: Examine authentication
policies and procedures and interview personnel to verify that different authentication
are used for access to each customer.

8.6.a Examine authentication policies and procedures to verify that procedures for
using authentication mechanisms such as physical security tokens, smart cards, and
certificates are defined and include:
􏰁 Authentication mechanisms are assigned to an individual account and not shared
among multiple accounts.
􏰁 Physical and/or logical controls are defined to ensure only the intended account can
use that mechanism to gain access.

8.6.b Interview security personnel to verify authentication mechanisms are assigned

to an account and not shared among multiple accounts.

8.6.c Examine system configuration settings and/or physical controls, as applicable, to

verify that controls are implemented to ensure only the intended account can use that
mechanism to gain access.

8.7.a Review database and application configuration settings and verify that all users
are authenticated prior to access.
8.7.b Examine database and application configuration settings to verify 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.7.c Examine database access control settings and database application configuration
settings to verify that user direct access to or queries of databases are restricted to
database administrators.

8.7.d Examine database access control settings, database application configuration

settings, 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).

8.8 Examine documentation interview personnel to verify that security policies and
operational procedures for identification and authentication are:
-Documented,
-In use, and
-Known to all affected parties.
e, actions taken on critical data and systems are performed by, and can be traced to, known and authorized users.

Selected Merchant T

Validation Instructions for QSA/ISA Priority A

(For In-Place Requirements)

Identify the written procedures for user identification management 4 0

examined to verify processes are defined for each of the items below at
8.1.1 through 8.1.8:
 Assign all users a unique ID before allowing them to access system
components or cardholder data.
 Control addition, deletion, and modification of user IDs, credentials, and
other identifier objects.
 Immediately revoke access for any terminated users.
 Remove/disable inactive user accounts at least every 90 days.
 Manage IDs used by vendors to access, support, or maintain system
components via remote access as follows:
- Enabled only during the time period
needed and disabled when not in use.
- Monitored when in use.
 Limit repeated access attempts by locking out the user ID after not more
than six attempts.
 Set the lockout duration to a minimum of 30 minutes or until an
administrator enables the user ID.
 If a session has been idle for more than 15 minutes, require the user to re-
authenticate to re-activate the terminal or session.
<Report Findings Here>

Left empty by PCIco 4 0

Identify the responsible administrative personnel interviewed for this testing 4 0

procedure.
<Report Findings Here>

For the interview, summarize the relevant details discussed to confirm that all users
are assigned a unique ID for access to system components or cardholder data.
<Report Findings Here>
Identify the sample of privileged user IDs selected for this testing procedure. 4 0
<Report Findings Here>

Identify the sample of general user IDs selected for this testing procedure.
<Report Findings Here>

Describe how observed system settings and the associated authorizations

documented for the user IDs were compared to verify that each ID has been
implemented with only the privileges specified on the documented approval:

For the sample of privileged user IDs.

<Report Findings Here>

For the sample of general user IDs.

<Report Findings Here>

Identify the sample of users terminated in the past six months selected. 4 0
<Report Findings Here>

Describe how the current user access lists for local access were reviewed to verify
that the sampled user IDs have been deactivated or removed from the access lists.
<Report Findings Here>

Describe how the current user access lists for remote access were reviewed to verify
that the sampled user IDs have been deactivated or removed from the access lists.
<Report Findings Here>

For the sample of users terminated in the past six months at 8.1.3.a, describe how it 4 0
was determined which, if any, physical authentication methods, the terminated
users had access to prior to termination.
<Report Findings Here>

Describe how the physical authentication method(s) for the terminated employees
were verified to have been returned or deactivated.
<Report Findings Here>

Describe how user accounts were observed to verify that any inactive accounts over 4 0
90 days old are either removed or disabled.
<Report Findings Here>

Identify the personnel interviewed who confirm that accounts used by vendors for 4 0
remote access are:
 Disabled when not in use.
 Enabled only when needed by the vendor, and disabled when not in use.
<Report Findings Here>

Describe how processes for managing accounts used by vendors to access, support,
or maintain system components were observed to verify that accounts used by
vendors for remote access are:
Disabled when not in use.
Enabled only when needed by the vendor, and disabled when not in use.
<Report Findings Here>
Identify the personnel interviewed who confirm that accounts used by vendors for 4 0
remote access are monitored while being used.
<Report Findings Here>

Describe how processes for managing accounts used by vendors to access, support,
or maintain system components were observed to verify that vendor remote access
accounts are monitored while being used.
<Report Findings Here>

Identify the sample of system components selected for this testing procedure. 4 0
<Report Findings Here>
For each item in the sample, describe how system configuration settings were
inspected to verify that authentication parameters are set to require that user
accounts be locked after not more than six invalid logon attempts.
<Report Findings Here>

For service providers only, identify the documented internal processes and 4 0
customer/user documentation reviewed to verify that non-consumer user accounts
are temporarily locked-out after not more than six invalid access attempts.
<Report Findings Here>

Describe the implemented processes that were observed to verify that non-
consumer user accounts are temporarily locked-out after not more than six invalid
access attempts.
<Report Findings Here>

Identify the sample of system components selected for this testing procedure. 4 0
<Report Findings Here>
For each item in the sample, describe how system configuration settings were
inspected 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.
<Report Findings Here>

Identify the sample of system components selected for this testing procedure. 4 0
<Report Findings Here>

For each item in the sample, describe how system configuration settings were
inspected to verify that system/session idle time out features have been set to 15
minutes or less.
<Report Findings Here>
Identify the document describing the authentication method(s) used that was 4 0
reviewed to verify that the methods require users to be authenticated using a
unique ID and additional authentication for access to the cardholder data
environment.
<Report Findings Here>

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.
<Report Findings Here>

For each type of authentication method used and for each type of system
component, describe how the authentication method was observed to be:

Used for access to the cardholder data environment.

Functioning consistently with the documented authentication method(s).
<Report Findings Here>

Identify the vendor documentation reviewed for this testing procedure. 4 0

<Report Findings Here>

Identify the sample of system components selected.

<Report Findings Here>

For each item in the sample, describe how system configuration settings were
examined to verify that passwords are protected with strong cryptography during
transmission.
<Report Findings Here>

For each item in the sample, describe how system configuration settings were
examined to verify that passwords are protected with strong cryptography during
storage.
<Report Findings Here>

For each item in the sample at 8.2.1.a, describe how password files were examined 4 0
to verify that passwords are unreadable during storage.
<Report Findings Here>

For each item in the sample at 8.2.1.a, describe how password files were examined 4 0
to verify that passwords are unreadable during transmission.
<Report Findings Here>

Additional procedure for service providers: for each item in the sample at 8.2.1.a, 4 0
describe how password files were examined to verify that customer passwords are
unreadable during storage.
<Report Findings Here>

Additional procedure for service providers: for each item in the sample at 8.2.1.a, 4 0
describe how password files were examined to verify that customer passwords are
unreadable during transmission.
<Report Findings Here>
Identify the document examined to verify that authentication procedures for 4 0
modifying authentication credentials define that if a user requests a reset of an
authentication credential by a non-face-to-face method, the user’s identity is
verified before the authentication credential is modified.
<Report Findings Here>

Describe the non-face-to-face methods used for requesting password resets.

<Report Findings Here>

Describe how security personnel were observed to verify that if a user requests a
reset of an authentication credential by a non-face-to- face method, the user’s
identity is verified before the authentication credential is modified.
<Report Findings Here>

Identify the sample of system components selected for this testing procedure. 4 0
<Report Findings Here>

For each item in the sample, describe how system configuration settings were
inspected to verify that user password parameters are set to require at least the
following strength/complexity:

Require a minimum length of at least seven characters.

Contain both numeric and alphabetic characters.
<Report Findings Here>

For service providers only: Identify the documented internal processes and 4 0
customer/user documentation reviewed to verify that non-consumer user
passwords are required to meet at least the following strength/complexity:
 A minimum length of at least seven characters.
 Non-consumer user passwords are required to contain both numeric and
alphabetic characters.
<Report Findings Here>

Describe how internal processes were reviewed to verify that non-consumer user
passwords are required to meet at least the following strength/complexity:

A minimum length of at least seven characters.

Non-consumer user passwords are required to contain both numeric and alphabetic
characters
<Report Findings Here>.
Identify the sample of system components selected for this testing procedure. 4 0
<Report Findings Here>

For each item in the sample, describe how system configuration settings were
inspected to verify that user password parameters are set to require users to
change passwords at least every 90 days.
<Report Findings Here>

For service providers only, identify the documented internal processes and 4 0
customer/user documentation reviewed to verify that:
 Non-consumer user passwords are required to change periodically; and
 Non-consumer users are given guidance as to when, and under what
circumstances, passwords must change.
<Report Findings Here>

Describe how internal processes were reviewed to verify that:

Non-consumer user passwords are required to change periodically; and

Non-consumer users are given guidance as to when, and under what circumstances,
passwords must change.
<Report Findings Here>

Identify the sample of system components selected for this testing procedure. 4 0
<Report Findings Here>

For each item in the sample, describe how system configuration settings were
inspected to verify that password parameters are set to require that new passwords
cannot be the same as the four previously used passwords.
<Report Findings Here>

For service providers only, identify the documented internal processes and 4 0
customer/user documentation reviewed to verify that new non-consumer user
passwords cannot be the same as the previous four passwords.
<Report Findings Here>

Describe how internal processes were reviewed to verify that new non-consumer
user passwords cannot be the same as the previous four passwords.
<Report Findings Here>

Identify the documented password procedures examined to verify the procedures 4 0

define that:
 First-time passwords must be set to a unique value for each user.
 First-time passwords must be changed after the first use.
 Reset passwords must be set to a unique value for each user.
 Reset passwords must be changed after the first use.
<Report Findings Here>

Describe how security personnel were observed to:

Set first-time passwords to a unique value for each new user.

Set first-time passwords to be changed after first use.
<Report Findings Here>
Describe how system configurations for remote access servers and systems were 4 0
examined to verify two-factor authentication is required for:

All remote access by personnel.

All third-party/vendor remote access (including access to applications and system
components for support or maintenance purposes).
<Report Findings Here>

Identify the sample of personnel observed connecting remotely to the network 4 0

selected.
<Report Findings Here>

For each item in the sample, describe how two- factor authentication was observed
to be required for remote access to the network.
<Report Findings Here>

Identify which two factors are used:

 Something you know
 Something you are
 Something you have
<Report Findings Here>

Identify the documented procedures examined to verify authentication procedures 4 0

define that authentication procedures and policies are distributed to all users.
<Report Findings Here>

Identify the personnel interviewed who confirm that authentication procedures and
policies are distributed to all users.
<Report Findings Here>
Identify the documented authentication procedures and policies that are 4 0
distributed to users reviewed to verify they include:
 Guidance on selecting strong authentication credentials.
 Guidance for how users should protect their authentication credentials.
 Instructions for users not to reuse previously used passwords.
 That users should change passwords if there is any suspicion the password could
be compromised.
<Report Findings Here>

Identify the sample of users interviewed for this testing procedure. 4 0

<Report Findings Here>

For the interview, summarize the relevant details discussed that verify that the
sampled users are familiar with authentication procedures and policies.
<Report Findings Here>

Identify the sample of system components selected for this testing procedure. 4 0
<Report Findings Here>

For each item in the sample, describe how user ID lists for the sample of system
components were examined to verify that:

Generic user IDs 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.
<Report Findings Here>

Identify the documented policies/procedures examined to verify authentication 4 0

policies/procedures define that use of group and shared IDs and/or passwords or
other authentication methods are explicitly prohibited.
<Report Findings Here>

Identify the system administrators interviewed who confirm that group and shared 4 0
IDs and/or passwords or other authentication methods are not distributed, even if
requested.
For service providers only, indicate whether this ROC is being completed prior to 4 0
June 30, 2015. (yes/no)
<Report Findings Here>

If “yes” AND the assessed entity does not have this in place ahead of the
requirement’s effective date, mark this as “Not Applicable.”
If “no” OR if the assessed entity has this in place ahead of the requirement’s
effective date, complete the following:

Identify the documented procedures examined to verify that different

authentication is used for access to each customer.
<Report Findings Here>

Identify the personnel interviewed for this testing procedure.

<Report Findings Here>

For the interview, summarize the relevant details discussed to confirm that
different authentication is used for access to each customer.
<Report Findings Here>

Identify the documented authentication policies and procedures examined to verify 4 0

the procedures for using authentication mechanisms define that:
 Authentication mechanisms are assigned to an individual account and not shared
among multiple accounts.
 Physical and/or logical controls are defined to ensure only the intended account
can use that mechanism to gain access.
<Report Findings Here>

Identify the security personnel interviewed who confirm that authentication 4 0

mechanisms are assigned to an account and not shared among multiple accounts.
<Report Findings Here>

Identify the sample of system components selected for this testing procedure. 4 0
<Report Findings Here>
For each item in the sample, describe how system configuration settings and/or
physical controls, as applicable, were examined to verify that controls are
implemented to ensure only the intended account can use that mechanism to gain
access.
<Report Findings Here>

Identify all databases containing cardholder data. 4 0

<Report Findings Here>
Describe how authentication is managed (for example, via application and/or
database interfaces).
<Report Findings Here>

Describe how database and/or application configuration settings were observed to

verify that all users are authenticated prior to access.
<Report Findings Here>
For each database from 8.7.a: 4 0
Describe how the database and application configuration settings were examined to
verify that only programmatic methods are used for:

All user access to the database

All use queries of the database
All user actions on the database
<Report Findings Here>

Describe the process observed to verify that only programmatic methods are used
for:

All user access to the database

All use queries of the database
All user actions on the database
<Report Findings Here>

For each database from 8.7.a, describe how database application configuration 4 0
settings were examined to verify that the following are restricted to only database
administrators:

User direct access to databases

Queries of databases
<Report Findings Here>

For each database from 8.7.a: 4 0

Identify applications with access to the database.
<Report Findings Here>

Describe the implemented methods for ensuring that application IDs can only be
used by the applications.
<Report Findings Here>

Describe how database access control settings, database application configuration

settings and related application IDs were examined together to verify that
application IDs can only be used by the applications.
<Report Findings Here>

Identify the document reviewed to verify that security policies and operational 0
procedures for identification and authentication are documented.
<Report Findings Here>

Identify responsible personnel interviewed who confirm that the above

documented security policies and operational procedures for identification and
authentication are: 6
 In use
 Known to all affected parties.
<Report Findings Here>

170 0
uthorized users.

ected Merchant Type: D

A-EP PE2P B B-IP C-VT C D S In Place? Severity

0 0 0 0 0 0 1 1

N 3

0 0 0 0 0 0 1 1

N 3

1 0 0 0 0 0 1 1

N 3
0 0 0 0 0 0 1 1

N 3

1 0 0 0 0 0 1 1

N 3

1 0 0 0 0 0 1 1

Y 0

0 0 0 0 0 0 1 1
Y 0

1 0 0 1 0 1 1 1

N 3
1 0 0 1 0 1 1 1

N 3

1 0 0 0 0 0 1 1

N 3

0 0 0 0 0 0 0 1

N 0

1 0 0 0 0 0 1 1

N 3

0 0 0 0 0 0 1 1

N 3
1 0 0 0 0 0 1 1

N 3

1 0 0 0 0 0 1 1

N 3

0 0 0 0 0 0 1 1
N 3

0 0 0 0 0 0 1 1
N 3

0 0 0 0 0 0 0 1

N 0

0 0 0 0 0 0 0 1

N 0
0 0 0 0 0 0 1 1

N 3

1 0 0 0 0 0 1 1

N 3

0 0 0 0 0 0 0 1

N 0
1 0 0 0 0 0 1 1

N 3

0 0 0 0 0 0 0 1

N 0

1 0 0 0 0 0 1 1

N 3

0 0 0 0 0 0 0 1

N 0

1 0 0 0 0 0 1 1

N 3
1 0 0 1 0 1 1 1

N 3

1 0 0 1 0 1 1 1

N 3

0 0 0 0 0 0 1 1

N 3
0 0 0 0 0 0 1 1

N 3

0 0 0 0 0 0 1 1

N 3

1 0 0 1 0 0 1 1

N 3

1 0 0 1 0 0 1 1

N 3

1 0 0 1 0 0 1 1
N 3
0 0 0 0 0 0 0 1

N 0

1 0 0 0 0 0 1 1

N 3

1 0 0 0 0 0 1 1
N 3

1 0 0 0 0 0 1 1

N 3

0 0 0 0 0 0 1 1

N 3
0 0 0 0 0 0 1 1

N 3

0 0 0 0 0 0 1 1

N 3

0 0 0 0 0 0 1 1

N 3

0 0 0 0 0 0 1 1

N 1

21 0 0 7 0 4 37 44 Y 97
N
C
NT
NA
 Proofs / Stage of implementation Remediation plan
Documentation links
Estimated date for completion Comments Owner
Return to Table of content Go to requriement 8
Requirement 9: Restrict physical access to cardholder data
Any physical access to data or systems that house cardholder data provides the opportunity for individuals to ac
workers, or anyone who needs to enter the facility for a short duration, usually not more than one day. “Media”
Major Obser
Five of Requirement 9’s subcontrols (9.1.3, 9.1.2, 9.3.3, 9.3.1 and 9.3.2.b) make it into our “Top 20.” These refer to restricting phy
achieve between 86.1% and 91.1% compliance,
Just 66.3% of organizations were compliant with 9.9.1 [Properly maintain inventory logs of all media and conduct media invento
organizations that do maint
But surprisingly, 74.3% of organizations were comp

PCI DSS Requirement Guidance

9.1 Use appropriate facility entry controls to limit Without physical access controls, unauthorized
and monitor physical access to systems in the persons could potentially gain access to the building
cardholder data environment. and to sensitive information, and could alter system
configurations, introduce vulnerabilities into the
network, or destroy or steal equipment.

9.1.1 Use video cameras and/or access control When investigating physical breaches, these
mechanisms to monitor individual physical access to controls can help identify individuals that physically
sensitive areas. Review collected data and correlate access those sensitive areas storing cardholder data.
with other entries. Store for at least three months, Examples of sensitive areas include corporate
unless otherwise restricted by law. database server rooms, back-end server room of a
retail location that stores cardholder data, and
Note: “Sensitive areas” refers to any data center, storage areas for large quantities of cardholder
server room or any area that houses systems that data,
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.
server room or any area that houses systems that data,
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 Implement physical and/or logical controls to Restricting access to network jacks will prevent
restrict access to publicly accessible network jacks. 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.

9.1.3 Restrict physical access to wireless access Without security over access to wireless
points, gateways, handheld devices, components and devices, malicious users could use
networking/communications hardware, and your organization’s unattended wireless devices to
telecommunication lines. access your network resources, or even connect
their own devices to your wireless network to gain
unauthorized access. Additionally, securing
networking and communications hardware prevents
malicious users from intercepting network traffic or
physically connecting their own devices to your
wired network resources.

Consider placing wireless access points, gateways

and networking/ communications hardware in
secure storage areas, such as within locked closets
or server rooms. For wireless networks, ensure
strong encryption is enabled. Also consider enabling
automatic device lockout on wireless handheld
devices after a long idle period, and set your devices
to require a password when powering on.

9.2 Develop procedures to easily distinguish Without badge systems and door controls,
between onsite personnel and visitors, especially in unauthorized and malicious users can easily gain
areas where cardholder data is accessible. access to your facility to steal, disable, disrupt, or
destroy critical systems and cardholder data. For
optimum control, consider implementing badge or
card access system in and out of work areas that
contain cardholder data.
Identifying authorized visitors so they are easily
distinguished from onsite personnel prevents
unauthorized visitors from being granted access to
areas containing cardholder data.
 unauthorized visitors from being granted access to
areas containing cardholder data.

9.3 Control physical access for onsite personnel toControlling physical access to the CDE helps ensure
the sensitive areas as follows: that only authorized personnel with a legitimate
business need are granted access.
-Access must be authorized and based on individual When personnel leave the organization, all physical
job function. access mechanisms should be returned or disabled
-Access is revoked immediately upon termination, promptly (as soon as possible) upon their
and all physical access mechanisms, such as keys, departure, to ensure personnel cannot gain physical
access cards, etc., are returned or disabled. access to the CDE once their employment has
ended.

9.4 Implement procedures to identify and authorize Visitor controls are important to reduce the ability
visitors. Procedures should include the following: of unauthorized and malicious persons to gain
access to facilities (and potentially, to cardholder
data).
Visitor controls ensure visitors are identifiable as
visitors so personnel can monitor their activities,
and that their access is restricted to just the
duration of their legitimate visit.

Ensuring that visitor badges are returned upon

expiry or completion of the visit prevents malicious
persons from using a previously authorized pass to
gain physical access into the building after the visit
has ended.
A visitor log documenting minimum information on
the visitor is easy and inexpensive to maintain and
will assist in identifying physical access to a building
or room, and potential access to cardholder data.
 Visitor controls are important to reduce the ability
of unauthorized and malicious persons to gain
access to facilities (and potentially, to cardholder
data).
9.4.1 Visitors are authorized before entering, and Visitor controls ensure visitors are identifiable as
escorted at all times within, areas where cardholder visitors so personnel can monitor their activities,
data is processed or maintained. and that their access is restricted to just the
duration of their legitimate visit.

Ensuring that visitor badges are returned upon

expiry or completion of the visit prevents malicious
persons from using a previously authorized pass to
gain physical access into the building after the visit
has ended.
A visitor log documenting minimum information on
the visitor is easy and inexpensive to maintain and
will assist in identifying physical access to a building
or room, and potential access to cardholder data.

9.4.2 Visitors are identified and given a badge or

other identification that expires and that visibly
distinguishes the visitors from onsite personnel.

9.4.3 Visitors are asked to surrender the badge or

identification before leaving the facility or at the
date of expiration.

9.4.4 A visitor log is used to maintain a physical

audit trail of visitor activity to the facility as well as
computer rooms and data centers where cardholder
data is stored or transmitted.
Document the visitor’s 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 Physically secure all media. Controls for physically securing media are intended
to prevent unauthorized persons from gaining
access to cardholder data on any type of media.
Cardholder data is susceptible to unauthorized
viewing, copying, or scanning if it is unprotected
while it is on removable or portable media, printed
out, or left on someone’s desk.

9.5.1 Store media backups in a secure location,

preferably an off-site facility, such as an alternate or
backup site, or a commercial storage facility. Review
the location’s security at least annually.

9.6 Maintain strict control over the internal or Procedures and processes help protect cardholder
external distribution of any kind of media, including data on media distributed to internal and/or
the following: external users. Without such procedures data can
be lost or stolen and used for fraudulent purposes.

9.6.1 Classify media so the sensitivity of the data It is important that media be identified such that its
can be determined. classification status can be easily discernable. Media
not identified as confidential may not be adequately
protected or may be lost or stolen

9.6.2 Send the media by secured courier or other Media may be lost or stolen if sent via a non-
delivery method that can be accurately tracked. trackable method such as regular postal mail. Use
the services of a secure courier to deliver any media
that contains cardholder data, so that you can use
their tracking systems to maintain inventory and
location of shipments.
9.6.3 Ensure management approves any and all Without a firm process for ensuring that all media
media that is moved from a secured area (including movements are approved before the media is
when media is distributed to individuals). removed from secure areas, the media would not
be tracked or appropriately protected, and its
location would be unknown, leading to lost or
stolen media.

9.7 Maintain strict control over the storage and Without careful inventory methods and storage
accessibility of media. controls, stolen or missing media could go
unnoticed for an indefinite amount of time.

9.7.1 Properly maintain inventory logs of all media If media is not inventoried, stolen or lost media may
and conduct media inventories at least annually. not be noticed for a long time or at all.

9.8 Destroy media when it is no longer needed for If steps are not taken to destroy information
business or legal reasons as follows: contained on hard disks, portable drives, CD/DVDs,
or paper prior to disposal, malicious individuals may
be able to retrieve information from the disposed
media, leading to a data compromise. For example,
malicious individuals may use a technique known as
“dumpster diving,” where they search through trash
cans and recycle bins looking for information they
can use to launch an attack.
Examples of methods for securely destroying
electronic media include secure wiping, degaussing,
or physical destruction (such as grinding or
shredding hard disks).
 or physical destruction (such as grinding or
shredding hard disks).

9.8.1 Shred, incinerate, or pulp hardcopy materials

so that cardholder data cannot be reconstructed.

9.8.2 Render cardholder data on electronic media

unrecoverable so that cardholder data cannot be
reconstructed.

9.9 Protect devices that capture payment card data Criminals attempt to steal cardholder data by
via direct physical interaction with the card from stealing and/or manipulating card-reading devices
tampering and substitution. and terminals. For example, they will try to steal
devices so they can learn how to break into them,
and they often try to replace legitimate devices with
fraudulent devices that send them payment card
information every time a card is entered. Criminals
will also try to add “skimming” components to the
outside of devices, which are designed to capture
payment card details before they even enter the
device—for example, by attaching an additional
card reader on top of the legitimate card reader so
that the payment card details are captured twice:
once by the criminal’s component and then by the
device’s legitimate component. In this way,
transactions may still be completed without
interruption while the criminal is “skimming” the
payment card information during the process.
This requirement is recommended, but not
required, for manual key-entry components such as
computer keyboards and POS keypads.
Additional best practices on skimming prevention
are available on the PCI SSC website.
9.9.1 Maintain an up-to-date list of devices. The list Keeping an up-to-date list of devices helps an
should include the following: organization keep track of where devices are
supposed to be, and quickly identify if a device is
-Make, model of device missing or lost.
-Location of device (for example, the address of the The method for maintaining a list of devices may be
site or facility where the device is located) automated (for example, a device-management
-Device serial number or other method of unique system) or manual (for example, documented in
identification. electronic or paper records). For on-the-road
devices, the location may include the name of the
personnel to whom the device is assigned.

9.9.2 Periodically inspect device surfaces to detect Regular inspections of devices will help
tampering (for example, addition of card skimmers organizations to more quickly detect tampering or
to devices), or substitution (for example, by replacement of a device, and thereby minimize the
checking the serial number or other device potential impact of using fraudulent devices.
characteristics to verify it has not been swapped The type of inspection will depend on the device—
with a fraudulent device). for example, photographs of devices that are known
to be secure can be used to compare a device’s
current appearance with its original appearance to
see whether it has changed. Another option may be
to use a secure marker pen, such as a UV light
marker, to mark device surfaces and device
openings so any tampering or replacement will be
apparent. Criminals will often replace the outer
casing of a device to hide their tampering, and these
methods may help to detect such activities. Device
vendors may also be able to provide security
guidance and “how to” guides to help determine
whether the device has been tampered with.
The frequency of inspections will depend on factors
such as location of device and whether the device is
attended or unattended. For example, devices left in
public areas without supervision by the
organization’s personnel may have more frequent
inspections than devices that are kept in secure
areas or are supervised when they are accessible to
the public. The type and frequency of inspections is
determined by the merchant, as defined by their
annual risk-assessment process.
 marker, to mark device surfaces and device
openings so any tampering or replacement will be
apparent. Criminals will often replace the outer
casing of a device to hide their tampering, and these
methods may help to detect such activities. Device
vendors may also be able to provide security
guidance and “how to” guides to help determine
whether the device has been tampered with.
The frequency of inspections will depend on factors
such as location of device and whether the device is
attended or unattended. For example, devices left in
public areas without supervision by the
organization’s personnel may have more frequent
inspections than devices that are kept in secure
areas or are supervised when they are accessible to
the public. The type and frequency of inspections is
determined by the merchant, as defined by their
annual risk-assessment process.

9.9.3 Provide training for personnel to be aware of Criminals will often pose as authorized maintenance
attempted tampering or replacement of devices. personnel in order to gain access to POS devices. All
Training should include the following: third parties requesting access to devices should
􏰀 Verify the identity of any third-party persons always be verified before being provided access—
claiming to be repair or maintenance personnel, for example, by checking with management or
prior to granting them access to modify or phoning the POS maintenance company (such as
troubleshoot devices. the vendor or acquirer) for verification. Many
􏰀 Do not install, replace, or return devices without criminals will try to fool personnel by dressing for
verification. the part (for example, carrying toolboxes and
dressed in work wear), and could also be
􏰀 Be aware of suspicious behavior around devices knowledgeable about locations of devices, so it’s
(for example, attempts by unknown persons to important personnel are trained to follow
unplug or open devices). procedures at all times.
􏰀 Report suspicious behavior and indications of Another trick criminals like to use is to send a “new”
device tampering or substitution to appropriate POS system with instructions for swapping it with a
personnel (for example, to a manager or security legitimate system and “returning” the legitimate
officer). system to a specified address. The criminals may
even provide return postage as they are very keen
to get their hands on these devices. Personnel
always verify with their manager or supplier that
the device is legitimate and came from a trusted
source before installing it or using it for business.
 to get their hands on these devices. Personnel
always verify with their manager or supplier that
the device is legitimate and came from a trusted
source before installing it or using it for business.

9.10 Ensure that security policies and operational Personnel need to be aware of and following
procedures for restricting physical access to security policies and operational procedures for
cardholder data are documented, in use, and known restricting physical access to cardholder data
to all affected parties. and CDE systems on a continuous basis.
 Go to requriement 10Executive Summary

e opportunity for individuals to access devices or data and to remove systems or hardcopies, and should be appropriately re
not more than one day. “Media”
Major refers from
Observations to allthe
paper
2014 and electronic
Verizon media
Compliance containing cardholder data
Report:
“Top 20.” These refer to restricting physical access to network hardware, and making sure all visitors are authorized (with specific controls before e
between 86.1% and 91.1% compliance, showing that organizations are generally pretty strong on controlling physical access.
of all media and conduct media inventories at least annually]. This low level of compliance could be because organizations see logging as a resourc
organizations that do maintain logs may forget about backups or USB devices containing CHD.
ingly, 74.3% of organizations were compliant with 9.8 [Destroy media when it is no longer needed for business or legal reasons].

SANS Testing Procedure

Top 20 Critical
Security Controls
NC Verify the existence of physical security controls for each computer room, data center,
and other physical areas with systems in the cardholder data environment.
- Verify that access is controlled with badge readers or other devices including
authorized badges and lock and key.
- Observe a system administrator’s attempt to log into consoles for randomly selected
systems in the cardholder environment and verify that they are “locked” to prevent
unauthorized use.

NC 9.1.1.a Verify that video cameras and/or access control mechanisms are in place to
monitor the entry/exit points to sensitive areas.

9.1.1.b Verify that video cameras and/or access control mechanisms are protected
from tampering or disabling.
 9.1.1.c Verify that video cameras and/or access control mechanisms are monitored
and that data from cameras or other mechanisms is stored for at least three months.

NC 9.1.2 Interview responsible personnel and observe locations of publicly accessible

network jacks to verify that physical and/or logical controls are in place to restrict
access to publicly accessible network jacks.

NC 9.1.3 Verify that physical access to wireless access points, gateways, handheld devices,
networking/communications hardware, and telecommunication lines is appropriately
restricted.

NC 9.2.a Review processes and procedures for assigning badges to onsite personnel and
visitors, and verify these processes include the following:

- Granting new badges,

- Changing access requirements, and
- Revoking terminated onsite personnel and expired visitor badges
 9.2.b Verify that access to the badge system is limited to authorized personnel.

9.2.c Examine badges in use to verify that they clearly identify visitors and it is easy to
distinguish between onsite personnel and visitors.

9.2.d Examine identification methods (such as ID badges) in use to verify that they
clearly identify visitors and it is easy to distinguish between onsite personnel and
visitors.

NC 9.3.a For a sample of onsite personnel with physical access to the CDE, interview
responsible personnel and observe access control lists to verify that:
-Access to the CDE is authorized.
-Access is required for the individual’s job function.

9.3.b Observe personnel access the CDE to verify that all personnel are authorized
before being granted access.


9.3.c Select a sample of recently terminated employees and review access control lists
to verify the personnel do not have physical access to the CDE.

NC 9.4 Verify that visitor authorization and access controls are in place as follows:
 9.4.1.a Observe procedures and interview personnel to verify that visitors must be
authorized before they are granted access to, and escorted at all times within, areas
where cardholder data is processed or maintained.

NC

9.4.1.b Observe the use of visitor badges or other identification to verify that a
physical token badge does not permit unescorted access to physical areas where
cardholder data is processed or maintained.

9.4.2.a Observe people within the facility to verify the use of visitor badges or other
identification, and that visitors are easily distinguishable from onsite personnel.

NC

9.4.2.b Verify that visitor badges or other identification expire.

9.4.3 Observe visitors leaving the facility to verify visitors are asked to surrender their
badge or other identification upon departure or expiration.
NC

9.4.4.a Verify that a visitor log is in use to record physical access to the facility as well
as computer rooms and data centers where cardholder data is stored or transmitted.

9.4.4.b Verify that the log contains:

-The visitor’s name,
- The firm represented, and
- The onsite personnel authorizing physical access.
NC

9.4.4.c Verify that the log is retained for at least three months.
C8.4 9.5 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.5.1.a Observe the storage location’s physical security to confirm that backup media
storage is secure.

9.5.1.b Verify that the storage location security is reviewed at least annually.

9.6 Verify that a policy exists to control distribution of media, and that the policy
covers all distributed media including that distributed to individuals.

C8.4 9.6.1 Verify that all media is classified so the sensitivity of the data can be determined.

NC 9.6.2.a Interview personnel and examine records to verify that all media sent
outside the facility is logged and sent via secured courier or other delivery
method that can be tracked.
 9.6.2.b Select a recent sample of several days of offsite tracking logs for all media, and
verify tracking details are documented.

9.6.3 Select a recent sample of several days of offsite tracking logs for all media. From
examination of the logs and interviews with responsible personnel, verify proper
management authorization is obtained whenever media is moved from a secured area
(including when media is distributed to individuals).

NC 9.7 Verify that all media sent outside the facility is logged and authorized by
management and sent via secured courier or other delivery method that can be
tracked.

NC 9.7.1 Select a recent sample of several days of offsite tracking logs for all media, and
verify the presence in the logs of tracking details and proper management
authorization.

NC 9.8 Examine the periodic media destruction policy and verify that it covers all media
and defines requirements for the following:
-Hard-copy materials must be crosscut shredded, incinerated, or pulped such that
there is reasonable assurance the hard- copy materials cannot be reconstructed.
-Storage containers used for materials that are to be destroyed must be secured.
-Cardholder data on electronic media must be rendered unrecoverable via a secure
wipe program (in accordance with industry-accepted standards for secure deletion),
or by physically destroying the media.
NC 9.8.1.a Interview personnel and examine procedures to verify that hard-copy
materials are crosscut shredded, incinerated, or pulped such that there is reasonable
assurance the hard-copy materials cannot be reconstructed.

NC 9.8.1.b Examine storage containers used for materials that contain

information to be destroyed to verify that the containers are secured.

NC 9.8.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).

9.9 Examine documented policies and procedures to verify they include:

-Maintaining a list of devices
-Periodically inspecting devices to look for tampering or substitution
- Training personnel to be aware of suspicious behavior and to report tampering or
substitution of devices
9.9.1.a Examine the list of devices to verify it includes:
-Make, model of device
-Location of device (for example, the address of the site or facility where the device is
located)
-Device serial number or other method of unique identification.

9.9.1.b Select a sample of devices from the list and observe device locations to verify
that the list is accurate and up to date.

9.9.1.c Interview personnel to verify the list of devices is updated when devices are
added, relocated, decommissioned, etc.

9.9.2.a Examine documented procedures to verify processes are defined to include

the following:
-Procedures for inspecting devices
-Frequency of inspections.
9.9.2.b Interview responsible personnel and observe inspection processes to verify:
-Personnel are aware of procedures for inspecting devices.
-All devices are periodically inspected for evidence of tampering and substitution.

9.9.3.a Review training materials for personnel at point-of-sale locations to verify they
include training in the following:
-Verifying the identity of any third-party persons claiming to be repair or maintenance
personnel, prior to granting them access to modify or troubleshoot devices
-Not to install, replace, or return devices without verification
-Being aware of suspicious behavior around devices (for example, attempts by
unknown persons to unplug or open devices)
-Reporting suspicious behavior and indications of device tampering or substitution to
appropriate personnel (for example, to a manager or security officer).
9.9.3.b Interview a sample of personnel at point-of-sale locations to verify they have
received training and are aware of the procedures for the following:
-Verifying the identity of any third-party persons claiming to be repair or maintenance
personnel, prior to granting them access to modify or troubleshoot devices
-Not to install, replace, or return devices without verification
-Being aware of suspicious behavior around devices (for example, attempts by
unknown persons to unplug or open devices)
-Reporting suspicious behavior and indications of device tampering or substitution to
appropriate personnel (for example, to a manager or security officer).

9.10 Examine documentation and interview personnel to verify that security policies
and operational procedures for restricting physical access to cardholder data are:
-Documented,
-In use, and
-Known to all affected parties.
nd should be appropriately restricted. For the purposes of Requirement 9, “onsite personnel” refers to full-time and part-ti
er data
ized (with specific controls before entering areas where CHD is processed or maintained). These
hysical access.
ganizations see logging as a resource-intensive task that adds little value — we disagree — and
or legal reasons].
Selected Merchant Ty

Validation Instructions for QSA/ISA Priority A

(For In-Place Requirements)

Identify and briefly describe all of the following with systems in the cardholder data 0
environment:
All computer rooms
All data centers
Any other physical areas
<Report Findings Here>

For each area identified (add rows as needed), complete the following:

Describe the physical security controls to be in place, including authorized badges

and lock and key.
<Report Findings Here>

Identify the randomly selected systems in the cardholder environment for which a
system administrator login attempt was observed. 2
<Report Findings Here>

Describe how consoles for the randomly selected systems were observed to verify
that they are “locked” when not in use to prevent unauthorized use.
<Report Findings Here>

Describe the video cameras and/or access control mechanisms observed to monitor 0
the entry/exit points to sensitive areas.
<Report Findings Here>
2

Describe how the video cameras and/or access control mechanisms were observed 0
to be protected from tampering and/or disabling.
<Report Findings Here> 2
Describe how the video cameras and/or access control mechanisms were observed 0
to be monitored.
<Report Findings Here>

Describe how data from the cameras and/or access control mechanisms was
observed to be stored for at least three months. 2
<Report Findings Here>

Identify responsible personnel interviewed who confirm that physical and/or logical 0
controls are in place to restrict access to publicly accessible network jacks.
<Report Findings Here>

Describe the physical and/or logical controls observed at the locations of publicly
accessible network jacks to verify the controls are in place restrict access.
<Report Findings Here> 2

Describe how physical access was observed to be restricted to the following: 0

Wireless access points
Wireless gateways
Wireless handheld devices
Network/communications hardware
Telecommunication lines
<Report Findings Here>

Identify the documented processes reviewed to verify that procedures are defined 5 0
for identifying and distinguishing between onsite personnel and visitors, including
the following:
 Identifying new onsite personnel or visitors (for example, assigning badges),
 Changing access requirements, and
 Revoking terminated onsite personnel and expired visitor identification (such as
ID badges).
<Report Findings Here>
Describe how processes for identifying and distinguishing between onsite personnel 5 0
and visitors were observed to verify that:
Visitors are clearly identified, and
It is easy to distinguish between onsite personnel and visitors.
<Report Findings Here>

Identify the document that defines that access to the identification process is 5 0
limited to authorized personnel.
<Report Findings Here>

Describe how access to the identification process was observed to be limited to

authorized personnel.
<Report Findings Here>

Briefly describe the identification method in use for onsite personnel and visitors. 5 0
<Report Findings Here>
Describe how the identification methods were examined to verify that:
The identification method(s) clearly identify visitors.
It is easy to distinguish between onsite personnel and visitors.
<Report Findings Here>

Identify the sample of onsite personnel with physical access to the CDE interviewed 5 0
for this testing procedure.
<Report Findings Here>

For all items in the sample, describe how responsible personnel were interviewed
and access control lists observed to verify that:
Access to the CDE is authorized.
Access is required for the individual’s job function.
<Report Findings Here>

Describe how personnel accessing the CDE were observed to verify that all 5 0
personnel are authorized before being granted access.
<Report Findings Here>

Identify the sample of users recently terminated. 5 0

<Report Findings Here>

For all items in the sample, provide the name of the assessor who attests that the
access control lists were reviewed to verify the personnel do not have physical
access to the CDE.
<Report Findings Here>

Not Provided by PCIco 5 0

Describe how visitor authorization processes were observed to verify that visitors: 5 0
 Must be authorized before they are granted access to areas where cardholder
data is processed or maintained.
 Are escorted at all times within areas where cardholder data is processed and
maintained.
<Report Findings Here>
Identify personnel interviewed who confirm that visitor authorization processes are
in place so that visitors must be authorized before they are granted access to, and
escorted at all times within, areas where cardholder data is processed or
maintained.
<Report Findings Here>

Describe how the use of visitor badges or other identification was observed to 5 0
verify that a physical token badge does not permit unescorted access to physical
areas where cardholder data is processed or maintained.
<Report Findings Here>

Describe how people within the facility were observed to use visitor badges or 5 0
other identification.
<Report Findings Here>

Describe how visitors within the facility were observed to be easily distinguishable
from onsite personnel.
<Report Findings Here>

Describe how visitor badges or other identification were verified to expire 5 0

<Report Findings Here>

Describe how visitors leaving the facility were observed to verify they are asked to 5 0
surrender their badge or other identification upon departure or expiration.
<Report Findings Here>

Describe how it was verified that a visitor log is in use to record physical access to: 5 0
The facility.
Computer rooms and data centers where cardholder data is stored or transmitted.
<Report Findings Here>

Provide the name of the assessor who attests that the visitor log contains: 5 0
 The visitor’s name,
 The firm represented, and
 The onsite personnel authorizing physical access.
<Report Findings Here>

Identify the defined retention period for visitor logs. 5 0

<Report Findings Here>
Describe how visitor logs were observed to be retained for at least three months.
<Report Findings Here>
Identify the documented procedures for protecting cardholder data reviewed to 5 1
verify controls for physically securing all media are defined.
<Report Findings Here>

For all types of media used, describe the controls for physically securing the media
used.
<Report Findings Here>

Identify all locations where backup media is stored. 5 0

<Report Findings Here>
Describe how it was observed that backup media storage is stored in a secure
location.
<Report Findings Here>

Identify the document reviewed to verify that the storage location must be 5 0
reviewed at least annually.
<Report Findings Here>

Describe how processes were observed to verify that reviews of the security of each
storage location are performed at least annually.
<Report Findings Here>

Identify the documented policy to control distribution of media that was reviewed 5 1
to verify the policy covers all distributed media, including that distributed to
individuals.
<Report Findings Here>

Describe how media distribution is controlled, including distribution to individuals.

<Report Findings Here>

Identify the documented policy reviewed to verify policy defines how media is 5 1
classified.
<Report Findings Here>

Describe how the classifications were observed to be implemented so the sensitivity

of the data can be determined.
<Report Findings Here>

Identify the personnel interviewed who confirm that all media sent outside the 5 1
facility is logged and sent via secured courier or other delivery method that can be
tracked.
<Report Findings Here>

Identify the record examined for this testing procedure.

<Report Findings Here>

Describe how offsite tracking records were examined to verify that all media is
logged and sent via secured courier or other delivery method that can be tracked.
<Report Findings Here>
Identify the sample of recent offsite tracking logs for all media selected. 5 1
<Report Findings Here>

For each item in the sample, describe how the offsite tracking logs were reviewed
to verify that tracking details are documented.
<Report Findings Here>

Identify responsible personnel interviewed who confirm that proper management 5 1

authorization is obtained whenever media is moved from a secured area (including
when media is distributed to individuals).
<Report Findings Here>

For each item in the sample in 9.6.2.b, describe how offsite tracking logs were
examined to verify proper management authorization is obtained whenever media
is moved from a secured area (including when media is distributed to individuals).
<Report Findings Here>

Identify the documented policy for controlling storage and maintenance of all 5 1
media that was reviewed to verify that the policy defines required periodic media
inventories.
<Report Findings Here>

Identify the media inventories logs reviewed. 5 1

<Report Findings Here>

Describe how the media inventory logs were reviewed to verify that:
<Report Findings Here>

Media inventory logs of all media were observed to be maintained.

Media inventories are performed at least annually.
<Report Findings Here>

Identify the policy document for periodic media destruction that was examined to 5 1
verify it covers all media and defines requirements for the following:
Hard-copy materials must be crosscut shredded, incinerated, or pulped such that
there is reasonable assurance the hard- copy materials cannot be reconstructed.
Storage containers used for materials that are to be destroyed must be secured.
Cardholder data on electronic media must be rendered unrecoverable via a secure
wipe program (in accordance with industry- accepted standards for secure
deletion), or by physically destroying the media.
<Report Findings Here>
IIdentify personnel interviewed who confirm that hard-copy materials are crosscut 5 1
shredded, incinerated, or pulped such that there is reasonable assurance the hard-
copy materials cannot be reconstructed.
<Report Findings Here>

Describe how the procedures were examined to verify that hard-copy materials are
crosscut shredded, incinerated, or pulped such that there is reasonable assurance
that hardcopy materials cannot be reconstructed.
<Report Findings Here>

Describe how the storage containers used for materials to be destroyed are 1
secured. 1
<Report Findings Here>
Describe how cardholder data on electronic media is rendered unrecoverable, via 0
secure wiping of media and/or physical destruction of media.
<Report Findings Here>

If data is rendered unrecoverable via secure deletion or a secure wipe program,

identify the industry-accepted standards used. 1
<Report Findings Here>

Indicate whether this ROC is being completed prior to June 30, 2015. (yes/no) 0
<Report Findings Here>

If “yes” AND the assessed entity does not have this in place ahead of the
requirement’s effective date, mark 9.9 – 9.9.9.3.b as “Not Applicable.”
If not OR if the assessed entity has this in place ahead of the requirement’s effective
date, complete the following:

Identify the documented policies and procedures examined to verify they include:
 Maintaining a list of devices.
 Periodically inspecting devices to look for
tampering or substitution.
 Training personnel to be aware of suspicious behavior and to report tampering or
substitution of POS devices.
<Report Findings Here>
5
If “yes” at 9.9 AND the assessed entity does not have this in place ahead of the 0
requirement’s effective date, mark 9.9.1.a - 9.9.1.c as “Not Applicable.”
If not OR if the assessed entity has this in place ahead of the requirement’s effective
date, complete the following:

Identify the documented up-to-date list of devices examined to verify it includes:

 Make, model of device.
 Location of device (for example, the address of the site or facility where the 5
device is located).
<Report Findings Here>

Identify the sample of devices from the list selected for this testing procedure. 0
<Report Findings Here>

For all items in the sample, describe how the device locations for the sample of
devices was observed to verify that the list is accurate and up-to-date.
<Report Findings Here> 5

Identify personnel interviewed for this testing procedure. 0

<Report Findings Here>
For the interview, summarize the relevant details discussed that verify the list of
devices is updated when devices are added, relocated, decommissioned, etc. 5
<Report Findings Here>

If “yes” at 9.9 AND the assessed entity does not have this in place ahead of the 5 0
requirement’s effective date, mark 9.9.2.a - 9.9.2.b as “Not Applicable.”
If not OR if the assessed entity has this in place ahead of the requirement’s effective
date, complete the following:

Identify the documented procedures examined to verify that processes are defined
to include the following:
 Procedures for inspecting devices.
 Frequency of inspections.
<Report Findings Here>
Identify responsible personnel interviewed who confirm that: 5 0
 Personnel are aware of procedures for inspecting devices.
 All devices are periodically inspected for evidence of tampering and substitution.
<Report Findings Here>

Describe how inspection processes were observed to verify that:

All devices are periodically inspected for evidence of tampering.
All devices are periodically inspected for evidence of substitution.
<Report Findings Here>

If “yes” at 9.9 AND the assessed entity does not have this in place ahead of the 5 0
requirement’s effective date, mark 9.9.3.a - 9.9.3.b as “Not Applicable.”
If not OR if the assessed entity has this in place ahead of the requirement’s effective
date, complete the following:

Identify the training materials for personnel at point-of-sale locations that were
reviewed to verify the materials include training in the following:
 Verifying the identity of any third-party persons claiming to be repair or
maintenance personnel, prior to granting them access to modify or troubleshoot
devices.
 Not to install, replace, or return devices without verification.
 Being aware of suspicious behavior around devices (for example, attempts by
unknown persons to unplug or open devices).
 Reporting all suspicious behavior to appropriate personnel (for example, a
manager or security officer).
 Reporting tampering or substitution of devices.
<Report Findings Here>
Identify the sample of personnel at point-of- sale locations interviewed to verify 5 0
they have received training.
<Report Findings Here>

For the interview, summarize the relevant details discussed that verify interviewees
are aware of the procedures for the following:
Verifying the identity of any third-party persons claiming to be repair or
maintenance personnel, prior to granting them access to modify or troubleshoot
devices.
<Report Findings Here>

Not to install, replace, or return devices without verification.

<Report Findings Here>

Being aware of suspicious behavior around devices (for example, attempts by

unknown persons to unplug or open devices).
<Report Findings Here>

Reporting suspicious behavior and indications of device tampering or substitution

to appropriate personnel (for example, to a manager or security officer).
<Report Findings Here>

Identify the document reviewed to verify that security policies and operational 6 0
procedures for restricting physical access to cardholder data are documented.
<Report Findings Here>

Identify responsible personnel interviewed who confirm that the above

documented security policies and operational procedures for restricting physical
access to cardholder data are:

In use
Known to all affected parties
<Report Findings Here>

200 11
rs to full-time and part-time employees, temporary employees, contractors and consultants who are physically present on t

cted Merchant Type: D

A-EP PE2P B B-IP C-VT C D S In Place? Severity

1 0 0 0 0 0 1 1

N 5

0 0 0 0 0 0 1 1

N 5

0 0 0 0 0 0 1 1
N 5
0 0 0 0 0 0 1 1

N 5

0 0 0 1 0 1 1 1

N 5

0 0 0 0 0 0 1 1

N 5

0 0 0 0 0 0 1 1

N 2
0 0 0 0 0 0 1 1

N 2

0 0 0 0 0 0 1 1

N 2

0 0 0 0 0 0 1 1

N 2

0 0 0 0 0 0 1 1

N 2

0 0 0 0 0 0 1 1
N 2

0 0 0 0 0 0 1 1

N 2

0 0 0 0 0 0 1 1
N 2
0 0 0 0 0 0 1 1

N 2

0 0 0 0 0 0 1 1

N 2

0 0 0 0 0 0 1 1

N 2

0 0 0 0 0 0 1 1
N 2

0 0 0 0 0 0 1 1

N 2

0 0 0 0 0 0 1 1

N 2

0 0 0 0 0 0 1 1

N 2

0 0 0 0 0 0 1 1

N 2
1 1 1 1 1 1 1 1

N 2

0 0 1 1 0 0 1 1

N 2

0 0 1 1 0 0 1 1

N 2

1 0 1 1 1 1 1 1

N 2

1 0 1 1 1 1 1 1

N 2

1 0 1 1 1 1 1 1

N 2
1 0 1 1 1 1 1 1

N 2

1 0 1 1 1 1 1 1

N 2

1 0 1 1 1 1 1 1

N 2

0 0 1 0 1 1 1 1

N 2

1 1 1 1 1 1 1 1

N 2
1 1 1 1 1 1 1 1

N 2

1 0 1 1 1 1 1 1
N 6

0 0 0 0 0 1 1 1

N 6

0 1 1 1 0 1 1 1

NT 2
0 1 1 1 0 1 1 1

NT 2

0 1 1 1 0 1 1 1

Y 0

0 1 1 1 0 1 1 1

Y 0

0 1 1 1 0 1 1 1

C 0
0 1 1 1 0 1 1 1

Y 0

0 1 1 1 0 1 1 1

Y 0
0 1 1 1 0 1 1 1

Y 0

0 1 0 0 0 0 1 1

Y 0

11 12 21 21 11 21 45 45 Y 102
N
C
NT
NA
nsultants who are physically present on the entity’s premises. A “visitor” refers to a vendor, guest of any onsite personnel, s

Proofs / Stage of implementation Remediation plan

Documentation links
or, guest of any onsite personnel, service

Estimated date for completion Comment Owner

s
Return to Table of content Go to requirement 9
Requirement 10: Track and monitor all access to network resources and cardholder data
Logging mechanisms and the ability to track user activities are critical in preventing, detecting, or minimizing the impact of a data com

Major Observa
Organizations generally find enterprise log management hard, in terms of generating logs (covered in controls 10.1 and 10.2), protecti
one can have a knock-on effect on compliance with several others. But
One of the most challenging parts of Requirement 10 appears to be control 10.4. This specifies that access to time data is restricted,
with all

PCI DSS Requirement Guidance

10.1 Implement audit trails to link all access to It is critical to have a process or system that links
system components to each individual user. user access to system components accessed. This
system generates audit logs and provides the
ability to trace back suspicious activity to a
specific user.
10.2 Implement automated audit trails for all Generating audit trails of suspect activities alerts
system components to reconstruct the following the system administrator, sends data to other
events: monitoring mechanisms (like intrusion detection
systems), and provides a history trail for post-
incident follow-up. Logging of the following
events enables an organization to identify and
trace potentially malicious activities.

10.2.1 All individual accesses to cardholder data Malicious individuals could obtain knowledge of a
user account with access to systems in the CDE,
or they could create a new, unauthorized account
in order to access cardholder data. A record of all
individual accesses to cardholder data can
identify which accounts may have been
compromised or misused.

10.2.2 All actions taken by any individual with Accounts with increased privileges, such as the
root or administrative privileges “administrator” or “root” account, have the
potential to greatly impact the security or
operational functionality of a system. Without a
log of the activities performed, an organization is
unable to trace any issues resulting from an
administrative mistake or misuse of privilege back
to the specific action and individual.

10.2.3 Access to all audit trails Malicious users often attempt to alter audit logs
to hide their actions, and a record of access
allows an organization to trace any
inconsistencies or potential tampering of the logs
to an individual account,
 10.2.4 Invalid logical access attempts Malicious individuals will often perform multiple
access attempts on targeted systems. Multiple
invalid login attempts may be an indication of an
unauthorized user’s attempts to “brute force” or
guess a password.

10.2.5 Use of identification and authentication Without knowing who was logged on at the time
mechanisms —including but not limited to of an incident, it is impossible to identify the
creation of new accounts and elevation of accounts which may be used. Additionally,
privileges—and all changes, additions, or malicious users may attempt to manipulate the
deletions to accounts with root or administrative authentication controls with the intent of
privileges 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 system’s
authentication mechanisms.

10.2.6 Initialization of the audit logs Turning the audit logs off prior to performing
illicit activities is a common goal for malicious
users wishing to avoid detection. Initialization of
audit logs could indicate that the log function was
disabled by a user to hide their actions.

10.2.7 Creation and deletion of system-level Malicious software, such as malware, often
objects creates or replaces system level objects on the
target system in order to control a particular
function or operation on that system.
Please refer to the PCI DSS and PA-DSS Glossary
of Terms, Abbreviations, and Acronyms for
definitions of “system-level objects”.

10.3 Record at least the following audit trail entries By recording these details for the auditable
for all system components for each event: events at 10.2, a potential compromise can be
quickly identified, and with sufficient detail to
know who, what, where, when, and how.

10.3.1 User identification

 10.3.2 Type of event

10.3.3 Date and time

10.3.4 Success or failure indication

10.3.5 Origination of event

10.3.6 Identity or name of affected data, system

component, or resource.

10.4 Using time-synchronization technology, Time synchronization technology is used to

synchronize all critical system clocks and times and synchronize clocks on multiple systems. When
ensure that the following is implemented for properly deployed, this technology can
acquiring, distributing, and storing time. synchronize clocks on large numbers of systems
to within a fraction of a second of each other.
Note: One example of time synchronization Some problems that can occur when clocks are
technology is Network Time Protocol (NTP). 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

10.4.1 Critical systems have the correct and technology is Network Time Protocol (NTP).
consistent time.
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 system’s clock.

More information on NTP can be found at

www.ntp.org, including information about time,
time standards, and servers.
 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 system’s clock.

More information on NTP can be found at

www.ntp.org, including information about time,
time standards, and servers.

10.4.2 Time data is protected.

10.4.3 Time settings are received from industry-
accepted time sources.
10.5 Secure audit trails so they cannot be altered. Often a malicious individual who has entered the
network will attempt to edit the audit logs in
order to hide their activity. Without adequate
protection of audit logs, their completeness,
accuracy, and integrity cannot be guaranteed,
and the audit logs can be rendered useless as an
investigation tool after a compromise.

10.5.1 Limit viewing of audit trails to those with a Adequate protection of the audit logs includes
job-related need. strong access control (limit access to logs based
on “need to know” only) and use of internal
segregation (to make the logs harder to find and
modify). By writing logs from external-facing
technologies such as wireless, firewalls, DNS, and
mail servers, the risk of those logs being lost or
altered is lowered, as they are more secure
within the internal network.

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 By writing logs from external-facing technologies
onto a log server on the internal LAN. 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.
Logs may be written directly, or offloaded or
copied from external systems, to the secure
internal system or media.

10.5.5 Use file-integrity monitoring or change- File-integrity monitoring systems check for
detection software on logs to ensure that existing changes to critical files, and notify when such
log data cannot be changed without generating changes are noted. For file-integrity monitoring
alerts (although new data being added purposes, an entity usually monitors files that
should not cause an alert). don’t regularly change, but when changed
indicate a possible compromise. For log files
(which do change frequently) what should be
monitored are, for example, when a log file is
deleted, suddenly grows or shrinks significantly,
and any other indicators that a malicious
individual has tampered with a log file. There are
both off-the-shelf and open source tools available
for file-integrity monitoring.

10.6 Review logs for all system components at least Many breaches occur over days or months before
daily. Log reviews must include those servers that being detected. Checking logs daily minimizes the
perform security functions like intrusion-detection amount of time and exposure of a potential
system (IDS) and authentication, authorization, and breach.
accounting protocol (AAA) servers (for example, Regular log reviews by personnel or automated
RADIUS). means can identify and proactively address
unauthorized access to the cardholder data
Note: Log harvesting, parsing, and alerting tools environment.
may be used to meet compliance with Requirement The log review process does not have to be
10.6. manual. The use of log harvesting, parsing, and
alerting tools can help facilitate the process by
identifying log events that need to be reviewed.

10.6.1 Review the following at least daily: Many breaches occur over days or months before
􏰀 All security events being detected. Checking logs daily minimizes the
􏰀 Logs of all system components that store, amount of time and exposure of a potential
process, or transmit CHD and/or SAD, or that breach.
could impact the security of CHD and/or SAD Daily review of security events—for example,
notifications or alerts that identify suspicious or
􏰀 Logs of all critical system components anomalous activities—as well as logs from critical
􏰀 Logs of all servers and system components that system components, and logs from systems that
perform security functions (for example, perform security functions, such as firewalls,
firewalls, intrusion-detection systems/intrusion- IDS/IPS, file-integrity monitoring (FIM) systems,
prevention systems (IDS/IPS), authentication etc. is necessary to identify potential issues. Note
servers, e-commerce redirection servers, etc.). that the determination of “security event” will
vary for each organization and may include
consideration for the type of technology,
location, and function of the device.
Organizations may also wish to maintain a
baseline of “normal” traffic to help identify
anomalous behavior.
 etc. is necessary to identify potential issues. Note
servers, e-commerce redirection servers, etc.). that the determination of “security event” will
vary for each organization and may include
consideration for the type of technology,
location, and function of the device.
Organizations may also wish to maintain a
baseline of “normal” traffic to help identify
anomalous behavior.

10.6.2 Review logs of all other system Logs for all other system components should also
components periodically based on the be periodically reviewed to identify indications of
organization’s policies and risk management potential issues or attempts to gain access to
strategy, as determined by the organization’s sensitive systems via less-sensitive systems. The
annual risk assessment. frequency of the reviews should be determined
by an entity’s annual risk assessment.
 10.6.3 Follow up exceptions and anomalies If exceptions and anomalies identified during the
identified during the review process. log-review process are not investigated, the entity
may be unaware of unauthorized and potentially
malicious activities that are occurring within their
own network.

10.7 Retain audit trail history for at least one year, Retaining logs for at least a year allows for the
with a minimum of three months immediately fact that it often takes a while to notice that a
available for analysis (for example, online, archived, compromise has occurred or is occurring, and
or restorable from back-up). 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.
10.8 Ensure that security policies and operational Personnel need to be aware of and following
procedures for monitoring all access to network security policies and daily operational procedures
resources and cardholder data are documented, in for monitoring all access to network resources
use, and known to all affected parties. and cardholder data on a continuous basis.
 Go to requirement 11 Executive Summary
older data
or minimizing the impact of a data compromise. The presence of logs in all environments allows thorough tracking, alerting, and analysis when som

Major Observations from the 2014 Verizon PCI Compliance Report:

vered in controls 10.1 and 10.2), protecting them (10.5), reviewing them (10.6), and archiving them (10.7). Furthermore, many of the controls within
on compliance with several others. But the trends are promising: in 2013 the average rose to 82.2% and 60.0% of organizations were fully complian
es that access to time data is restricted, external time signals are properly used, and that changes to time settings are logged, monitored, and revie
with all parts of this control between 2011 and 2013.

SANS Testing Procedure

Top 20 Critical
Security Controls

C17.2 10.1 Verify, through observation and interviewing the system administrator, that:
-Audit trails are enabled and active for system components.
-Access to system components is linked to individual users.
C14.1 10.2 Through interviews, examination of audit logs, and examination of audit log
C14.6 settings, perform the following:

C.14.3 10.2.1 Verify all individual access to cardholder data is logged.

C12.9 10.2.2 Verify actions taken by any individual with root or administrative privileges are
C12.10 logged.

NC 10.2.3 Verify access to all audit trails is logged.

C14.3 10.2.4 Verify invalid logical access attempts are logged.

NC 10.2.5 Verify use of identification and authentication mechanisms is logged.

10.2.5.b Verify all elevation of privileges is logged.

10.2.5.c Verify all changes, additions, or deletions to any account with root or
administrative privileges are logged.

NC 10.2.6 Verify initialization of audit logs is logged.

C.14.3 10.2.7 Verify creation and deletion of system level objects are logged.

C14.1 10.3 Through interviews and observation, for each auditable event (from 10.2),
perform the following:

NC 10.3.1 Verify user identification is included in log entries.

 NC 10.3.2 Verify type of event is included in log entries.

NC 10.3.3 Verify date and time stamp is included in log entries.

C14.3 10.3.4 Verify success or failure indication is included in log entries.

NC 10.3.5 Verify origination of event is included in log entries.

NC 10.3.6 Verify identity or name of affected data, system component, or resources is

included in log entries.

C.14.5 10.4 Examine configuration standards and processes to verify that time-
synchronization technology is implemented and kept current per PCI DSS
Requirements 6.1 and 6.2.

C6.5 10.4.1.a Examine the process for acquiring, distributing and storing the correct time
within the organization to verify that:
-Only the designated central time server(s) receives time signals from external
sources, and time signals from external sources are based on International Atomic
Time or UTC.
-Where there is more than one designated time server, the time servers peer with one
another to keep accurate time,
- Systems receive time information only from designated central time server(s).
 10.4.1.b Observe the time-related system-parameter settings for a sample of system
components to verify:
-Only the designated central time server(s) receives time signals from external
sources, and time signals from external sources are based on International Atomic
Time or UTC.
-Where there is more than one designated time server, the designated central time
server(s) peer with one another to keep accurate time.
- Systems receive time only from designated central time server(s).

NC 10.4.2.a Examine 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 Examine system configurations, time synchronization settings and logs, and
processes to verify that any changes to time settings on critical systems are logged,
monitored, and reviewed.

C14.5 10.4.3 Examine systems configurations to verify that the time server(s) accept time
updates from specific, industry-accepted external sources (to prevent a malicious
individual from changing the clock). Optionally, those updates can be encrypted with a
symmetric key, and access control lists can be created that specify the IP addresses of
client machines that will be provided with the time updates (to prevent unauthorized
use of internal time servers).
C14.2.1 10.5 Interview system administrator and examine permissions to verify that audit
C14.7 trails are secured so that they cannot be altered as follows:

NC 10.5.1 Verify that only individuals who have a job-related need can view audit trail
files.

C14.7 10.5.2 Verify that current audit trail files are protected from unauthorized
modifications via access control mechanisms, physical segregation, and/or network
segregation.

C14.2.1 10.5.3 Verify that current audit trail files are promptly backed up to a centralized log
server or media that is difficult to alter.
C14.7 10.5.4 Verify that logs for external-facing technologies (for example, wireless,
firewalls, DNS, mail) are offloaded or copied onto a secure centralized internal log
server or media.

NC 10.5.5 Examine system settings, monitored files, and results from monitoring activities
to verify the use of file-integrity monitoring or change-detection software on logs.

C14.4 Not povided by PCIco

C14.6

10.6.1.a Examine security policies and procedures to verify that procedures are
defined for reviewing the following at least daily, either manually or via log tools:
-All security events
-Logs of all system components that store, process, or transmit CHD and/or SAD, or
that could impact the security of CHD and/or SAD
-Logs of all critical system components
-Logs of all servers and system components that perform security functions (for
example, firewalls, intrusion-detection systems/intrusion-prevention systems
(IDS/IPS), authentication servers, e-commerce redirection servers, etc.)
10.6.1.b Observe processes and interview personnel to verify that the following are
reviewed at least daily:
-All security events
-Logs of all system components that store, process, or transmit CHD and/or SAD, or
that could impact the security of CHD and/or SAD
-Logs of all critical system components
-Logs of all servers and system components that perform security functions (for
example, firewalls, intrusion-detection systems/intrusion-prevention systems
(IDS/IPS), authentication servers, e-commerce redirection servers, etc.).

10.6.2.a Examine security policies and procedures to verify that procedures are
defined for reviewing logs of all other system components periodically—either
manually or via log tools—based on the organization’s policies and risk management
strategy.

10.6.2.b Examine the organization’s risk-assessment documentation and interview

personnel to verify that reviews are performed in accordance with organization’s
policies and risk management strategy.
 10.6.3.a Examine security policies and procedures to verify that procedures are
defined for following up on exceptions and anomalies identified during the review
process.

10.6.3.b Observe processes and interview personnel to verify that follow-up to

exceptions and anomalies is performed.

NC 10.7.a Examine security policies and procedures to verify that they define the
following:
-Audit log retention policies
- Procedures for retaining audit logs for at least one year, with a minimum of three
months immediately available online.

10.7.b Interview personnel and examine audit logs to verify that audit logs are
available for at least one year.

10.7.c Interview personnel and observe processes to verify that at least the last three
months’ logs can be immediately restored for analysis.
10.8 Examine documentation interview personnel to verify that security policies and
operational procedures for monitoring all access to network resources and cardholder
data are:
-Documented,
- In use, and
-Known to all affected parties.
ing, alerting, and analysis when something does go wrong. Determining the cause of a compromise is very difficult, if not impossible, without system

ermore, many of the controls within Requirement 10 are interdependent, and failing to comply with
of organizations were fully compliant.
s are logged, monitored, and reviewed. We found that just 49.5% of organizations were compliant

Selected Merchant Typ

Validation Instructions for QSA/ISA Priority A A-EP

(For In-Place Requirements)

Identify the system administrator(s) interviewed who confirm that: 0 0

Audit trails are enabled and active for system components.
Access to system components is linked to individual users.
<Report Findings Here>
Describe how audit trails were observed to verify the following:
Audit trails are enabled and active for system components.
Access to system components is linked to individual users. 4
<Report Findings Here>
Identify the responsible personnel interviewed who confirm the following from 0 1
10.2.1-10.2.7 are logged:
All individual access to cardholder data.
All actions taken by any individual with root or administrative privileges.
Access to all audit trails.
All actions taken by any individual with root or administrative privileges.
Use of identification and authentication mechanisms.
All elevation of privileges.
All changes, additions, or deletions to any
account with root or administrative privileges.
Initialization of audit logs.
Stopping or pausing of audit logs.
Creation and deletion of system level objects.
<Report Findings Here>

Identify the sample of audit logs observed to verify the following from 10.2.1-10.2.7
are logged:
All individual access to cardholder data.
All actions taken by any individual with root or administrative privileges.
Access to all audit trails.
All actions taken by any individual with root or administrative privileges. 4
Use of identification and authentication mechanisms.
All elevation of privileges.
All changes, additions, or deletions to any
account with root or administrative privileges.
Initialization of audit logs.
Stopping or pausing of audit logs.
Creation and deletion of system level objects.
<Report Findings Here>

For all items in the sample at 10.2, describe how configuration settings were 0 0
observed to verify all individual access to cardholder data is logged.
<Report Findings Here>

For all items in the sample at 10.2, describe how configuration settings were 0 1
observed to verify all actions taken by any individual with root or administrative
privileges are logged.
<Report Findings Here>

For all items in the sample at 10.2, describe how configuration settings were 0 0
observed to verify access to all audit trails is logged.
<Report Findings Here> 4
For all items in the sample at 10.2, describe how configuration settings were 0 1
observed to verify invalid logical access attempts are logged.
<Report Findings Here>
4

For all items in the sample at 10.2, describe how configuration settings were 0 1
observed to verify use of identification and authentication mechanisms is logged.
<Report Findings Here> 4

For all items in the sample at 10.2, describe how configuration settings were 0 1
observed to verify all elevation of privileges is logged.
<Report Findings Here>
4

For all items in the sample at 10.2, describe how configuration settings were 0 1
observed to verify all changes, additions, or deletions to any account with root or
administrative privileges are logged.
<Report Findings Here> 4

For all items in the sample at 10.2, describe how configuration settings were 0 0
observed to verify initialization of audit logs is logged.
<Report Findings Here>
4

For all items in the sample at 10.2, describe how configuration settings were 0 0
observed to verify creation and deletion of system level objects are logged.
<Report Findings Here>

Identify the responsible personnel interviewed who confirm that for each auditable 0 1
event from 10.2.1-10.2.7, the following are included in log entries:
User identification
Type of event
Date and time
Success or failure indication
Origination of event
<Report Findings Here>

Identify the sample of audit logs from 10.2.1- 10.2.7 observed to verify the 4
following are included in log entries:
<Report Findings Here>

For all logs in the sample at 10.3, describe how the audit logs were observed to 0 1
verify user identification is included in log entries.
<Report Findings Here> 4
For all logs in the sample at 10.3, describe how the audit logs were observed to 0 1
verify type of event is included in log entries.
<Report Findings Here> 4

For all logs in the sample at 10.3, describe how the audit logs were observed to 0 1
verify date and time stamp is included in log entries.
<Report Findings Here>
4

For all logs in the sample at 10.3, describe how the audit logs were observed to 0 1
verify success or failure indication is included in log entries.
<Report Findings Here> 4

For all logs in the sample at 10.3, describe how event is included in log entries. the 0 1
audit logs were observed to verify origination of event is included in log entries.
<Report Findings Here> 4

For all logs in the sample at 10.3, describe how the audit logs were observed to 0 1
verify the identity or name of affected data, system component, or resource is
included in log entries.
<Report Findings Here> 4

Identify the time synchronization technologies in use. (If NTP, include version) 0 0
<Report Findings Here>

Identify the documented time-synchronization process that defines processes for

ensuring the time synchronization technologies are kept current per PCI DSS
Requirements 6.1 and 6.2.
<Report Findings Here>

Describe how processes were examined to verify that time synchronization

technologies are: 4
Implemented.
Kept current, per the documented process.
<Report Findings Here>

Identify the documented process for acquiring, distributing, and storing the correct 0 0
time within the organization examined to verify that the process defines the
following:
Only the designated central time server(s) receive time signals from external
sources, and time signals from external sources are based on International Atomic
Time or UTC.
Where there is more than one designated time server, the time servers peer with 4
one another to keep accurate time.
Systems receive time information only from designated central time server(s).
<Report Findings Here>
Identify the sample of system components selected for 10.4.1.b-10.4.2.b 0 0
<Report Findings Here>

For all items in the sample, describe how the time-related system-parameter
settings for the sample of system components were observed to verify:

Only the designated central time server(s) receive time signals from external
sources, and time signals from external sources are based on International Atomic
Time or UTC.
<Report Findings Here>
Where there is more than one designated time server, the designated central time
server(s) peer with one another to keep accurate time. 4
<Report Findings Here>

Systems receive time only from designated central time server(s).

<Report Findings Here>

Identify the documented time-synchronization procedures examined to verify 0 0

procedures define that:
Access to time data is restricted to only personnel with a business need to access
time data.
Define which personnel have a business need to access time data.
<Report Findings Here>

Identify the authorized personnel interviewed who confirm that personnel with
access to time data have a business need to access time data.
<Report Findings Here>
4
For all items in the sample from 10.4.1, describe how configuration settings were
examined to restrict access to time data to only personnel with a documented
need.
<Report Findings Here>
Identify the documented time-synchronization procedures examined to verify 0 0
procedures define that changes to time settings on critical systems must be:
Logged
Monitored
Reviewed
<Report Findings Here>
For all items in the sample from 10.4.1, describe how configuration settings on the
sampled system components were examined to log any changes to time settings on
critical systems.
<Report Findings Here>

For all items in the sample from 10.4.1, describe how logs were examined to log any
changes to time settings on critical systems.
<Report Findings Here>

Describe how time synchronization processes were examined to verify changes to 4

time settings on critical systems are:
Logged
Monitored
Reviewed
<Report Findings Here>

Identify the document reviewed to verify it defines that: 0 0

Time settings are configured to either accept time updates from specific, industry-
accepted time sources; OR
The updates are encrypted with a symmetric key and access control lists specify the
IP addresses of client machines that will be provided with the time updates.
<Report Findings Here>

Identify the sample of time servers selected.

<Report Findings Here>

For all items in the sample, describe how configuration settings were examined to
verify either of the following:
<Report Findings Here>

That the time servers receive time updates from specific, industry-accepted
external sources. OR
<Report Findings Here>

That time updates are encrypted with a symmetric key, and access control lists 4
specify the IP addresses of client machines.
<Report Findings Here>
Identify the industry-accepted time source indicated (if applicable).
<Report Findings Here>
Identify the system administrators interviewed who confirm that audit trails are 0 0
secured so that they cannot be altered as follows (from 10.5.1- 10.5.5):
Only individuals who have a job-related need can view audit trail files.
Current audit trail files are protected from unauthorized modifications via access
control mechanisms, physical segregation, and/or network segregation.
Current audit trail files are promptly backed up to a centralized log server or media
that is difficult to alter, including:
That current audit trail files are promptly backed up to the centralized log server or
media
The frequency that audit trail files are backed up
That the centralized log server or media is difficult to alter
Logs for external-facing technologies (for example, wireless, firewalls, DNS, mail)
are written onto a secure, centralized, internal log server or media.
Use file-integrity monitoring or change- detection software on logs to ensure that
existing log data cannot be changed without generating alerts. 4
<Report Findings Here>

Identify the sample of system components selected for this testing procedure from
10.5.1- 10.5.5.
<Report Findings Here>

For each item in the sample at 10.5, describe how system configurations and 0 0
permissions were examined to verify they restrict viewing of audit trail files to only
individuals who have a documented job-related need.
<Report Findings Here>
4

For each item in the sample at 10.5, describe how system configurations and 0 0
permissions were examined to verify that current audit trail files are protected from
unauthorized modifications. (e.g., via access control mechanisms, physical
segregation, and/or network segregation).
<Report Findings Here> 4

For each item in the sample at 10.5, describe how system configurations and 0 0
permissions were examined to verify that current audit trail files are promptly
backed up to a centralized log server or media that is difficult to alter.
<Report Findings Here>

Identify and briefly describe the following:

The centralized log server or media to which audit trail files are backed up.
<Report Findings Here>

How frequently the audit trail files are backed up, and how the frequency is
appropriate. 4
<Report Findings Here>

How the centralized log server or media is difficult to alter.

<Report Findings Here>
For each item in the sample at 10.5, describe how system configurations and 0 1
permissions were examined to verify that logs for external- facing technologies are
written onto a secure, centralized, internal log server or media.
<Report Findings Here>

Describe how logs for external-facing technologies are written onto a secure
centralized internal log server or media 4
<Report Findings Here>.

For each item in the sample at 10.5, describe how the following were examined to 0 0
verify the use of file-integrity monitoring or change-detection software on logs:
System settings
Monitored files
Results from monitoring activities
Identify the file-integrity monitoring (FIM) or change-detection software verified to
be in use.
<Report Findings Here>
4

Not provided by PCIco 0 1

Identify the documented security policies and procedures examined to verify that 0 0
procedures define reviewing the following at least daily, either manually or via log
tools:
All security events.
Logs of all system components that store, process, or transmit CHD and/or SAD, or
that could impact the security of CHD and/or SAD.
Logs of all critical system components.
Logs of all servers and system components that perform security functions. 4
<Report Findings Here>

Describe the manual or log tools used for daily review of logs.
<Report Findings Here>
Identify the personnel interviewed who confirm that the following are reviewed at 0 1
least daily:
All security events.
Logs of all system components that store, process, or transmit CHD and/or SAD, or
that could impact the security of CHD and/or SAD.
Logs of all critical system components.
Logs of all servers and system components that perform security functions.
<Report Findings Here>

Describe how processes were observed to verify that the following are reviewed at
least daily:

All security events.

<Report Findings Here>

Logs of all system components that store, process, or transmit CHD and/or SAD, or
that could impact the security of CHD and/or SAD.
<Report Findings Here>
4
Logs of all critical system components.
<Report Findings Here>

Logs of all servers and system components that perform security functions.
<Report Findings Here>

Identify the documented security policies and procedures examined to verify that 0 0
procedures define reviewing logs of all other system components periodically—
either manually or via log tools—based on the organization’s policies and risk
management strategy.
<Report Findings Here>

Describe the manual or log tools defined for periodic review of logs of all other 4
system components.
<Report Findings Here>

Identify the organization’s risk assessment documentation examined to verify that 0 1

reviews are performed in accordance with the organization’s policies and risk
management strategy.
<Report Findings Here>

For the interview, summarize the relevant details discussed that verify that reviews
are performed in accordance with the organization’s policies and risk management 4
strategy.
<Report Findings Here>
Identify the documented security policies and procedures examined to verify that 0 0
procedures define following up on exceptions and anomalies identified during the
review process.
<Report Findings Here>

Describe how processes were observed to verify that follow-up to exceptions and 0 0
anomalies is performed.
<Report Findings Here>

Identify the personnel interviewed who confirm that follow-up to exceptions and
anomalies is performed.
<Report Findings Here> 4

Identify the documented security policies and procedures examined to verify that 0 0
procedures define the following:
Audit log retention policies.
Procedures for retaining audit logs for at least one year, with a minimum of three
months immediately available online.
<Report Findings Here> 4

Identify the personnel interviewed who confirm that audit logs are available for at 0 1
least one year.
<Report Findings Here>

Describe how the audit logs were examined to verify that audit logs are available for
at least one year. 4
<Report Findings Here>

Identify the personnel interviewed who confirm that at least the last three months’ 0 1
logs can be immediately restored for analysis.
<Report Findings Here>

Describe the processes observed to verify that at least the last three months’ logs
can be immediately restored for analysis. 4
<Report Findings Here>
Identify the document reviewed to verify that security policies and operational 0 0
procedures for monitoring all access to network resources and cardholder data are
documented.
<Report Findings Here>

Identify responsible personnel interviewed who confirm that the above

documented security policies and operational procedures for monitoring all access
to network resources and cardholder data are:
In use 6
Known to all affected parties
<Report Findings Here>

166 0 19
ot impossible, without system activity logs.

ed Merchant Type D

PE2P B B-IP C-VT C D S In Place? Severity Proofs /

Documentation links

0 0 0 0 0 1 1

NA 0
0 0 0 0 1 1 1

NA 0

0 0 0 0 0 1 1

N 3

0 0 0 0 1 1 1

N 3

0 0 0 0 0 1 1

N 3
0 0 0 0 1 1 1

N 3

0 0 0 0 1 1 1
N 3

0 0 0 0 1 1 1

N 3

0 0 0 0 1 1 1

N 3

0 0 0 0 0 1 1

N 3

0 0 0 0 0 1 1

N 3

0 0 0 0 1 1 1

N 3

0 0 0 0 1 1 1

N 3
0 0 0 0 1 1 1

N 3

0 0 0 0 1 1 1

N 3

0 0 0 0 1 1 1

N 3

0 0 0 0 1 1 1

N 3

0 0 0 0 1 1 1

N 3

0 0 0 0 0 1 1

N 3

0 0 0 0 0 1 1

N 3
0 0 0 0 0 1 1

N 3

0 0 0 0 0 1 1

N 3
0 0 0 0 0 1 1

N 3

0 0 0 0 0 1 1

N 3
0 0 0 0 0 1 1

N 3

0 0 0 0 0 1 1

N 3

0 0 0 0 0 1 1

N 3

0 0 0 0 0 1 1

N 3
0 0 0 0 0 1 1

N 3

0 0 0 0 0 1 1

N 3

0 0 0 0 1 1 1

N 3

0 0 0 0 1 1 1

Y 0
0 0 0 0 1 1 1

Y 0

0 0 0 0 1 1 1

Y 0

0 0 0 0 1 1 1

N 3
0 0 0 0 1 1 1

NT 3

0 0 0 0 1 1 1

NA 0

0 0 0 0 0 1 1

N 3

0 0 0 0 1 1 1

N 3

0 0 0 0 1 1 1

N 3
0 1 0 1 0 1 1

NT 1

0 1 0 1 22 41 41 Y 103
N
C
NT
NA
Stage of implementation Remediation plan
Estimated date for completion Comments Owner
Return to Table of content Go to requriement 10
Requirement 11: Regularly test security systems and processes.
Vulnerabilities are being discovered continually by malicious individuals and researchers, and being introduced by new software. Syste
Major observations from the 2014 Verizon PCI Compliance Report:
Requirement 11 was the least complied-with requirement in our study. Just 23.8% of companies met all the controls between 2011 an
Controls and subcontrols where we saw the lowest compliance between 2011 and 2013 were:
• 11.3.a[Examinetheresultsfromthemostrecentpenetrationtesttoverifythatpenetration
testing is performed at least annually], 39.6%
• 11.3.b[Verifythatnotedexploitablevulnerabilitieswerecorrectedandtestingrepeated],43.6% • 11.2.1.a[Reviewthescanreportsandverif
the most recent 12-month period], 45.5%

PCI DSS Requirement Guidance

11.1 Implement processes to test for the presence Implementation and/or exploitation of wireless
of wireless access points (802.11), and detect and technology within a network is one of the most
identify all authorized and unauthorized wireless common paths for malicious users to gain access to
access points on a quarterly basis. the network and cardholder data. If a wireless
device or network is installed without a company’s
Note: Methods that may be used in the process knowledge, it can allow an attacker to easily and
include but are not limited to wireless network “invisibly” enter the network.
scans, physical/logical inspections of system
components and infrastructure, network access Unauthorized wireless devices may be hidden
control (NAC), or wireless IDS/IPS. Whichever within or attached to a computer or other system
methods are used, they must be sufficient to detect component, or be attached directly to a network
and identify any unauthorized devices. port or network device, such as a switch or router.
Any such unauthorized device could result in an
unauthorized access point into the environment.
Due to the ease with which a wireless access point
can be attached to a network, the difficulty in
detecting their presence, and the increased risk
presented by unauthorized wireless devices, these
processes must be performed even when a policy
exists prohibiting the use of wireless technology.

The size and complexity of a particular environment

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

Network access control (NAC) solutions can perform

device authentication and configuration
management to prevent unauthorized systems
connecting to the network, or unauthorized devices
connecting to authorized systems on the network.
An organization should have, as part of its incident
response plan, documented procedures to follow in
the event an unauthorized wireless access point is
detected. A wireless IDS/IPS should be configured to
 inspection due to the number of system
components and network points where a rogue
wireless access device could be installed or hidden.
In this case, multiple methods may be combined to
meet the requirement, such as performing physical
system inspections in conjunction with the results of
a wireless analyzer.

Network access control (NAC) solutions can perform

device authentication and configuration
management to prevent unauthorized systems
connecting to the network, or unauthorized devices
connecting to authorized systems on the network.
An organization should have, as part of its incident
response plan, documented procedures to follow in
the event an unauthorized wireless access point is
detected. A wireless IDS/IPS should be configured to
automatically generate an alert, but the plan must
also document response procedures if an
unauthorized device is detected during a manual
wireless scan.

11.1.1 Maintain an inventory of authorized

wireless access points including a documented
business justification.

11.1.2 Implement incident response procedures

in the event unauthorized wireless access points
are detected.

11.2 Run internal and external network vulnerability A vulnerability scan is an automated tool run against
scans at least quarterly and after any significant external and internal network devices and servers,
change in the network (such as new system designed to expose potential vulnerabilities in
component installations, changes in network networks that could be found and exploited by
11.2.1 Perform quarterly internal vulnerability An established process for identifying vulnerabilities
scans. on internal systems within the CDE requires that
vulnerability scans be conducted quarterly.
Identifying and addressing vulnerabilities in a timely
manner reduces the likelihood of a vulnerability
being exploited and potential compromise of a
system component or cardholder data.

Vulnerabilities posing the greatest risk to the

environment (for example, ranked “High” per
Requirement 6.2) should be resolved with the
highest priority.

As internal networks may be constantly changing

during the year, it is possible that an entity may not
have consistently clean internal vulnerability scans.
The intent is for an entity to have a robust
vulnerability management program in place to
resolve noted vulnerabilities in a reasonable
timeframe. At minimum, “High” vulnerabilities must
 being exploited and potential compromise of a
system component or cardholder data.

Vulnerabilities posing the greatest risk to the

environment (for example, ranked “High” per
Requirement 6.2) should be resolved with the
highest priority.

As internal networks may be constantly changing

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

Internal vulnerability scans can be performed by

qualified, internal staff that are reasonably
independent of the system component(s) being
scanned (for example, a firewall administrator
should not be responsible for scanning the firewall),
or an entity may choose to have internal
vulnerability scans performed by a PCI SSC
Approved Scanning Vendor (ASV), QSA or other firm
specializing in vulnerability scanning.

11.2.2 Perform quarterly external vulnerability As external networks are at greater risk of compromise, quarterly external vulne
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 Scanning an environment after any significant
any significant change. changes are made ensures that changes were
completed appropriately such that the security of
Note: Scans conducted after changes may be the environment was not compromised as a result
performed by internal staff. of the change. It may not be necessary to scan the
entire environment after a change. However, all
system components affected by the change will
need to be scanned.
11.3 Implement a methodology for penetration The intent of a penetration test is to simulate a real-
testing that includes the following: world attack situation with a goal of identifying how
far an attacker would be able to penetrate into an
-Is based on industry-accepted penetration testing environment. This allows an entity to gain a better
approaches (for example, NIST SP800-115) understanding of their potential exposure and
-Includes coverage for the entire CDE perimeter and develop a strategy to defend against attacks.
critical systems A penetration test differs from a vulnerability scan,
-Includes testing from both inside and outside the as a penetration test is an active process that may
network include exploiting identified vulnerabilities.
-Includes testing to validate any segmentation and Conducting a vulnerability scan may be one of the
scope-reduction controls first steps a penetration tester will perform in order
-Defines application-layer penetration tests to to plan the testing strategy, although it is not the
include, at a minimum, the vulnerabilities listed in only step. Even if a vulnerability scan does not
Requirement 6.5 detect known vulnerabilities, the penetration tester
-Defines network-layer penetration tests to include will often gain enough knowledge about the system
components that support network functions as well to identify possible security gaps.
as operating systems Penetration testing is generally a highly manual
-Includes review and consideration of threats and process. While some automated tools may be used,
vulnerabilities experienced in the last 12 months the tester uses their knowledge of systems to
-Specifies retention of penetration testing results penetrate into an environment. Often the tester will
and remediation activities results. 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 to identify areas
of potential weakness in the environment.
11.3.1 Perform external penetration testing at Penetration testing conducted on a regular basis
least annually and after any significant and after significant changes to the environment is a
infrastructure or application upgrade or proactive security measure that helps minimize
modification (such as an operating system potential access to the CDE by malicious individuals.
upgrade, a sub-network added to the The determination of what constitutes a significant
environment, or a web server added to the upgrade or modification is highly dependent on the
environment). configuration of a given environment. If an upgrade
or modification could allow access to cardholder
data or affect the security of the cardholder data
environment, then it could be considered
significant. Performing penetration tests after
network upgrades and modifications provides
assurance that the controls assumed to be in place
are still working effectively after the upgrade or
modification.
11.3.2 Perform internal penetration testing at
least annually and after any significant
infrastructure or application upgrade or
modification (such as an operating system
upgrade, a sub-network added to the
environment, or a web server added to the
environment).
11.3.3 Exploitable vulnerabilities found during
penetration testing are corrected and testing is
repeated to verify the corrections.

11.3.4 If segmentation is used to isolate the CDE Penetration testing is an important tool to confirm
from other networks, perform penetration tests that any segmentation in place to isolate the CDE
at least annually and after any changes to from other networks is effective. The penetration
segmentation controls/methods to verify that the testing should focus on the segmentation controls,
segmentation methods are operational and both from outside the entity’s network and from
effective, and isolate all out-of-scope systems inside the network but outside of the CDE, to
from in-scope systems. confirm that they are not able to get through the
segmentation controls to access the CDE. For
example, network testing and/or scanning for open
ports, to verify no connectivity between in-scope
and out-of-scope networks.
11.4 Use intrusion-detection systems, and/or Intrusion detection and/or intrusion prevention
intrusion-prevention systems to monitor all traffic at systems (IDS/IPS) compare the traffic coming into
the perimeter of the cardholder data environment the network with known “signatures” and/or
as well as at critical points inside of the cardholder behaviors of thousands of compromise types
data environment, and alert personnel to suspected (hacker tools, Trojans and other malware), and send
compromises. alerts and/or stop the attempt as it happens.
Without a proactive approach to unauthorized
Keep all intrusion-detection and prevention activity detection via these tools, attacks on (or
engines, baselines, and signatures up-to-date. 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 entity’s environment and as
documented in their risk assessment.
While many IDS/IPS devices today are able to
monitor multiple points inside of the CDE via one
device, it is important to remember the increased
exposure that may occur as a result of a failure in
that single device. Thus, it is important to
incorporate appropriate redundancy in the IDS/IPS
infrastructure.

There are thousands of compromise types, with

more being discovered on a daily basis. Stale
signatures and scanning engines on IDS/IPS devices
will not have the ability to identify new
vulnerabilities that could lead to an undetected
breach. Vendors of these products provide
frequent, often daily, updates that should be
evaluated and applied on a regular basis.
11.5 Deploy a change-detection mechanism (for Change-detection solutions such as file-integrity
example, file-integrity monitoring tools) to alert monitoring (FIM) tools check for changes to critical
personnel to unauthorized modification of critical files, and notify when such changes are detected. If
system files, configuration files, or content files; and not implemented properly and the output of the
configure the software to perform critical file change-detection solution monitored, a malicious
comparisons at least weekly. individual could alter configuration file contents,
operating system programs, or application
executables. 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.

11.5.1 Implement a process to respond to any alerts

generated by the change- detection solution.
11.6 Ensure that security policies and operational Personnel need to be aware of and following
procedures for security monitoring and testing are security policies and operational procedures for
documented, in use, and known to all affected security monitoring and testing on a continuous
parties basis.
 Go to requirement 12 Executive Summary

being introduced by new software. System components, processes, and custom software should be tested frequently to ensure security controls co

es met all the controls between 2011 and 2013.

11.2.1.a[Reviewthescanreportsandverifythatfourquarterlyinternalscanswereperformedin

SANS Testing Procedure

Top 20 Critical
Security Controls
C1.2 11.1.a Examine policies and procedures to verify processes are defined for detection
C13.9 and identification of both authorized and unauthorized wireless access points on a
C7.1 quarterly basis.
C7.3
C7.9

11.1.b Verify that the methodology is adequate to detect and identify any
unauthorized wireless access points, including at least the following:

- WLAN cards inserted into system components

- Portable wireless devices connected to system components (for example, by USB,
etc.)
- Wireless devices attached to a network port or network device

11.1.c Examine output from recent wireless scans to verify that:

-Authorized and unauthorized wireless access points are identified, and-
The scan 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.1 Examine documented records to verify that an inventory of authorized wireless

access points is maintained and a business justification is documented for all
authorized wireless access points.

11.1.2.a Examine the organization’s incident response plan (Requirement 12.10) to

verify it defines and requires a response in the event that an unauthorized wireless
access point is detected.

11.1.2.b Interview responsible personnel and/or inspect recent wireless scans and
related responses to verify action is taken when unauthorized wireless access points
are found.

C1.2 11.2 Examine scan reports and supporting documentation to verify that internal and
C13.9 external vulnerability scans are performed as follows:
C6.4
C4.1
C4.1 11.2.1.a Review the scan reports and verify that four quarterly internal scans occurred
C11.2 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 Interview personnel to verify that the scan was performed by a qualified
internal resource(s) or qualified external third party, and if applicable, organizational
independence of the tester exists (not required to be a QSA or ASV).

C4.1 11.2.2.a Review output from the four most recent quarters of external vulnerability
scans and verify that four quarterly scans occurred in the most recent 12-month
period.

11.2.2.b Review the results of each quarterly scan to ensure that they satisfy the ASV
Program Guide requirements (for example, no vulnerabilities rated higher than a 4.0
by the CVSS and no automatic failures).

For each of the four internal quarterly scans indicated at 11.2.2.a, identify whether a
rescan was necessary. (yes/no)

If “yes,” describe how the results of the rescan were reviewed to verify that the ASV
Program Guide requirements for a passing scan have been met.

If “yes,” describe how the results of the rescan were reviewed to verify that the ASV
Program Guide requirements for a passing scan have been met.
 11.2.2.c Review the scan reports to verify that the scans were completed by a PCI SSC
Approved Scanning Vendor (ASV).

C6.4 11.2.3.a Inspect and correlate change control documentation and scan reports to
C4.1 verify that system components subject to any significant change were scanned.
C11.2

11.2.3.b Review scan reports and verify that the scan process includes rescans until:
􏰀 For external scans, no vulnerabilities exist that are scored 4.0 or higher by the CVSS.
􏰀 For internal scans, all “high- risk” vulnerabilities as defined in PCI DSS Requirement
6.1 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 Examine penetration- testing methodology and interview responsible personnel
to verify a methodology is implemented and includes at least the following:
Is based on industry- accepted penetration testing approaches.
Includes coverage for the entire CDE perimeter and critical systems.
Includes testing from both inside and outside the network.
Includes testing to validate any segmentation and scope reduction controls.
Defines application-layer penetration tests to include, at a minimum, the
vulnerabilities listed in Requirement 6.5.
Defines network-layer penetration tests to include components that support network
functions as well as operating systems.
􏰀 Includes review and consideration of threats and vulnerabilities experienced in the
last 12 months.
􏰀 Specifies retention of penetration testing results and remediation activities results.
C13.9 11.3.1.a Examine the scope of work and results from the most recent external
C20.1 penetration test to verify that penetration testing is performed as follows:
􏰀 Per the defined methodology
􏰀 At least annually
􏰀 After any significant changes to the environment.
11.3.1.b 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.2.a Examine the scope of work and results from the most recent internal
penetration test to verify that penetration testing is performed at least annually and
after any significant changes to the environment.
Per the defined methodology
At least annually
After any significant changes
to the environment
11.3.2.b 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.3 Examine penetration testing results to verify that noted exploitable

vulnerabilities were corrected and that repeated testing confirmed the vulnerability
was corrected.

11.3.4.a Examine segmentation controls and review penetration-testing methodology

to verify that penetration- testing procedures are defined to test all segmentation
methods to confirm they are operational and effective, and isolate all out-of-scope
systems from in-scope systems.
 11.3.4.b Examine the results from the most recent penetration test to verify that
penetration testing to verify segmentation controls:
-Is performed at least annually and after any changes to segmentation
controls/methods.
-Covers all segmentation controls/methods in use.
-Verifies that segmentation methods are operational and effective, and isolate all out-
of-scope systems from in- scope systems.

C13.2 11.4.a Examine system configurations and network diagrams to verify that techniques
C13.3 (such as intrusion-detection systems and/or intrusion-prevention systems) are in place
C5.1.2 to monitor all traffic:
􏰀-At the perimeter of the cardholder data environment
􏰀-At critical points in the cardholder data environment.

11.4.b Examine system configurations and interview responsible personnel to

confirm intrusion-detection and/or intrusion-prevention techniques alert
personnel of suspected compromises.
 11.4.c Examine IDS/IPS configurations and vendor documentation to verify
intrusion-detection and/or intrusion- prevention techniques are configured,
maintained, and updated per vendor instructions to ensure optimal
protection.

C3.9 11.5.a Verify the use of a change-detection mechanism 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
􏰁 Additional critical files determined by entity (for example, through risk assessment
or other means).

11.5.b Verify the mechanism is configured to alert personnel to unauthorized

modification of critical files, and to perform critical file comparisons at least weekly.

11.5.1 Interview personnel to verify that all alerts are investigated and resolved.
11.6 Examine documentation interview personnel to verify that security policies and
operational procedures for security monitoring and testing are:
-Documented,
- In use, and
-Known to all affected parties.
ntly to ensure security controls continue to reflect a changing environment

Selected Merchant Typ

Validation Instructions for QSA/ISA Priotity A A-EP

(For In-Place Requirements)

Identify the documented policies and procedures examined to verify processes are 4 0 0
defined for detection and identification of authorized and unauthorized wireless
access points on a quarterly basis.
<Report Findings Here>

Describe how the methodology/processes were verified to be adequate to detect 4 0 0

and identify unauthorized wireless access points, including the following:
<Report Findings Here>

WLAN cards inserted into system components.

<Report Findings Here>

Portable or mobile devices attached to system components to create a wireless

access point.
<Report Findings Here>

Wireless devices attached to a network port or network device.

<Report Findings Here>

Any other unauthorized wireless access point.

<Report Findings Here>

Identify/describe the output from recent wireless scans examined to verify that: 4 0 0
Authorized wireless access points are identified.
Unauthorized wireless access points are identified.
The scan is performed at least quarterly.
The scan covers all system components.
The scan covers all facilities.
<Report Findings Here>
Identify whether automated monitoring is utilized. (yes/no) 4 0 0
<Report Findings Here>

If “no,” mark the remainder of 11.1.d as “Not Applicable.” If “yes,” complete the
following:
<Report Findings Here>
Identify and describe any automated monitoring technologies in use.
<Report Findings Here>

For each monitoring technology in use, describe how the technology generates
alerts to personnel.
<Report Findings Here>

Identify the documented inventory records of authorized wireless access points 4 0 0

examined to verify that an inventory of authorized wireless access points is
maintained and a business justification is documented for all authorized wireless
access points.
<Report Findings Here>

Identify the Incident Response Plan document examined that defines and requires 4 0 0
response in the event that an unauthorized wireless access point is detected.
<Report Findings Here>

Identify the responsible personnel interviewed for this testing procedure. 4 0 0

<Report Findings Here>

For the interview, summarize the relevant details discussed that verify that action is
taken when unauthorized wireless access points are found.
<Report Findings Here>
And/or:

Identify the recent wireless scans inspected for this testing procedure.
<Report Findings Here>

Describe how the recent wireless scans and related responses were inspected to
verify that action is taken when unauthorized wireless access points are found.
<Report Findings Here>

Not provided by PCIco 4 0 0

<Report Findings Here>

Identify the internal vulnerability scan reports and supporting documentation 0 0

reviewed.
<Report Findings Here>

Provide the name of the assessor who attests that four quarterly internal scans
were verified to have occurred in the most recent 12-month period. 2
<Report Findings Here>
Identify the documented process for quarterly internal scanning to verify the 0 0
process defines performing rescans as part of the quarterly internal scan process.
<Report Findings Here>

For each of the four internal quarterly scans indicated at 11.2.1.a, identify
whether a rescan was required. (yes/no)
<Report Findings Here>

If “yes,” describe how rescans were verified to be performed until either:
<Report Findings Here>
Passing results are obtained, or 2
<Report Findings Here>
All “High” vulnerabilities as defined in PCI DSS Requirement 6.1 are resolved.
<Report Findings Here>

Identifytheresponsiblepersonnelinterviewed who confirm that the scan was 0 0

performed by a qualified internal resource(s) or qualified external third party.
<Report Findings Here>
Identify whether a qualified internal resource performs the scan. (yes/no)
<Report Findings Here>

If “no,” mark the remainder of 11.2.1.c as “Not Applicable.”

If “yes,” complete the following:

Describe how the personnel who perform the scans demonstrated they are
qualified to perform the scans. 2
<Report Findings Here>

Describe how organizational independence of the tester was observed to exist.

<Report Findings Here>

Identify the external network vulnerability scan reports and supporting 0 1

documentation reviewed.
<Report Findings Here>

Provide the name of the assessor who attests that four quarterly external
vulnerability scans were verified to have occurred in the most recent 12-month 2
period.
<Report Findings Here>

Describe how the results of each quarterly scan were reviewed to verify that the 0 1
ASV Program Guide requirements for a passing scan have been met.
<Report Findings Here>

For each of the four internal quarterly scans indicated at 11.2.2.a, identify
whether a rescan was necessary. (yes/no)
<Report Findings Here>
2
Provide the name of the assessor who attests that the external scan reports were 0 1
reviewed and verified to have been completed by a PCI SSC-Approved Scanning
Vendor (ASV). 2
<Report Findings Here>

Identify the document reviewed to verify processes are defined for performing 0 1
internal and external scans after any significant change.
<Report Findings Here>
dentify the change control documentation and scan reports reviewed for this
testing procedure.
<Report Findings Here>

Describe how the change control documentation and scan reports were inspected 2
and correlated to verify that all system components subject to significant change
were scanned after the change.
<Report Findings Here>

For all scans reviewed in 11.2.3.a, identify whether a rescan was required. (yes/no) 0 1
<Report Findings Here>

If “yes” – for external scans, describe how rescans were performed until no
vulnerabilities with a CVSS score greater than 4.0 exist.
<Report Findings Here>

If “yes” – for internal scans, describe how rescans were performed until either 2
passing results were obtained or all “high-risk” vulnerabilities as defined in PCI DSS
Requirement 6.1 were resolved.
<Report Findings Here>

Describe how it was validated that the scan was performed by a qualified internal 0 1
resource(s) or qualified external third party.
<Report Findings Here>

Identify whether an internal resource performed the scans. (yes/no)

If “no,” mark the remainder of 11.2.3.c as “Not Applicable.”
If “yes,” complete the following:
<Report Findings Here>

Describe how the personnel who perform the scans demonstrated they are
qualified to perform the scans. 2
<Report Findings Here>

Describe how organizational independence of the tester was observed to exist.

<Report Findings Here>
Identify the documented penetration-testing methodology examined to verify a 0 1
methodology is implemented that includes at least the following:
Based on industry-accepted penetration testing approaches.
Coverage for the entire CDE perimeter and critical systems.
Testing from both inside and outside the network.
Testing to validate any segmentation and scope reduction controls.
Defines application-layer penetration tests to include, at a minimum, the
vulnerabilities listed in Requirement 6.5.
Defines network-layer penetration tests to include components that support
network functions as well as operating systems.
Review and consideration of threats and vulnerabilities experienced in the last 12
months.
Retention of penetration testing results and remediation activities results.
<Report Findings Here>

Identify the responsible personnel interviewed who confirm the penetration–

testing methodology implemented includes at least the following:
Based on industry-accepted penetration testing approaches.
Coverage for the entire CDE perimeter and critical systems.
Testing from both inside and outside the network.
Testing to validate any segmentation and scope reduction controls.
Defines application-layer penetration tests to include, at a minimum, the
vulnerabilities listed in Requirement 6.5.
Defines network-layer penetration tests to include components that support
network functions as well as operating systems.
Review and consideration of threats and vulnerabilities experienced in the last 12
months.
Retention of penetration testing results and remediation activities results.
<Report Findings Here>

Describe how the penetration-testing methodology was examined to verify that the
implemented methodology includes at least the following:

Based on industry-accepted penetration testing approaches.

<Report Findings Here>

Coverage for the entire CDE perimeter and critical systems.

<Report Findings Here>

Testing from both inside the network, and from outside of the network attempting
to get in. 2
<Report Findings Here>

Testing to validate any segmentation and scope-reduction controls.

<Report Findings Here>

Defines application-layer penetration tests to include, at a minimum, the

vulnerabilities listed in Requirement 6.5.
<Report Findings Here>

Defines network-layer penetration tests to include components that support

network functions as well as operating systems.
<Report Findings Here>

Review and consideration of threats and vulnerabilities experienced in the last 12

months.
<Report Findings Here>
Retention of penetration testing results and remediation activities results.
<Report Findings Here>
Coverage for the entire CDE perimeter and critical systems.
<Report Findings Here>
Testing from both inside the network, and from outside of the network attempting
to get in. 2
<Report Findings Here>
Testing to validate any segmentation and scope-reduction controls.
<Report Findings Here>

Defines application-layer penetration tests to include, at a minimum, the

vulnerabilities listed in Requirement 6.5.
<Report Findings Here>

Defines network-layer penetration tests to include components that support

network functions as well as operating systems.
<Report Findings Here>

Review and consideration of threats and vulnerabilities experienced in the last 12

months.
<Report Findings Here>

Retention of penetration testing results and remediation activities results.

<Report Findings Here>

Identify the documented external penetration test results reviewed to verify that 0 1
external penetration testing is performed:
Per the defined methodology
At least annually
<Report Findings Here>

Describe how the scope of work was reviewed to verify that external penetration
testing is performed:
Per the defined methodology
At least annually
<Report Findings Here>

Identify whether any significant external infrastructure or application upgrade or

modification occurred during the past 12 months.
<Report Findings Here>
2
Identify the documented penetration test results reviewed to verify that external
penetration tests are performed after significant external infrastructure or
application upgrade.
<Report Findings Here>
Describe how it was validated that the test was performed by a qualified internal 0 1
resource(s) or qualified external third party.
<Report Findings Here>

Identify whether an internal resource performed the test. (yes/no)

If “no,” mark the remainder of 11.3.1.b as “Not Applicable.”
If “yes,” complete the following:
Describe how the personnel who perform the scans demonstrated they are
qualified to perform the scans.
<Report Findings Here>
2
Describe how organizational independence of the tester was observed to exist.
<Report Findings Here>

Identify the documented internal penetration test results reviewed to verify that 0 0
internal penetration tests are performed after significant internal infrastructure or
application upgrade.
<Report Findings Here>

Describe how the scope of work was reviewed to verify that internal penetration
testing is performed:
Per the defined methodology
At least annually
<Report Findings Here>

Identify whether any significant internal infrastructure or application upgrade or

modification occurred during the past 12 months. (yes/no)
<Report Findings Here>
2
Identify the documented internal penetration test results reviewed to verify that
internal penetration tests are performed after significant internal infrastructure or
application upgrade.
<Report Findings Here>
Describe how it was validated that the test was performed by a qualified internal 0 0
resource(s) or qualified external third party.
<Report Findings Here>

Identify whether an internal resource performed the test. (yes/no)

If “no,” mark the remainder of 11.3.2.b as “Not Applicable.”
If “yes,” complete the following:
Describe how the personnel who perform the scans demonstrated they are
qualified to perform the scans
<Report Findings Here>

Describe how organizational independence of the tester was observed to exist.

<Report Findings Here>

Describe how the personnel who perform the scans demonstrated they are
qualified to perform the scans 2
<Report Findings Here>

Describe how organizational independence of the tester was observed to exist.

<Report Findings Here>

Identify the documented penetration testing results examined to verify that noted 0 1
exploitable vulnerabilities were corrected and that repeated testing confirmed the
vulnerability was corrected.
<Report Findings Here> 2

Identify whether segmentation is used to isolate the CDE from other networks. 0 1
(yes/no)
<Report Findings Here>

If “no,” mark the remainder of 11.3.4.a and 11.3.4.b as “Not Applicable.”

If “yes”:

Describe segmentation controls examined for this testing procedure.

<Report Findings Here>

Describe how the segmentation controls and penetration-testing methodology

were examined to verify that penetration testing procedures are defined to:
<Report Findings Here>
2
Test all segmentation methods to confirm they are operational and effective.
<Report Findings Here>

Isolate all out-of-scope systems from in-scope systems.

<Report Findings Here>
Identify the documented results from the most recent penetration test to verify 0 1
that penetration testing to verify segmentation controls:
Is performed at least annually and after any changes to segmentation
controls/methods. Covers all segmentation controls/methods in use.
Verifies that segmentation methods are operational and effective, and isolate all 2
out- of-scope systems from in-scope systems.
<Report Findings Here>

Identify the network diagrams examined to verify that techniques are in place to 0 0
monitor all traffic:
At the perimeter of the cardholder data environment.
At critical points in the cardholder data environment.
<Report Findings Here>

Identify the techniques observed to be in place to monitor all traffic:

At the perimeter of the cardholder data environment.
At critical points in the cardholder data environment.
<Report Findings Here>

Describe how system configurations were examined to verify that techniques are in
place to monitor all traffic:
<Report Findings Here>
At the perimeter of the cardholder data environment.
<Report Findings Here> 2

At critical points in the cardholder data environment.

<Report Findings Here>

Describe how system configurations for intrusion-detection, and/or intrusion- 0 0

prevention techniques were examined to verify they are configured to alert
personnel of suspected compromises.
<Report Findings Here>

Describe how alerts to personnel are generated.

<Report Findings Here>
2
Identify the responsible personnel interviewed who confirm that the generated
alerts are received as intended.
<Report Findings Here>
Identify the vendor document(s) examined to verify defined vendor instructions for 0 0
intrusion- detection and/or intrusion-prevention techniques
<Report Findings Here>

Describe how IDS/IPS configurations were examined and compared to vendor

documentation to verify intrusion-detection, and/or intrusion-prevention
techniques are:
Configured per vendor instructions to ensure optimal protection.
<Report Findings Here>
Maintained per vendor instructions to ensure optimal protection. 2
<Report Findings Here>
Updated per vendor instructions to ensure optimal protection.
<Report Findings Here>

Describe the change-detection mechanism deployed. 4 0 1

<Report Findings Here>

Identify the results from monitored files reviewed.

<Report Findings Here>

Describe how change-detection mechanism settings and results from monitored

files were observed to monitor changes to:

Critical system files

<Report Findings Here>

Critical configuration files

<Report Findings Here>

Critical content files

<Report Findings Here>

Describe how it was verified that the change-detection mechanism is configured to: 4 0 1
Alert personnel to unauthorized modification of critical files.
<Report Findings Here>

Perform critical file comparisons at least weekly.

<Report Findings Here>

Identify the personnel interviewed for this testing procedure. 4 0 1

<Report Findings Here>

For the interview, summarize details of the interview that verify that all alerts are
investigated and resolved.
<Report Findings Here>
Identify the document reviewed to verify that security policies and operational 6 0 0
procedures for security monitoring and testing are documented.
<Report Findings Here>

Identify responsible personnel interviewed who confirm that the above

documented security policies and operational procedures for security monitoring
and testing are:
In use
Known to all affected parties
<Report Findings Here>

90 0 15
ed Merchant Type D

PE2P B B-IP C-VT C D S In Place? Severity

0 0 0 0 1 1 1

N 3

0 0 0 0 1 1 1

N 3

0 0 0 0 1 1 1

N 3
0 0 0 0 1 1 1

N 3

0 0 0 0 1 1 1

N 3

0 0 0 0 1 1 1

N 3

0 0 0 0 1 1 1

N 3

0 0 0 0 1 1 1
N 3

0 0 0 0 1 1 1

N 5
0 0 0 0 1 1 1

N 5

0 0 0 0 1 1 1

N 5

0 0 1 0 1 1 1

N 5

0 0 1 0 1 1 1

N 5
0 0 1 0 1 1 1
N 5

0 0 0 0 1 1 1

N 5

0 0 0 0 1 1 1

N 5

0 0 0 0 1 1 1

N 5
0 0 0 0 0 1 1

N 5
 N 5

0 0 0 0 0 1 1

N 5
0 0 0 0 0 1 1

N 5

0 0 0 0 0 1 1

N 5
0 0 0 0 0 1 1

N 5

0 0 0 0 0 1 1

N 5

0 0 0 0 1 1 1

N 5
0 0 0 0 1 1 1

NT 5

0 0 0 0 0 1 1

N 5

0 0 0 0 0 1 1

N 5
0 0 0 0 0 1 1

N 5

0 0 0 0 1 1 1

N 3

0 0 0 0 1 1 1

N 3

0 0 0 0 1 1 1

C 0
0 1 0 1 0 1 1

Y 0

0 1 3 1 22 32 32 Y 130
N
C
NT
NA
 Proofs / Stage of implementation Remediation plan
Documentation links
Estimated date for Comments Owner
completion
Return to Table of content Go to Requirement 11
Requirement 12: Maintain a policy that addresses information security for all personnel.
A strong security policy sets the security tone for the whole entity and informs personnel what is expected of them. All personnel shou

Major Observ
Organizations found control 12.4 [Ensure that the security policy and procedures clearly defin
79.2% and 74.3% of organizations respectively were compliant with all the subcontrols of 12.7 [Screen potential personnel prior
Only 53.5% of organizations complie
And only 55.4% of organizations complied with 12.9.4 [Regularly train staff with security responsibilities]. Clearly,

PCI DSS Requirement Guidance

12.1 Establish, publish, maintain, and disseminate a A company's information security policy creates the
security policy. roadmap for implementing security measures to
protect its most valuable assets. A strong security
policy sets the security tone for the whole company,
and lets personnel know what is expected of them.
All personnel should be aware of the sensitivity of
data and their responsibilities for protecting it.

12.1.1 Review the security policy at least annually Security threats and protection methods evolve
and updates when the environment changes. rapidly throughout the year. Without updating the
security policy to reflect relevant changes, new
protection measures to fight against these threats
are not addressed.

12.2 Implement a risk-assessment process that: A risk assessment enables an organization to

-Is performed at least annually and upon significant identify threats and the associated vulnerabilities
changes to the environment (for example, which have the potential to negatively impact their
acquisition, merger, relocation, etc.), business. Resources can then be effectively
-Identifies critical assets, threats, and vulnerabilities, allocated to implement controls that reduce the
and likelihood and/or the potential impact of the threat
-Results in a formal risk assessment. 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,
changes to the environment (for example, which have the potential to negatively impact their
acquisition, merger, relocation, etc.), business. Resources can then be effectively
-Identifies critical assets, threats, and vulnerabilities, allocated to implement controls that reduce the
and likelihood and/or the potential impact of the threat
-Results in a formal risk assessment. being realized.
Performing risk assessments at least annually allows
the organization to keep up to date with
organizational changes and evolving threats, trends
and technologies,

12.3 Develop usage policies for critical technologies Personnel usage policies can either prohibit use of
(for example, remote- access technologies, wireless certain devices and other technologies if that is
technologies, removable electronic media, laptops, company policy, or provide guidance for personnel
tablets, personal data/digital assistants (PDAs), e- as to correct usage and implementation. If usage
mail usage and Internet usage) and define proper policies are not in place, personnel may use the
use of these technologies. Ensure these usage technologies in violation of company policy, thereby
policies require the following: allowing malicious individuals to gain access to
critical systems and cardholder data. An example
can be unknowingly setting up wireless networks
with no security. To ensure that company standards
are followed and only approved technologies are
implemented, consider confining implementation to
operations teams only and not allowing
unspecialized/general personnel install these
technologies.

12.3.1 Explicit approval by authorized parties Without requiring proper approval for
implementation of these technologies, individual
personnel may innocently implement a solution to a
perceived business need, but also open a huge hole
that subjects critical systems and data to malicious
individuals.

12.3.2 Authentication for use of the technology If technology is implemented without proper
authentication (user IDs and passwords, tokens,
VPNs, etc.), malicious individuals may easily use this
unprotected technology to access critical systems
and cardholder data.
12.3.3 A list of all such devices and personnel Malicious individuals may breach physical security
with access and place their own devices on the network as a
“back door.” Personnel may also bypass procedures
and install devices. An accurate inventory with
proper device labeling allows for quick identification
of non-approved installations.

12.3.4 A method to accurately and readily Malicious individuals may breach physical security
determine owner, contact information, and and place their own devices on the network as a
purpose (for example, labeling, coding, and/or “back door.” Personnel may also bypass procedures
inventorying of devices) and install devices. An accurate inventory with
proper device labeling allows for quick identification
of non-approved installations. Consider establishing
an official naming convention for devices, and log all
devices with established inventory controls. Logical
labeling may be employed with information such as
codes that can correlate the device to its owner,
contact information, and purpose.
12.3.5 Acceptable uses of the technology By defining acceptable business use and location of
company-approved devices and technology, the
company is better able to manage and control gaps
in configurations and operational controls, to
ensure a “back door” is not opened for a malicious
individual to gain access to critical systems and
12.3.6 Acceptable network locations for the cardholder data.
technologies

12.3.7 List of company-approved products

12.3.8 Automatic disconnect of sessions for Remote-access technologies are frequent "back
remote-access technologies after a specific period doors" to critical resources and cardholder data. By
of inactivity disconnecting remote-access technologies when not
in use (for example, those used to support your
systems by your POS vendor, other vendors, or
business partner), access and risk to networks is
minimized. Consider using controls to disconnect
devices after 15 minutes of inactivity. Please also
see Requirement 8.5.6 for more on this topic.
 12.3.9 Activation of remote-access technologies
for vendors and business partners only when
needed by vendors and business partners, with
immediate deactivation after use

12.3.10 For personnel accessing cardholder data To ensure all personnel are aware of their
via remote-access technologies, prohibit copy, responsibilities to not store or copy cardholder data
move, and storage of cardholder data onto local onto their local personal computer or other media,
hard drives and removable electronic media, your policy should clearly prohibit such activities
unless explicitly authorized for a defined business except for personnel that have been explicitly
need. authorized to do so. Any such authorized personnel
are responsible for ensuring that cardholder data in
their possession is handled in accordance with all
PCI DSS requirements, as that remote personnel’s
environment is now considered a part of the
organization’s cardholder data environment.

12.4 Ensure that the security policy and procedures Without clearly defined security roles and
clearly define information security responsibilities responsibilities assigned, there could be
for all personnel. inconsistent interaction with the security group,
leading to unsecured implementation of
technologies or use of outdated or unsecured
technologies.

12.5 Assign to an individual or team the following Each person or team with responsibilities for
information security management responsibilities: information security management should be clearly
aware of their responsibilities and related tasks,
through specific policy. Without this accountability,
gaps in processes may open access into critical
resources or cardholder data.

12.5.1 Establish, document, and distribute

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

12.5.3 Establish, document, and distribute

security incident response and escalation
procedures to ensure timely and effective
handling of all situations.

12.5.4 Administer user accounts, including

additions, deletions, and modifications

12.5.5 Monitor and control all access to data.

12.6 Implement a formal security awareness If personnel are not educated about their security
program to make all personnel aware of the responsibilities, security safeguards and processes
importance of cardholder data security. that have been implemented may become
ineffective through errors or intentional actions.

12.6.1 Educate personnel upon hire and at least If the security awareness program does not include
annually. periodic refresher sessions, key security processes
and procedures may be forgotten or bypassed,
Note: Methods can vary depending on the role of resulting in exposed critical resources and
the personnel and their level of access to the cardholder data. The focus and depth of the initial
cardholder data. and refresher training can vary depending on the
role of the personnel, and should be tailored as
appropriate for the particular audience. For
example, sessions for database administrators may
be focused on specific technical controls and
processes, while training for retail cashiers may
focus on secure transaction procedures

Consider including ongoing awareness updates to

keep employees up to date with current policies
and procedures. The method of delivery may also
vary to suit the particular audience or training being
delivered. For example, initial and annual training
may be delivered via a formal hands-on or
computer-based training session, while ongoing
periodic updates may be delivered via e-mails,
 processes, while training for retail cashiers may
focus on secure transaction procedures

Consider including ongoing awareness updates to

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

12.6.2 Require personnel to acknowledge at least Requiring an acknowledgement by personnel in

annually that they have read and understood the writing or electronically helps ensure that they have
security policy and procedures. read and understood the security
policies/procedures, and that they have made and
will continue to make a commitment to comply with
these policies.

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

To be effective, the level of background checking

should be appropriate for the particular position.
For example, positions requiring greater
responsibility or that have administrative access to
critical data or systems may warrant more detailed
background checks than positions with less
responsibility and access. It may also be appropriate
for the process to cover internal transfers, where
personnel in lower risk positions, and who have not
already undergone a detailed background check,
are promoted or transferred to positions of greater
responsibility or access.
12.8 Maintain and implement policies and If a merchant or service provider shares cardholder
procedures to manage service providers, to include data with a service provider, then certain
the following: requirements apply to ensure continued protection
of this data will be enforced by such service
providers.

12.8.1 Maintain a list of service providers. Keeping track of all service providers identifies
where potential risk extends to outside of the
organization.

 The acknowledgement of the service providers

12.8.2 Maintain a written agreement that evidences their commitment to maintaining proper
includes an acknowledgement that the service security of cardholder data that it obtains from its
providers are responsible for the security of clients, and thus holds them accountable.
cardholder data the service providers possess or
otherwise store, process or transmit on behalf of
the customer, or to the extent that they could
impact the security of the customer’s cardholder
data environment.
12.8.3 Ensure there is an established process for The process ensures that any engagement of a
engaging service providers including proper due service provider is thoroughly vetted internally by
diligence prior to engagement. an organization, which should include a risk analysis
prior to establishing a formal relationship with the
service provider.

12.8.4 Maintain a program to monitor service Knowing your service providers’ PCI DSS compliance
providers’ PCI DSS compliance status at least status provides assurance that they comply with the
annually. same requirements that your organization is subject
to.
If the service provider offers a variety of services,
this requirement applies only to those services
12.8.5 Maintain information about which PCI DSS actually delivered to the client, and only those
requirements are managed by each service services in scope for the client’s PCI DSS
provider, and which are managed by the entity. assessment. For example, if a provider offers
firewall/IDS and ISP services, a client who utilizes
only the firewall/IDS service would only include that
service in the scope of their PCI DSS assessment.
12.9 Additional requirement for service providers: This requirement applies when the entity being
Service providers acknowledge in writing to assessed is a service provider. In conjunction with
customers that they are responsible for the security Requirement 12.8.2, this requirement is intended to
of cardholder data the service provider possesses or promote a consistent level of understanding
otherwise stores, processes, or transmits on behalf between service providers and their customers
of the customer, or to the extent that they could about their applicable PCI DSS responsibilities. The
impact the security of the customer’s cardholder acknowledgement of the service providers
data environment. evidences their commitment to maintaining proper
security of cardholder data that it obtains from its
clients.
The method by which the service provider provides
written acknowledgment should be agreed between
the provider and their customers.

12.10 Implement an incident response plan. Be Without a thorough security incident response plan
prepared to respond immediately to a system that is properly disseminated, read, and understood
breach. by the parties responsible, confusion and lack of a
unified response could create further downtime for
the business, unnecessary public media exposure,
as well as new legal liabilities.
12.10.1 Create the incident response plan to be The incident response plan should be thorough and
implemented in the event of system breach. contain all the key elements to allow your company
Ensure the plan addresses the following, at a to respond effectively in the event of a breach that
minimum: could impact cardholder data.

- Roles, responsibilities, and communication and

contact strategies in the event of a compromise
including notification of the payment brands, at a
minimum
- Specific incident response procedures
- Business recovery and continuity procedures
- Data back-up processes
- 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.10.2 Test the plan at least annually. Without proper testing, key steps may be missed
which could result in increased exposure during an
incident.
If within the last year the incident response plan
was activated in its entirety, covering all
components of the plan, a detailed review of the
actual incident and its response may be sufficient to
12.10.3 Designate specific personnel to be Without proper testing, key steps may be missed
available on a 24/7 basis to respond to alerts. which could result in increased exposure during an
incident.
If within the last year the incident response plan
was activated in its entirety, covering all
components of the plan, a detailed review of the
actual incident and its response may be sufficient to
provide a suitable test. If only some components of
the plan were recently activated, the remaining
components would still need to be tested. If no
components of the plan were activated in the last
12 months, the annual test would need to
encompass all components of the plan.

12.10.4 Provide appropriate training to staff with

security breach response responsibilities.

12.10.5 Include alerts from intrusion- detection, These monitoring systems are designed to focus on
intrusion-prevention, and file- integrity potential risk to data, are critical in taking quick
monitoring systems. action to prevent a breach, and must be included in
the incident-response processes.
12.10.6 Develop a process to modify and evolve Incorporating “lessons learned” into the incident
the incident response plan according to lessons response plan after an incident helps keep the plan
learned and to incorporate industry current and able to react to emerging threats and
developments. security trends.
 Go to requirement 1 Executive Summary

t is expected of them. All personnel should be aware of the sensitivity of data and their responsibilities for protecting it. For the purposes of Require

Major Observations from the 2014 Verizon PCI Compliance Report:

urity policy and procedures clearly define information security responsibilities for all personnel] easiest to comply with — 83.2% of organizations fu
f 12.7 [Screen potential personnel prior to hire to minimize the risk of attacks from internal sources] and 12.5 [Assign to an individual or team the f
Only 53.5% of organizations complied. with 12.1.2.b [Perform and document risk assessments at least annually.
ff with security responsibilities]. Clearly, once the initial policy-setting activities are done, organizations are failing to translate compliance effort into

SANS Testing Procedure

Top 20 Critical
Security Controls
NC 12.1 Examine the information security policy and verify that the policy is published
and disseminated to all relevant personnel (including vendors and business partners).

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

NC 12.2.a Verify that an annual risk assessment process is documented that identifies
threats, vulnerabilities, and results in a formal risk assessment.
 12.2.b Review risk assessment documentation to verify that the risk assessment
process is performed at least annually.

NC 12.3 Examine the usage policies for critical technologies and interview responsible
personnel to verify the following policies are implemented and followed:

NC 12.3.1 Verify that the usage policies require explicit approval from authorized parties
to use the technologies.

NC 12.3.2 Verify that the usage policies require that all technology use be authenticated
with user ID and password or other authentication item (for example, token).
NC 12.3.3 Verify that the usage policies require a list of all devices and personnel
authorized to use the devices.

NC 12.3.4 Verify that the usage policies define a method to accurately and readily
determine owner, contact information, and purpose (for example, labeling, coding,
and/or inventorying of devices).

NC 12.3.5 Verify that the usage policies require acceptable uses for the technology.

NC 12.3.6 Verify that the usage policies require acceptable network locations for the
technology.

NC 12.3.7 Verify that the usage policies require a list of company- approved products.

NC 12.3.8 Verify that the usage policies require automatic disconnect of sessions for
remote-access technologies after a specific period of inactivity.

12.3.8.b Examine configurations for remote access technologies to verify that remote
access sessions will be automatically disconnected after a specific period of inactivity.
NC 12.3.9 Verify that the usage policies require activation of remote- access technologies
used by vendors and business partners only when needed by vendors and business
partners, with immediate deactivation after use.

NC 12.3.10.a Verify that the usage policies prohibit copying, moving, or storing of
cardholder data onto local hard drives and removable electronic media when
accessing such data via remote-access technologies.

12.3.10.b For personnel with proper authorization, verify that usage policies require
the protection of cardholder data in accordance with PCI DSS Requirements.

NC 12.4.a Verify that information security policy and procedures clearly define
information security responsibilities for all personnel.

12.4.b Interview a sample of responsible personnel to verify they understand the

security policies.

NC 12.5 Verify the formal assignment of information security to a Chief Security Officer or
other security-knowledgeable member of management.
Obtain and examine information security policies and procedures to verify that the
following information security responsibilities are specifically and formally assigned:

NC 12.5.1 Verify that responsibility for creating and distributing security policies and
procedures is formally assigned.
 NC 12.5.2 Verify that responsibility for monitoring and analyzing security alerts and
distributing information to appropriate information security and business unit
management personnel is formally assigned.

C18.1 12.5.3 Verify that responsibility for creating and distributing security incident response
and escalation procedures is formally assigned.

NC 12.5.4 Verify that responsibility for administering user account and authentication
management is formally assigned.

NC 12.5.5 Verify that responsibility for monitoring and controlling all access to data is
formally assigned.

C9.1 12.6.a Verify the existence of a formal security awareness program for all personnel.
C9.2

12.6.b Obtain and examine security awareness program procedures and

documentation and perform the following:

NC 12.6.1.a Verify that the security awareness program provides multiple methods of
communicating awareness and educating personnel (for example, posters, letters,
memos, web based training, meetings, and promotions).

NC 12.6.1.b Verify that personnel attend awareness training upon hire and at least
annually.
 12.6.1.c Interview a sample of personnel to verify they have completed awareness
training and are aware of the importance of cardholder data security.

NC 12.6.2 Verify that the security awareness program requires personnel to acknowledge,
in writing or electronically, at least annually that they have read and understand the
information security policy.

NC 12.7 Inquire with Human Resource department management and verify that
background checks are conducted (within the constraints of local laws) on potential
personnel prior to hire who will have access to cardholder data or the cardholder data
environment.
 12.8 Through observation, review of policies and procedures, and review of
supporting documentation, verify that processes are implemented to manage service
providers with whom cardholder data is shared, or that could affect the security of
cardholder data (for example, backup tape storage facilities, managed service
providers such as web-hosting companies or security service providers, those that
receive data for fraud modeling purposes, etc.), as follows:

NC 12.8.1 Verify that a list of service providers is maintained.

C12.13 12.8.2 Observe written agreements and confirm they include an acknowledgement by
service providers that they are responsible for the security of cardholder data the
service providers possess or otherwise store, process or transmit on behalf of the
customer, or to the extent that they could impact the security of the customer’s
cardholder data environment.

NC 12.8.3 Verify that policies and procedures are documented and were followed
including proper due diligence prior to engaging any service provider.

NA 12.8.4 Verify that the entity maintains a program to monitor its service providers’ PCI
DSS compliance status at least annually.

12.8.5 Verify the entity maintains information about which PCI DSS requirements are
managed by each service provider, and which are managed by the entity.
 12.9 Additional testing procedure for service providers: Review service provider’s
policies and procedures and observe written agreement templates to confirm the
service provider acknowledges in writing to customers that the service provider will
maintain all applicable PCI DSS requirements to the extent the service provider
handles, has access to, or otherwise stores, processes or transmits the customer’s
cardholder data or sensitive authentication data, or manages the customer's
cardholder data environment on behalf of a customer.

C18.1 12.10 Examine the incident response plan and related procedures to verify entity is
prepared to respond immediately to a system breach by performing the following:
C18.2 12.10.1.a Verify that the incident response plan includes:
C18.4
- Roles, responsibilities, and communication strategies in the event of a compromise
including notification of the payment brands, at a minimum:
- 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

12.10.1.b Interview personnel and review documentation from a sample of

previously reported incidents or alerts to verify that the documented incident
response plan and procedures were followed.

C18.2 12.10.2 Verify that the plan is tested at least annually.

 NC 12.10.3 Verify through observation and review of policies, that designated personnel
are available for 24/7 incident response and monitoring coverage for any evidence of
unauthorized activity, detection of unauthorized wireless access points, critical IDS
alerts, and/or reports of unauthorized critical system or content file changes.

C18.5 12.10.4 Verify through observation and review of policies that staff with
C18.6 responsibilities for security breach response are periodically trained.

NC 12.1.5 Verify through observation and review of processes that monitoring and
responding to alerts from security systems including detection of unauthorized
wireless access points are covered in the Incident Response Plan.
NC 12.10.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.
ting it. For the purposes of Requirement 12, “personnel” refers to full-time and part-time employees, temporary employees, contractors and consu

with — 83.2% of organizations fulfilled all the subcontrols.

sign to an individual or team the following information security management responsibilities].
ly.
to translate compliance effort into business-as-usual activities such as training.

Selected Merchant Ty

Validation Instructions for QSA/ISA Priority A

(For In-place requirements)

Identify the documented information security policy examined. 6 0
<Report Findings Here>

Describe how the information security policy was examined to verify that it is
published and disseminated to:

All relevant personnel.

<Report Findings Here>

All relevant vendors and business partners.

<Report Findings Here>

Identify the document reviewed to verify that the information security policy is 6 0
reviewed at least annually and updated as needed to reflect changes to business
objectives or the risk environment.
<Report Findings Here>

Describe how the information security policy was verified to be:

Reviewed at least annually.

<Report Findings Here>

Updated as needed to reflect changes to business objectives or the risk environment.

<Report Findings Here>

Describe how it was verified that an annual risk process is documented and: 1 0
Identifies assets, threats and vulnerabilities.

Results in formal risk assessment.

Identify the risk assessment result documentation reviewed to verify that: 1 0
The risk assessment process is performed at least annually.
The risk assessment is performed upon significant changes to the environment.
The documented risk assessment process was followed.
<Report Findings Here>

Identify critical technologies in use. 6 0

<Report Findings Here>

Identify the usage policies for all identified critical technologies reviewed to verify the
following policies (12.3.1-12.3.10) are defined:
Explicit approval from authorized parties to use the technologies.
All technology use to be authenticated with user ID and password or other
authentication item.
A list of all devices and personnel authorized to use the devices.
A method to accurately and readily determine owner, contact information, and
purpose.
Acceptable uses for the technology.
Acceptable network locations for the
technology.
A list of company-approved products.
Automatic disconnect of sessions for remote-access technologies after a specific
period of inactivity.
Activation of remote-access technologies used by vendors and business partners only
when needed by vendors and business partners, with immediate deactivation after
use.
Prohibit copying, moving, or storing of cardholder data onto local hard drives and
removable electronic media when accessing such data via remote-access technologies.
<Report Findings Here>

Identify the responsible personnel interviewed who confirm usage policies for all
identified critical technologies are implemented and followed (for 12.3.1–12.3.10): see
above.
<Report Findings Here>

Provide the name of the assessor who attests that the usage policies were verified to 6 0
include processes for explicit approval from authorized parties to use the
technologies.
<Report Findings Here>

Provide the name of the assessor who attests that the usage policies were verified to 6 0
include processes s for all technology used to be authenticated with user ID and
password or other authentication item.
<Report Findings Here>
Provide the name of the assessor who attests that the usage policies were verified to 6 0
include processes define a list of all devices and personnel authorized to use the
devices.
<Report Findings Here>

Provide the name of the assessor who attests that the usage policies were verified to 6 0
define a method to accurately and readily determine:
Owner
Contact Information
Purpose
<Report Findings Here>

Provide the name of the assessor who attests that the usage policies were verified to 6 0
define acceptable uses for the technology.
<Report Findings Here>

Provide the name of the assessor who attests that the usage policies were verified to 6 0
define acceptable network locations for the technology.
<Report Findings Here>

Provide the name of the assessor who attests that the usage policies were verified to 6 0
include a list of company-approved products.
<Report Findings Here>

Provide the name of the assessor who attests that the usage policies were verified to 6 0
require automatic disconnect of sessions for remote- access technologies after a
specific period of inactivity.
<Report Findings Here>

Describe how configurations for remote access technologies were examined to verify 6 0
that remote access sessions will be automatically disconnected after a specific period
of inactivity.
<Report Findings Here>

Identify any remote access technologies in use.

<Report Findings Here>

Identify the period of inactivity specified.

<Report Findings Here>
Provide the name of the assessor who attests that the usage policies were verified to 6 0
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.
<Report Findings Here>

Provide the name of the assessor who attests that the usage policies were verified to 6 0
prohibit copying, moving or storing of cardholder data onto local hard drives and
removable electronic media when accessing such data via remote- access
technologies.
<Report Findings Here>

Provide the name of the assessor who attests that the usage policies were verified to 6 0
require, for personnel with proper authorization, the protection of cardholder data in
accordance with PCI DSS Requirements.
<Report Findings Here>

Identify the information security policy and procedures reviewed to verify that they 6 0
clearly define information security responsibilities for all personnel.
<Report Findings Here>

Identify the responsible personnel interviewed for this testing procedure who confirm 6 0
they understand the security policy.
<Report Findings Here>

dentify the information security policies reviewed to verify the specific and formal 6 0
assignment of the following (including 12.5.1- 12.5.5):
Information security to a Chief Security Officer or other security-knowledgeable
member of management.
Responsibility for establishing, documenting and distributing security policies and
procedures.
Monitoring and analyzing security alerts and distributing information to appropriate
information security and business unit management personnel.
Establishing, documenting, and distributing security incident response and escalation
procedures.
Administering user account and authentication management.
Monitoring and controlling all access to data.
<Report Findings Here>

Provide the name of the assessor who attests that responsibilities were verified to be 6 0
formally assigned for:
Establishing security policies and procedures.
Documenting security policies and procedures.
Distributing security policies and procedures.
<Report Findings Here>
Provide the name of the assessor who attests that responsibilities were verified to be 6 0
formally assigned for:
Monitoring and analyzing security alerts.
Distributing information to appropriate information security and business unit
management personnel.
<Report Findings Here>

Provide the name of the assessor who attests that responsibilities were verified to be 0
formally assigned for:
Establishing security incident response and escalation procedures.
Documenting security incident response and escalation procedures.
Distributing security incident response and escalation procedures. 4
<Report Findings Here>

Provide the name of the assessor who attests that responsibilities were verified to be 6 0
formally assigned for administering user account and authentication management.
<Report Findings Here>

Provide the name of the assessor who attests that responsibilities were verified to be 6 0
formally assigned for:
Monitoring all access to data
Controlling all access to data
<Report Findings Here>

Identify the documented security awareness program reviewed to verify it provides 6 0

awareness to all personnel about the importance of cardholder data security.
<Report Findings Here>

Identify the documented security awareness program procedures and additional 6 0

documentation examined to verify that:
The security awareness program provides multiple methods of communicating
awareness and educating personnel.
Personnel attend security awareness training:
- Upon hire
- At least annually
Personnel acknowledge, in writing or electronically and at least annually, that they
have read and understand the information security policy.
<Report Findings Here>

Describe how the security awareness program provides multiple methods of 6 0

communicating awareness and educating personnel.
<Report Findings Here>

Describe how it was observed that all personnel attend security awareness training: 6 0
Upon hire
<Report Findings Here>

At least annually
<Report Findings Here>
Identifythesampleofpersonnelinterviewed who confirm they have completed security 6 0
awareness training.
<Report Findings Here>

For the interview, summarize details of the interview that verify their awareness of
the importance of cardholder data security.
<Report Findings Here>

Describe how it was verified that, per the security awareness program, all personnel: 6 0
Acknowledge that they have read and understand the information security policy
(including whether this is in writing or electronic).
<Report Findings Here>

Provide an acknowledgement at least annually

<Report Findings Here>

Identify the documented policy reviewed to verify requirement for background checks 6 0
to be conducted:
On potential personnel who will have access to cardholder data or the cardholder data
environment.
Prior to hiring the personnel.
<Report Findings Here>

Identify the Human Resources personnel interviewed who confirm background checks
are conducted:
On potential personnel who will have access to cardholder data or the cardholder data
environment.
Prior to hiring the personnel.
<Report Findings Here>
Describe how it was verified that background checks are conducted (within the
constraints of local laws):
<Report Findings Here>

On potential personnel who will have access to cardholder data or the cardholder data
environment.
<Report Findings Here>

Prior to hiring the personnel.

<Report Findings Here>
Identify the documented policies and procedures to manage service providers with 1
whom cardholder data is shared, or that could affect the security of cardholder data,
reviewed to verify policy defines the following from 12.8.1–12.8.5:
Maintain a list of service providers.
Maintain a written agreement that includes an acknowledgement that the service
providers will maintain all applicable PCI DSS requirements to the extent the service
provider handles, has access to, or otherwise stores, processes, or transmits the
customer’s cardholder data or sensitive authentication data, or manages the
customer's cardholder data environment on behalf of a customer.
Ensure there is an established process for engaging service providers including proper
due diligence prior to engagement.
Maintain a program to monitor service providers’ PCI DSS compliance status at least 2
annually.
Maintain information about which PCI DSS requirements are managed by each service
provider, and which are managed by the entity.
<Report Findings Here>

Describe how the documented list of service providers was observed to be maintained 1
(kept up-to-date).
<Report Findings Here> 2

Describe how written agreements for each service provider were observed to confirm 1
they include an acknowledgement by service providers that they will maintain all
applicable PCI DSS requirements to the extent the service provider handles, has access
to, or otherwise stores, processes, or transmits the customer’s cardholder data or
sensitive authentication data, or manages the customer's cardholder data 2
environment on behalf of a customer.
<Report Findings Here>

Describe how it was verified that the procedures for proper due diligence prior to 1
engaging a service provider are implemented, as documented in the policies and
procedures at 12.8.
<Report Findings Here>
2

Describe how it was verified that the entity maintains a program to monitor its service 1
providers’ PCI DSS compliance status at least annually.
<Report Findings Here> 2

Describe how it was observed that the entity maintains information about which PCI 1
DSS requirements are managed by each service provider, and which are managed by
the entity.
<Report Findings Here>
2
Identify whether the assessed entity is a service provider. (yes/no) 0
If “no,” mark the remainder of 12.9 as “Not Applicable.”
If “yes”:

Indicate whether this ROC is being completed prior to June 30, 2015. (yes/no)
<Report Findings Here>
If “yes” AND the assessed entity does not have this in place ahead of the
requirement’s effective date, mark the remainder of 12.9 as “Not Applicable.”
If “no” OR if the assessed entity has this in place ahead of the requirement’s effective
date:
<Report Findings Here>

Identify the service provider’s policies and procedures reviewed to verify that the
service provider acknowledges in writing to customers that the service provider will
maintain all applicable PCI DSS requirements to the extent the service provider
handles, has access to, or otherwise stores, processes, or transmits the customer’s
cardholder data or sensitive authentication data, or manages the customer's
cardholder data environment on behalf of a customer. 2
<Report Findings Here>

Describe how written agreement templates were observed to verify that the service
provider acknowledges in writing to customers that the service provider will maintain
all applicable PCI DSS requirements to the extent the service provider handles, has
access to, or otherwise stores, processes, or transmits the customer’s cardholder data
or sensitive authentication data, or manages the customer's cardholder data
environment on behalf of a customer.
<Report Findings Here>

Identify the documented incident response plan and related procedures examined to 0
verify the entity is prepared to respond immediately to a system breach, with defined
processes as follows from 12.10.1–12.10.6:
Create the incident response plan to be implemented in the event of system breach.
Test the plan at least annually.
Designate specific personnel to be available on a 24/7 basis to respond to alerts:
- 24/7incidentmonitoring
- 24/7incidentresponse
Provide appropriate training to staff with security breach response responsibilities.
Include alerts from security monitoring systems, including but not limited to intrusion- 4
detection, intrusion-prevention, firewalls, and file-integrity monitoring systems.
Develop a process to modify and evolve the incident response plan according to
lessons learned and to incorporate industry developments.
<Report Findings Here>
Provide the name of the assessor who attests that the incident response plan was 0
verified to include:
Roles and responsibilities.
Communication strategies.
Requirement for notification of the payment brands.
Specific incident response procedures.
Business recovery and continuity
procedures.
Data back-up processes.
Analysis of legal requirements for reporting compromises. 4
Coverage for all critical system components.
Responses for all critical system components.
Reference or inclusion of incident response procedures from the payment brands.
<Report Findings Here>

Identify the sample of personnel interviewed who confirm that the documented 0
incident response plan and procedures are followed.
<Report Findings Here>

Identify the sample of previously reported incidents or alerts reviewed for this testing
procedure.
<Report Findings Here>

For each item in the sample, describe how documentation was reviewed to confirm 4
that the documented incident response plan and procedures are followed.
<Report Findings Here>

Describe how it was observed that the incident response plan is tested at least 0
annually.
<Report Findings Here> 4
Identify the document requiring 24/7 incident response and monitoring coverage for: 0
Any evidence of unauthorized activity.
Detection of unauthorized wireless access
points.
Critical IDS alerts.
Reports of unauthorized critical system or content file changes.
<Report Findings Here>
Identify the sample of responsible personnel interviewed who confirm 24/7 incident
response and monitoring coverage for:
Any evidence of unauthorized activity.
Detection of unauthorized wireless access
points.
Critical IDS alerts.
Reports of unauthorized critical system or content file changes.
<Report Findings Here>

Describe how it was observed that designated personnel are available for 24/7
incident response and monitoring coverage
<Report Findings Here>
4
Any evidence of unauthorized activity.
<Report Findings Here>

Detection of unauthorized wireless access points.

<Report Findings Here>

Critical IDS alerts.

<Report Findings Here>

Reports of unauthorized critical system or content file changes.

<Report Findings Here>

Identify the sample of responsible personnel interviewed who confirm that staff with 0
responsibilities for security breach response are periodically trained.
<Report Findings Here>

Identify the documented policy reviewed that defines that staff with responsibilities
for security breach response are periodically trained. 4
<Report Findings Here>

Describe how it was observed that staff with responsibilities for security breach
response are periodically trained.
<Report Findings Here>
Describe how processes were reviewed to verify that monitoring alerts from security 0
monitoring systems, including detection of unauthorized wireless access points, are
covered in the Incident Response Plan.
<Report Findings Here>

Describe how processes were reviewed to verify that responding to alerts from
security monitoring systems, including detection of unauthorized wireless access
points, are covered in the Incident Response Plan. 4
<Report Findings Here>
Identify the documented policy reviewed to verify that processes are defined to 0
modify and evolve the incident response plan:
According to lessons learned.
To incorporate industry developments.
<Report Findings Here>

Identify the sample of responsible personnel interviewed who confirm that processes
are implemented to modify and evolve the incident response plan:
According to lessons learned.
To incorporate industry developments.
<Report Findings Here>

Describe how it was observed that processes are implemented to modify and evolve
the incident response plan:
<Report Findings Here>
4
According to lessons learned.
<Report Findings Here>

To incorporate industry developments.

<Report Findings Here>

226 6
oyees, contractors and consultants who are “resident” on the entity’s site or otherwise have access to the cardholder data environment.

cted Merchant Type D

A-EP PE2P B B-IP C-VT C D S In Place? Severity Proofs /

Documentation links

1 1 1 1 1 1 1 1

N 1

1 1 1 1 1 1 1 1

N 1

0 0 0 0 0 0 1 1

N 6
0 0 0 0 0 0 1 1

N 6

0 0 0 1 0 0 1 1

N 1

0 0 1 0 1 1 1 1

N 1

0 0 0 0 0 1 1 1

N 1
0 0 1 1 1 1 1 1

N 1

0 0 0 0 0 0 1 1

N 1

0 0 1 1 1 1 1 1

N 1

0 0 0 0 0 1 1 1

N 1

0 0 0 0 0 0 1 1
N 1

0 0 0 0 0 1 1 1

N 1

0 0 0 0 0 1 1 1

C 0
0 0 0 1 0 1 1 1

N 1

0 0 0 0 0 0 1 1

N 1

0 0 0 0 0 0 1 1

N 1

1 1 1 1 1 1 1 1

N 1

1 1 1 1 1 1 1 1
NT 1

1 1 1 1 1 1 1 1

N 1

0 0 0 0 0 0 1 1

N 1
0 0 0 0 0 0 1 1

N 1

0 1 1 1 1 1 1 1

N 3

1 0 0 0 0 0 1 1

N 1

0 0 0 0 0 0 1 1

N 1

1 1 1 1 1 1 1 1
N 1

1 1 0 1 0 0 1 1

N 1

0 1 0 0 0 0 1 1
N 1

0 1 0 0 0 0 1 1

N 1
0 1 0 0 0 0 1 1

Y 0

0 0 0 0 0 0 1 1

N 1

0 0 0 0 0 0 1 1

N 1
1 0 1 1 1 1 1 1

N 5

1 1 1 1 1 1 1 1
N 5

1 1 1 1 1 1 1 1

N 5

1 1 1 1 1 1 1 1

N 5

1 1 1 1 1 1 1 1
N 5

1 1 0 1 0 1 1 1

Y 0
0 0 0 0 0 0 0 1

Y 0

0 0 0 0 0 0 1 1

N 3
1 1 0 1 0 1 1 1

N 3

1 0 0 1 0 1 1 1

N 3

0 0 0 0 0 0 1 1
N 3
0 0 0 0 0 0 1 1

N 3

0 0 0 0 0 0 1 1

N 3

0 0 0 0 0 0 1 1

N 3
0 0 0 0 0 0 1 1

Y 0

16 17 15 20 15 23 46 47 Y 88
N
C
NT
NA
er data environment.

Stage of implementation Remediation plan

Estimated date for completion Comments Owner
IT Types
Server
Firewall & Router
Switches
Mail
DNS
Database
Application
Web application
Web server
WAP
POS
Others

Criticality
High
Medium
Low