Complete Roc

Payment Card Industry Data Security Standard v3.
Presented to: My Parent for CM, LLC.
BID: 123-456-7890
Date: November 06, 2015
Prepared by: Jodi QSA 1.1
CONFIDENTIAL INFORMATION
This document is the property of My Parent for CM, LLC.; it contains information that
is proprietary, confidential, or otherwise restricted from disclosure. If you are not an
authorized recipient, please return this document to the above-named owner.
Dissemination, distribution, copying, or use of this document in whole or in part by
anyone other than the intended recipient is strictly prohibited without prior written
permission of Trustwave and My Parent for CM, LLC..
Copyright © 2015 Trustwave. All Rights Reserved.
CONFIDENTIAL INFORMATION
Version 05052015
Payment Card Industry (PCI)

Data Security Standard
Report on Compliance
Template for Report on Compliance
for use with PCI DSS v3.1
Revision 1.0
April 2015
Document Changes
Date Version Description
PCI DSS 3.0, To introduce the template for submitting Reports on Compliance.
February 2014
Revision1.0 This document is intended for use with version 3.0 of the PCI Data Security Standard.
PCI DSS 3.0, Errata - Minor edits made to address typos and general errors, slight addition of content
July 2014
Revision 1.1
Revision to align with changes from PCI DSS 3.0 to PCI DSS 3.1 (see PCI DSS – Summary of
PCI DSS 3.1, Changes from PCI DSS Version 3.0 to 3.1 for details of those changes). Also includes minor edits
April 2015
Revision1.0 made for clarification and/or format.
PCI DSS Template for Report on Compliance for use with PCI DSS v3.1, Revision 1.0 April 2015
© 2015 PCI Security Standards Council, LLC. All Rights Reserved. Page i
Table of Contents
Document Changes.................................................................................................................................................................................................... i
Introduction to the ROC Template............................................................................................................................................................................ 1
ROC Template for PCI Data Security Standard v3.1............................................................................................................................................... 8
1. Contact Information and Report Date........................................................................................................................................................ 8
1.1 Contact information....................................................................................................................................................................................... 8
1.2 Date and timeframe of assessment............................................................................................................................................................... 9
1.3 PCI DSS version........................................................................................................................................................................................... 9
1.4 Additional services provided by QSA company............................................................................................................................................. 9
2. Summary Overview................................................................................................................................................................................... 10
2.1 Description of the entity’s payment card business....................................................................................................................................... 10
2.2 High-level network diagram(s)..................................................................................................................................................................... 10
3. Description of Scope of Work and Approach Taken.............................................................................................................................. 11
3.1 Assessor’s validation of defined cardholder data environment and scope accuracy...................................................................................11
3.2 Cardholder Data Environment (CDE) overview........................................................................................................................................... 11
3.3 Network segmentation................................................................................................................................................................................. 12
3.4 Network segment details............................................................................................................................................................................. 13
3.5 Connected entities for processing............................................................................................................................................................... 14
3.6 Other business entities that require compliance with the PCI DSS............................................................................................................. 14
3.7 Wireless summary....................................................................................................................................................................................... 15
3.8 Wireless details........................................................................................................................................................................................... 15
4. Details about Reviewed Environment...................................................................................................................................................... 16
4.1 Detailed network diagram(s)........................................................................................................................................................................ 16
4.2 Description of cardholder data flows........................................................................................................................................................... 16
4.3 Cardholder data storage.............................................................................................................................................................................. 17
4.4 Critical hardware in use in the cardholder data environment....................................................................................................................... 17
4.5 Critical software in use in the cardholder data environment........................................................................................................................ 17
4.6 Sampling ................................................................................................................................................................................................. 18
4.7 Sample sets for reporting............................................................................................................................................................................ 19
4.8 Service providers and other third parties with which the entity shares cardholder data..............................................................................19
4.9 Third-party payment applications/solutions................................................................................................................................................. 20
4.10 Documentation reviewed............................................................................................................................................................................. 21
4.11 Individuals interviewed................................................................................................................................................................................ 21
4.12 Managed service providers......................................................................................................................................................................... 22
4.13 Disclosure summary for “In Place with Compensating Control” responses................................................................................................. 22
4.14 Disclosure summary for “Not Tested” responses........................................................................................................................................ 23
5. Quarterly Scan Results............................................................................................................................................................................. 24
5.1 Quarterly scan results – initial PCI DSS compliance validation................................................................................................................... 24
© 2015 PCI Security Standards Council, LLC. All Rights Reserved. Page
5.2 Quarterly scan results – all other PCI DSS compliance validation............................................................................................................... 25
5.3 Attestations of scan compliance.................................................................................................................................................................. 25
6. Findings and Observations...................................................................................................................................................................... 26
Build and Maintain a Secure Network and Systems........................................................................................................................................... 26
Requirement 1: Install and maintain a firewall configuration to protect cardholder data....................................................................................26
Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters....................................................37
Protect Stored Cardholder Data........................................................................................................................................................................... 51
Requirement 3: Protect stored cardholder data................................................................................................................................................. 51
Requirement 4: Encrypt transmission of cardholder data across open, public networks...................................................................................68
Maintain a Vulnerability Management Program.................................................................................................................................................. 74
Requirement 5: Protect all systems against malware and regularly update anti-virus software or programs....................................................74
Requirement 6: Develop and maintain secure systems and applications.......................................................................................................... 78
Implement Strong Access Control Measures..................................................................................................................................................... 98
Requirement 7: Restrict access to cardholder data by business need to know................................................................................................. 98
Requirement 8: Identify and authenticate access to system components....................................................................................................... 102
Requirement 9: Restrict physical access to cardholder data........................................................................................................................... 118
Regularly Monitor and Test Networks............................................................................................................................................................... 132
Requirement 10: Track and monitor all access to network resources and cardholder data...............................................................................132
Requirement 11: Regularly test security systems and processes...................................................................................................................... 147
Maintain an Information Security Policy............................................................................................................................................................ 162
Requirement 12: Maintain a policy that addresses information security for all personnel..................................................................................162
Appendix A: Additional PCI DSS Requirements for Shared Hosting Providers...........................................................................................162
Appendix B: Compensating Controls............................................................................................................................................................... 162
Appendix C: Compensating Controls Worksheet............................................................................................................................................ 162
Appendix D: Segmentation and Sampling of Business Facilities/System Components.............................................................................162
© 2015 PCI Security Standards Council, LLC. All Rights Reserved. Page
Introduction to the ROC Template
This document, the PCI DSS Template for Report on Compliance for use with PCI DSS v3.1, Revision 1.0 (“ROC Reporting Template”), is the mandatory
template for Qualified Security Assessors (QSAs) completing a Report on Compliance (ROC) for assessments against the PCI DSS Requirements and
Security Assessment Procedures v3.1. The ROC Reporting Template provides reporting instructions and the template for QSAs to use. This can help
provide reasonable assurance that a consistent level of reporting is present among assessors.
Use of this Reporting Template is mandatory for all v3.1 submissions.
Tables have been included in this template to facilitate the reporting process for certain lists and other information as appropriate. The tables in this
template may be modified to increase/decrease the number of rows, or to change column width. Additional appendices may be added if the assessor
feels there is relevant information to be included that is not addressed in the current format. However, the assessor must not remove any details from the
tables provided in this document. Personalization, such as the addition of company logos, is acceptable.
Do not delete any content from any place in this document, including this section and the versioning above. These instructions are important
for the assessor as the report is written and for the recipient in understanding the context the responses and conclusions are made. Addition
of text or sections is applicable within reason, as noted above. Refer to the “Frequently Asked Questions for use with ROC Reporting
Template for PCI DSS v3.x” document on the PCI SSC website for further guidance.
The Report on Compliance (ROC) is produced during onsite PCI DSS assessments as part of an entity’s validation process. The ROC provides details
about the entity’s environment and assessment methodology, and documents the entity’s compliance status for each PCI DSS Requirement. A PCI DSS
compliance assessment involves thorough testing and assessment activities, from which the assessor will generate detailed work papers. These work
papers contain comprehensive records of the assessment activities, including observations, results of system testing, configuration data, file lists,
interview notes, documentation excerpts, references, screenshots, and other evidence collected during the course of the assessment. The ROC is
effectively a summary of evidence derived from the assessor’s work papers to describe how the assessor performed the validation activities and how
the resultant findings were reached. At a high level, the ROC provides a comprehensive summary of testing activities performed and information
collected during the assessment against the PCI DSS Requirements and Security Assessment Procedures v3.1. The information contained in a ROC
must provide enough detail and coverage to verify that the assessed entity is compliant with all PCI DSS requirements.
ROC Sections
The ROC includes the following sections and appendices:
 Section 1: Contact Information and Report Date
 Section 2: Summary Overview
 Section 3: Description of Scope of Work and Approach Taken
 Section 4: Details about Reviewed Environment
 Section 5: Quarterly Scan Results
 Section 6: Findings and Observations
© 2015 PCI Security Standards Council, LLC. All Rights Reserved. Page 1
 Appendix A: Additional PCI DSS Requirements for Shared Hosting Providers
 Appendices B and C: Compensating Controls and Compensating Controls Worksheet (as applicable)
 Appendix D: Segmentation and Sampling of Business Facilities/System Components (diagram)
The first five sections must be thoroughly and accurately completed, in order for the assessment findings in Section 6 and any applicable responses in
the Appendices to have the proper context. The Reporting Template includes tables with Reporting Instructions built-in to help assessors provide all
required information throughout the document. Responses should be specific, but efficient. Details provided should focus on concise quality of detail,
rather than lengthy, repeated verbiage. Parroting the testing procedure within a description is discouraged, as it does not add any level of assurance to
the narrative. Use of template language for summaries and descriptions is discouraged and details should be specifically relevant to the assessed entity.
ROC Summary of Assessor Findings

With the Reporting Template, an effort was made to efficiently use space, and as such, there is one response column for results/evidence (“ROC
Reporting Details: Assessor’s Response”) instead of three. Additionally, the results for “Summary of Assessor Findings” were expanded to more
effectively represent the testing and results that took place, which should be aligned with the Attestation of Compliance (AOC).
There are now five results possible – In Place, In Place with CCW (Compensating Control Worksheet), Not Applicable, Not Tested, and Not in Place. At
each sub-requirement there is a place to designate the result (“Summary of Assessor Findings”), which can be checked as appropriate. See the example
format on the following page, as referenced.
The following table is a helpful representation when considering which selection to make. Remember, only one response should be selected at the sub-
requirement level, and reporting of that should be consistent with other required documents, such as the AOC.
Refer to the “Frequently Asked Questions for use with ROC Reporting Template for PCI DSS v3.x” document on the PCI SSC website for
further guidance.
RESPONSE WHEN TO USE THIS RESPONSE: USING THE SAMPLE BELOW:

In Place The expected testing has been performed, and all In the sample, the Summary of Assessment Findings at
elements of the requirement have been met as stated. 1.1 is “in place” if all report findings are in place for 1.1.a
and 1.1.b or a combination of in place and not
applicable.
In Place w/ CCW The expected testing has been performed, and the In the sample, the Summary of Assessment Findings at
(Compensating requirement has been met with the assistance of a 1.1 is “in place with CCW” if all report findings are in
Control compensating control. place for 1.1.a and 1.1.b with the use of a CCW for one
Worksheet) All responses in this column require completion of a or both (completed at the end of the report) or a
Compensating Control Worksheet (CCW) combination of in place with CCW and not applicable.
Information on the use of compensating controls and
guidance on how to complete the worksheet is provided
in the PCI DSS.
Not in Place Some or all elements of the requirement have not been In the sample, the Summary of Assessment Findings at
met, or are in the process of being implemented, or 1.1 is “not in place” if either 1.1.a or 1.1.b are concluded
require further testing before it will be known if they are to be “not in place.”
in place.
N/A The requirement does not apply to the organization’s In the sample, the Summary of Assessment Findings at
(Not Applicable) environment. 1.1 is “not applicable” if both 1.1.a and 1.1.b are
All “not applicable” responses require reporting on concluded to be “not applicable.” A requirement is
testing performed to confirm the “not applicable” status. applicable if any aspects of the requirement apply to the
Note that a “Not Applicable” response still requires a environment being assessed, and a “Not Applicable”
detailed description explaining how it was determined designation in the Summary of Assessment Findings
that the requirement does not apply. should not be used in this scenario.
Certain requirements are always applicable (3.2.1-3.2.3, **Note, future-dated requirements are considered Not
for example), and that will be designated by a grey box Applicable until the future date has passed. While it
under “Not Applicable.” is true that the requirement is likely not tested
(hence the original instructions), it is not required to
be tested until the future date has passed, and the
requirement is therefore not applicable until that
date. As such, a “Not Applicable” response to future-
dated requirements is accurate, whereas a “Not
Tested” response would imply there was not any
consideration as to whether it could apply (and be
perceived as a partial or incomplete ROC).
Once the future date has passed, responses to
those requirements should be consistent with
instructions for all requirements.
Not Tested The requirement (or any single aspect of the In the sample, the Summary of Assessment Findings at
requirement) was not included for consideration in the 1.1 is “not tested” if either 1.1.a or 1.1.b are concluded
assessment and was not tested in any way. to be “not tested.”
(See “What is the difference between ‘Not Applicable’
and ‘Not Tested’?” below for examples of when this
option should be used.)
What is the difference between “Not Applicable” and “Not Tested?”

Requirements that are deemed to be not applicable to an environment must be verified as such. Using the example of wireless and an organization that
does not use wireless technology in any capacity, an assessor could select “N/A” for Requirements 1.2.3, 2.1.1, and 4.1.1, after the assessor
confirms that there are no wireless technologies used in their CDE or that connect to their CDE via assessor testing. Once this has been confirmed,
the organization may select “N/A” for those specific requirements, and the accompanying reporting must reflect the testing performed to confirm the
not applicable status.
If a requirement is completely excluded from review without any consideration as to whether it could apply, the “Not Tested” option should be
selected. Examples of situations where this could occur may include:
 An organization may be asked by their acquirer to validate a subset of requirements—for example: using the prioritized approach to validate
certain milestones.
 An organization may wish to validate a new security control that impacts only a subset of requirements—for example, implementation of a new
encryption methodology that requires assessment of PCI DSS Requirements 2, 3, and 4.
 A service provider organization might offer a service that covers only a limited number of PCI DSS requirements—for example, a physical
storage provider may only wish to validate the physical security controls per PCI DSS Requirement 9 for their storage facility.
In these scenarios, the organization only wishes to validate certain PCI DSS requirements even though other requirements might also apply to their
environment. Compliance is determined by the brands and acquirers, and the AOCs they see will be clear in what was tested and not tested. They
will decide whether to accept a ROC with something “not tested,” and the QSA should speak with them if any exception like this is planned. This
should not change current practice, just reporting.
Requirement X: Sample
Note – checkboxes have been added to the “Summary of Assessment Findings” so that the assessor may double click to check the applicable summary
result. Hover over the box you’d like to mark and click once to mark with an ‘x.’ To remove a mark, hover over the box and click again.
Summary of Assessment Findings
(check one)
PCI DSS Requirements Reporting Details: In In Place Not Not Not in
and Testing Procedures Reporting Instruction Assessor’s Response Place with CCW Applicable Tested Place
1.1 Sample sub-requirement ☐ ☐ ☐ ☐ ☐
1.1.a Sample testing procedure Reporting Instruction <Report Findings Here>
1.1.b Sample testing procedure Reporting Instruction <Report Findings Here>
ROC Reporting Details

The reporting instructions in the Reporting Template explain the intent of the response required. There is no need to repeat the testing procedure or the
reporting instruction within each assessor response. As noted earlier, responses should be specific and relevant to the assessed entity. Details provided
should focus on concise quality of detail, rather than lengthy, repeated verbiage and should avoid parroting of the testing procedure without additional
detail or generic template language.
Assessor responses will generally fall into categories such as the following:
 One word (yes/no)
Example Reporting Instruction: Indicate whether the assessed entity is an issuer or supports issuing services. (yes/no)
 Document name or interviewee job title/reference – In Sections 4.10, “Documentation Reviewed,” and 4.11, “Individuals Interviewed” below,
there is a space for a reference number and it is the QSA’s choice to use the document name/interviewee job title or the reference number at
the individual reporting instruction response.
Example Reporting Instruction: Identify the document that defines vendor software development processes.
Example Reporting Instruction: Identify the individuals interviewed who confirm that …
 Sample description – For sampling, the QSA must use the table at “Sample sets for reporting” in the Details about Reviewed Environment
section of this document to fully report the sampling, but it is the QSA’s choice to use the Sample set reference number (“Sample Set-5”) or list
out the items from the sample again at the individual reporting instruction response.
Example Reporting Instruction: Identify the sample of removable media observed.
 Brief description/short answer – Short and to the point, but provide detail and individual content that is not simply an echoing of the testing
procedure or reporting instruction nor a template answer used from report-to-report, but instead relevant and specific to the assessed entity.
Example Reporting Instruction: Describe the procedures for secure key distribution that were observed to be implemented.
Example Reporting Instruction: For the interview, summarize the relevant details discussed that verify …
Dependence on another service provider’s compliance:

Generally, when reporting on a requirement where a third-party service provider is responsible for the tasks, an acceptable response for an “in place”
finding may be something like:
“Assessor verified this is the responsibility of Service Provider X, as verified through review of x/y contract (document). Assessor reviewed the AOC for
Service Provider X, dated MM/DD/YYYY, and confirmed the service provider was found to be PCI DSS compliant against PCI DSS v2.0 (or PCI DSS
v3.0/PCI DSS v3.1) for all applicable requirements, and that it covers the scope of the services used by the assessed entity.”
That response could vary, but what’s important is that it is noted as “in place” and that there has been a level of testing by the assessor to support the
conclusion that this responsibility is verified and that the responsible party has been tested against the requirement and found to be compliant.
Dependence on another service provider’s compliance where the service providers is compliant with PCI DSS v2.0,
but the entity is being assessed against PCI DSS v3.1:
During the implementation period for PCI DSS version 3, an entity being assessed against PCI DSS v3.1 may be relying on the compliance of third-party
service providers who are assessed as compliant against PCI DSS v2.0. This is acceptable, and there is no need to force the third-party service provider
to be assessed against PCI DSS 3.1 while their PCI DSS 2.0 assessment is still valid. How should this be documented?
In the scenario where the entity is assessing against PCI DSS 3.1, but the third-party service provider’s current compliant assessment is against PCI
DSS 2.0, two possibilities exist:
 The requirement and/or testing procedure exists in both standards, in which case the response noted above would likely be sufficient. Noting that
the service provider is compliant with 2.0 of the PCI DSS in the response is worthwhile to address any possible changes to requirements or
testing procedures. As noted above, future-dated requirements are considered Not Applicable until the future date has passed. Until that date,
an acceptable answer for the accompanying “not applicable” finding might be something like: “Not Applicable, as this is a future-dated
requirement. Assessor verified this is the responsibility of Service Provider X, as verified through review of x/y contract (document). Assessor
reviewed the AOC for Service Provider X, dated 1/12/2013, and confirmed the SP is compliant with v2.0 of the PCI DSS.”
Refer to the FAQs on the PCI SSC website at https://www.pcisecuritystandards.org/faq/ for more information.
Do’s and Don’ts: Reporting Expectations
DO: DON’T:
 Use this Reporting Template when assessing against v3.1 of the  Don’t report items in the “In Place” column unless they have been
PCI DSS. verified as being “in place” as stated.
 Complete all sections in the order specified.  Don’t include forward-looking statements or project plans in the “In
 Read and understand the intent of each Requirement and Testing Place” assessor response.
Procedure.  Don’t simply repeat or echo the Testing Procedure in the response.
 Provide a response for every Testing Procedure.  Don’t copy responses from one Testing Procedure to another.
 Provide sufficient detail and information to support the designated  Don’t copy responses from previous assessments.
finding, but be concise.  Don’t include information irrelevant to the assessment.
 Describe how a Requirement was verified per the Reporting
Instruction, not just that it was verified.
 Ensure the parts of the Testing Procedure and Reporting Instruction
are addressed.
 Ensure the response covers all applicable system components.
 Perform an internal quality assurance review of the ROC for clarity,
accuracy, and quality.
 Provide useful, meaningful diagrams, as directed.
ROC Template for PCI Data Security Standard v3.1
This template is to be used for creating a Report on Compliance. Content and format for a ROC is defined as follows:
1. Contact Information and Report Date

1.1 Contact information
Client
 Company name: My Parent for CM, LLC.
 Company address:
 Company URL:
 Company contact name:
 Contact phone number:
 Contact e-mail address:
Assessor Company
 Company name: Trustwave Holdings, Inc.
 Company address:
 Company website: https://www.trustwave.com/home/
Assessor
 Assessor name: Jodi QSA 1.1
 Assessor PCI credentials: QSA
(QSA, PA-QSA, etc.)
 Assessor phone number: +44 (0) 845 456 9611
 Assessor e-mail address: compliance-qa@trustwave.com
Assessor Quality Assurance (QA) Primary Reviewer for this specific report (not the general QA contact for the QSA)
 QA reviewer name:
 QA reviewer phone number: +1 (312) 873 7500
 QA reviewer e-mail address: compliance-qa@trustwave.com
1.2 Date and timeframe of assessment

 Date of Report:
 Timeframe of assessment (start date to completion date): Trustwave conducted both on-site and remote compliance reviews pursuant
to the PCI assessment process between 2015-09-30 and TBD. The total
duration of the assessment was .
 Identify date(s) spent onsite at the entity: 456 Elm - 2015-10-07 - 2015-10-09
 Descriptions of time spent onsite at the entity and time spent performing
remote assessment activities, including time spent on validation of
remediation activities.
1.3 PCI DSS version

 Version of the PCI Data Security Standard used for the assessment PCI DSS 3.1
(should be 3.1):
1.4 Additional services provided by QSA company

The PCI DSS Validation Requirements for QSAs v1.2, Section 2.2 “Independence” specifies requirements for QSAs around disclosure of such services
and/or offerings that could reasonably be viewed to affect independence of assessment. Complete the below after review of this portion of the Validation
Requirements, to ensure responses are consistent with documented obligations.
 Disclose all services offered to the assessed entity by the QSAC, including
but not limited to whether the assessed entity uses any security-related
devices or security-related applications that have been developed or
manufactured by the QSA, or to which the QSA owns the rights or that the
QSA has configured or manages:
 Describe efforts made to ensure no conflict of interest resulted from the
above mentioned services provided by the QSAC:
2. Summary Overview
2.1 Description of the entity’s payment card business
Provide an overview of the entity’s payment card business, including:
 Describe the nature of the entity’s business (what kind of work they do, etc.) My Parent for CM, LLC. (CMParent)
Note: This is not intended to be a cut-and-paste from the entity’s website, but
should be a tailored description that shows the assessor understands the business
of the entity being assessed.
 Describe how and why the entity stores, processes, and/or transmits cardholder
data.
Note: This is not intended to be a cut-and-paste from above, but should build on
the understanding of the business and the impact this can have upon the security
of cardholder data. website
 What types of payment channels the entity serves, such as card-present and
card-not-present (for example, mail order/telephone order (MOTO), e-
commerce).
 Any entities that the assessed entity connects to for payment transmission or
processing, including processor relationships.
2.2 High-level network diagram(s)

Provide a high-level network diagram (either obtained from the entity or created by assessor) of the entity’s networking topography, showing the
overall architecture of the environment being assessed. This high-level diagram should summarize all locations and key systems, and the boundaries
between them and should include the following:
 Connections into and out of the network including demarcation points between the cardholder data environment (CDE) and other networks/zones
 Critical components within the cardholder data environment, including POS devices, systems, databases, and web servers, as applicable
 Other necessary payment components, as applicable
Figure 1. net dia -
3. Description of Scope of Work and Approach Taken
3.1 Assessor’s validation of defined cardholder data environment and scope accuracy
Document how the assessor validated the accuracy of the defined CDE/PCI DSS scope for the assessment, including:
As noted in PCI DSS, v3.1 – “At least annually and prior to the annual assessment, the assessed entity should confirm the accuracy of their PCI DSS scope by
identifying all locations and flows of cardholder data, and identify all systems that are connected to or if compromised could impact the CDE (e.g. authentication
servers) to ensure they are included in the PCI DSS scope.”
Note – additional reporting has been added below to emphasize systems that are connected to or if compromised could impact the CDE.
 Describe the methods or processes (for example, tools, observations,
feedback, scans, data flow analysis) used to identify and document all
existences of cardholder data (as executed by the assessor, assessed entity
or a combination):
 Describe the methods or processes (for example, tools, observations,
feedback, scans, data flow analysis) used to verify that no cardholder data
exists outside of the defined CDE (as executed by the assessor, assessed
entity or a combination):
 Describe how the results of the methods/processes were evaluated by the
assessor to verify that the PCI DSS scope of review is appropriate:
 Describe how the results of the methods/processes were documented (for
example, the results may be a diagram or an inventory of cardholder data
locations):
 Describe why the methods (for example, tools, observations, feedback, scans,
data flow analysis) used for scope verification are considered by the assessor
to be effective and accurate:
 Provide the name of the assessor who attests that the defined CDE and
scope of the assessment has been verified to be accurate, to the best of the
assessor’s ability and with all due diligence:
3.2 Cardholder Data Environment (CDE) overview

Provide an overview of the cardholder data environment encompassing the people, processes, technologies, and locations (for example, client’s
Internet access points, internal corporate network, processing connections).
 People – such as technical support, management, administrators, operations

teams, cashiers, telephone operators, etc.:
Note – this is not intended to be a list of individuals interviewed, but instead a
list of the types of people, teams, etc. who were included in the scope.
 Processes – such as payment channels, business functions, etc.:
 Technologies – such as e-commerce systems, internal network segments, DMZ
segments, processor connections, POS systems, etc.:
 Note – this is not intended to be a list of devices but instead a list of the types of
technologies, purposes, functions, etc. included in the scope.
 Locations/sites/stores – such as retail outlets, data centers, corporate office
locations, call centers, etc.:
 Other details, if applicable:
3.3 Network segmentation

 Identify whether the assessed entity has used network segmentation to reduce Yes
the scope of the assessment. (yes/no)
 If segmentation is not used: Provide the name of the assessor who attests Not Applicable
that the whole network has been included in the scope of the assessment.
 If segmentation is used: Briefly describe how the segmentation is
implemented.
 Identify the technologies used and any supporting processes
 Explain how the assessor validated the effectiveness of the segmentation, as follows:
- Describe the methods used to validate the effectiveness of the
segmentation (for example, observed configurations of implemented
technologies, tools used, network traffic analysis, etc.).
- Describe how it was verified that the segmentation is functioning as
intended.
- Describe how it was verified that adequate security controls are in place
to ensure the integrity of the segmentation mechanisms (e.g., access
controls, change management, logging, monitoring, etc.).
 Provide the name of the assessor who attests that the segmentation was
verified to be adequate to reduce the scope of the assessment AND that the
technologies/processes used to implement segmentation were included in the
PCI DSS assessment.
3.4 Network segment details
Describe all networks that store, process and/or transmit CHD:
Network Name
(in scope) Function/ Purpose of Network
Net Name transmit CHD
Describe all networks that do not store, process and/or transmit CHD, but are still in scope (e.g., connected to the CDE or provide
management functions to the CDE):
Network Name
(in scope) Function/ Purpose of Network
Not Applicable Not Applicable
Describe any networks confirmed to be out of scope:
Network Name
(out of scope) Function/ Purpose of Network
Not Applicable Not Applicable
3.5 Connected entities for processing

Complete the following for connected entities for processing. If the assessor needs to include additional reporting for the specific brand and/or acquirer, it
can be included either here within 3.5 or as an appendix at the end of this report. Do not alter the Attestation of Compliance (AOC) for this purpose.
Description of any discussions/issues between the

Identify All Processing Entities
QSA and Processing Entity on behalf of the
(Acquirer/ Bank/ Brands directly connected to for processing) Assessed Entity for this PCI DSS Assessment (if any)
processor entity processor


 Other details, if applicable
(add content or tables here for CMParent is a Service Provider, Level 1
brand/acquirer use, if needed):
3.6 Other business entities that require compliance with the PCI DSS
Entities wholly owned by the assessed entity that are required to comply with PCI DSS:
(This may include subsidiaries, different brands, DBAs, etc.)
Reviewed:
Wholly Owned Entity Name
As part of this assessment Separately
wholly owned one X

International entities owned by the assessed entity that are required to comply with PCI DSS:
List all countries where the entity conducts business.
Facilities in this country reviewed:

International Entity Name
As part of this assessment Separately
Not Applicable Not Applicable Not Applicable

3.7 Wireless summary

 If there are no wireless networks or technologies in use, describe how this Not Applicable
was verified by the assessor.
 If there are wireless networks or technologies in use, identify and describe
all wireless technologies in use that are connected to or could impact
the security of the cardholder data environment. This would include:
 Wireless LANs
 Wireless payment applications (for example, POS terminals)
 All other wireless devices/technologies
3.8 Wireless details
For each wireless technology in scope, identify the following:
For each wireless technology in scope, identify the following (yes/no):
Identified wireless Whether the technology is used to Whether the technology is connected to Whether the technology could
technology store, process or transmit CHD or part of the CDE impact the security of the CDE
wifi Tech Yes Yes No

Wireless technology not in scope for this assessment:
Identified wireless technology

(not in scope) Describe how the wireless technology was validated by the assessor to be not in scope
Wifi Not In Scope does not transmit CHD

4. Details about Reviewed Environment
4.1 Detailed network diagram(s)
Provide one or more detailed diagrams to illustrate each communication/connection point between in scope networks/environments/facilities.
Diagrams should include the following:
 All boundaries of the cardholder data environment
 Any network segmentation points which are used to reduce scope of the assessment
 Boundaries between trusted and untrusted networks
 Wireless and wired networks
 All other connection points applicable to the assessment
Ensure the diagram(s) include enough detail to clearly understand how each communication point functions and is secured. (For example, the level
of detail may include identifying the types of devices, device interfaces, network technologies, protocols, and security controls applicable to that
communication point.)
Figure 1. net-four-one - cowboy
4.2 Description of cardholder data flows
Types of CHD involved Describe how cardholder data is transmitted and/or processed and
Cardholder data flows (for example, full track, PAN, expiry) for what purpose it is used
Authorization Full Track slide card and get auth code back
Capture Not Applicable Not Applicable
Settlement Not Applicable Not Applicable
Chargeback Full Swipe
Identify all other data flows, as applicable (add rows as needed)
Other (describe) Not Applicable Not Applicable
4.3 Cardholder data storage
Identify and list all databases, tables, and files storing cardholder data and provide the following details.
Note: The list of files and tables that store cardholder data in the table below must be supported by an inventory created (or obtained from the client)
and retained by the assessor in the work papers.
How access to data stores is logged

(description of logging mechanism used for logging
Data Store How data is secured access to data—for example, enterprise log
(database, file, table, Cardholder data elements stored (for example, use of encryption, management solution, application-level logging,
etc.) (PAN, expiry, any elements of SAD) access controls, truncation, etc.) operating system logging, etc.)
DB Store from ES 4.3 CHD encrypted secure log

4.4 Critical hardware in use in the cardholder data environment

Identify and list all types of hardware in the cardholder environment, including network components, servers and other mainframes, devices
performing security functions, end-user devices (such as laptops and workstations), virtualized devices (if applicable) and any other critical hardware
– including homegrown components. For each item in the list, provide details for the hardware as indicated below. Add rows, as needed.
Type of Device Vendor (make/model) Role/Functionality

Firewalls Firewall 1.11 firewall
IDS / IPS IDs and IPS 1.11 IDs / IPS
Networks network 1.11 networking
Servers / Mainframes server 8.0 server
Wireless wireless 1.11 wireless
4.5 Critical software in use in the cardholder data environment

Identify and list all critical software in the cardholder environment, such as e-commerce applications, applications accessing CHD for non-payment
functions (fraud modeling, credit verification, etc.), software performing security functions or enforcing PCI DSS controls, underlying operating
systems that store, process or transmit CHD, system management software, virtualization management software, and other critical software –
including homegrown software/applications. For each item in the list, provide details for the software as indicated below. Add rows, as needed.
Name of Software Product Version or Release Role/Functionality
IMP_App MyApp 1.11 Application
IMP_DB DB 1.11 database
IMP_Enc encryp 1.11 encryption
IMP_Log logging 1.11 logging
IMP_OS systems 2.22 systems
IMP_Users user mgt 1.11 user mgt

4.6 Sampling
Identify whether sampling was used during the assessment.
 If sampling is not used:

 Provide the name of the assessor who attests that every system Not Applicable
component and all business facilities have been assessed.
 If sampling is used:
 Provide the name of the assessor who attests that all sample sets used
for this assessment are represented in the below “Sample sets for
reporting” table. Examples may include, but are not limited to firewalls,
application servers, retail locations, data centers, User IDs, people, etc.
 Describe the sampling rationale and/or standardized PCI DSS security
and operational processes/controls used for selecting sample sizes (for
people, processes, technologies, devices, locations/sites, etc.).
 Describe how the above processes and controls were validated by the
assessor.
4.7 Sample sets for reporting
Note: When a reporting instruction asks for a sample, the QSA may either refer to the Sample Set Identifier here (for example “Sample Set-1”) OR
list the sampled items individually in the response. Examples of sample sets may include, but are not limited to, firewalls, application servers, retail
locations, data centers, User IDs, people, etc. Add rows as needed.
Listing of all components (devices, Total Total

Sample Set Sample Type/ Description locations, etc.) of the Sample Set Sampled Population
Reference Number (e.g., firewalls, datacenters, etc.) (with make/model, as applicable)
Sample Set-1 Encryption - EncGroup encryp 1.11 - encryption - my location 1 1
Sample Set-2 Personnel - PeopleSet
Sample Set-3 Documents - DocSet
4.8 Service providers and other third parties with which the entity shares cardholder data
For each service provider or third party, provide:
Note: These entities are subject to PCI DSS Requirement 12.8.
The purpose for sharing the

data
What data is shared (for example, third-party storage, Status of PCI DSS Compliance
Company Name (for example, PAN, expiry date, etc.) transaction processing, etc.) (Date of AOC and version #)
Not Applicable Not Applicable Not Applicable Not Applicable

4.9 Third-party payment applications/solutions

Use the table on the following page to identify and list all third-party payment application products and version numbers in use, including whether
each payment application has been validated according to PA-DSS or PCI P2PE. Even if a payment application has been PA-DSS or PCI P2PE
validated, the assessor still needs to verify that the application has been implemented in a PCI DSS compliant manner and environment, and
according to the payment application vendor’s PA-DSS Implementation Guide for PA-DSS applications or P2PE Implementation Manual (PIM) and
P2PE application vendor’s P2PE Application Implementation Guide for PCI P2PE applications/solutions.
Note: It is not a PCI DSS requirement to use PA-DSS validated applications. Please consult with each payment brand individually to understand
their PA-DSS compliance requirements.
Note: Homegrown payment applications/solutions must be reported at the sections for Critical Hardware and Critical Software. It is also strongly
suggested to address such homegrown payment applications/solutions below at “Any additional comments or findings” in order to represent all
payment applications in the assessed environment in this table.
Name of Third-Party
Payment PA-DSS validated? P2PE validated? PCI SSC listing Expiry date of listing,
Application/Solution Version of Product (yes/no) (yes/no) reference number if applicable
POS 2.2 Yes No 123-4567 2016-03-25
 Provide the name of the assessor who attests that all PA-DSS validated payment applications were
reviewed to verify they have been implemented in a PCI DSS compliant manner according to the
payment application vendor’s PA-DSS Implementation Guide
 Provide the name of the assessor who attests that all PCI SSC-validated P2PE applications and
solutions were reviewed to verify they have been implemented in a PCI DSS compliant manner
according to the P2PE application vendor’s P2PE Application Implementation Guide and the P2PE
solution vendor’s P2PE Instruction Manual (PIM).
 For any of the above Third-Party Payment Applications and/or solutions that are not listed on the PCI
SSC website, identify any being considered for scope reduction/exclusion/etc.
 Any additional comments or findings the assessor would like to share, as applicable:
4.10 Documentation reviewed
Identify and list all reviewed documents. Include the following:
Reference Document Name Document date

Number (including version, if applicable) Brief description of document purpose (latest version date)
Doc-1 My Backup backups 2005-05-05
Doc-2 My docment docmentation 2010-10-10
Doc-3 My Pentest pentest 2015-01-01
Doc-4 My Scan scan 2015-01-01
Doc-5 MySDLC sdlc 2007-07-07
4.11 Individuals interviewed

Identify and list the individuals interviewed. Include the following:
Is this person Summary of Topics Covered / Areas or

Reference an ISA? Systems of Expertise
Number Employee Name Role/Job Title Organization (yes/no) (high-level summary only)
Int-1 Frank Sinatra IT Mgr IT Yes my desc
Int-2 Weird Al App Mgr Apps No my desc

4.12 Managed service providers

For managed service provider (MSP) reviews, the assessor must clearly identify which requirements in this document apply to the MSP (and are
included in the review), and which are not included in the review and are the responsibility of the MSP’s customers to include in their reviews. Include
information about which of the MSP’s IP addresses are scanned as part of the MSP’s quarterly vulnerability scans, and which IP addresses are the
responsibility of the MSP’s customers to include in their own quarterly scans:
 Identify whether the entity being assessed is a managed service provider. (yes/no) No
 If “yes”:
 List the requirements that apply to the MSP and are included in this assessment. Not Applicable
 List the requirements that are the responsibility of the MSP’s customers (and
Not Applicable
have not been included in this assessment).
 Provide the name of the assessor who attests that the testing of these Not Applicable
requirements and/or responsibilities of the MSP is accurately represented in the
signed Attestation of Compliance.
 Identify which of the MSP’s IP addresses are scanned as part of the MSP’s
Not Applicable
quarterly vulnerability scans.
 Identify which of the MSP’s IP addresses are the responsibility of the MSP’s
Not Applicable
customers.
4.13 Disclosure summary for “In Place with Compensating Control” responses
 Identify whether there were any responses indicated as “In Place with Compensating Control.”
Yes
(yes/no)
 If “yes,” complete the table below:
List of all requirements/testing procedures with this result Summary of the issue (legal obligation, etc.)
5.1 Deploy anti-virus software on all systems commonly affected by

5.1 ccw
malicious software (particularly personal computers and servers).
5.1.1 Ensure that anti-virus programs are capable of detecting, removing,
5.1.1 const
and protecting against all known types of malicious software.
5.1.2 For systems considered to be not commonly affected by malicious
software, perform periodic evaluations to identify and evaluate evolving
5.1.2 ccw
malware threats in order to confirm whether such systems continue to not
require anti-virus software.
5.2 const
5.3 const
5.4 Ensure that security policies and operational procedures for
protecting systems against malware are documented, in use, and known 5.4 cons ccw
to all affected parties.
7.1.2 Restrict access to privileged user IDs to least privileges necessary
7.1.2 ccw
to perform job responsibilities.
7.2.3 Default "deny-all" setting 7.2.3 ccw
11.1 ccw
11.1.1 Maintain an inventory of authorized wireless access points
11.1.1 ccw
including a documented business justification.
11.1.2 Implement incident response procedures in the event
11.1.2 ccw
unauthorized wireless access points are detected.
List of all requirements/testing procedures with this result Summary of the issue (legal obligation, etc.)
11.2.1 Perform quarterly internal vulnerability scans, and rescans as

needed, until all “high-risk” vulnerabilities (as identified in Requirement 11.2 ccw
6.1) are resolved. Scans must be performed by qualified personnel.
11.2.2 ccw
11.2.3 Perform internal and external scans, and rescans as needed, after
11.2.3 ccw
any significant change. Scans must be performed by qualified personnel.
11.3 ccw
11.3.1 ccw
11.3.2 ccw
11.3.3 Exploitable vulnerabilities found during penetration testing are
11.3.3 ccw
corrected and testing is repeated to verify the corrections.
11.3.4 If segmentation is used to isolate the CDE from other networks,
perform penetration tests at least annually and after any changes to
segmentation controls/methods to verify that the segmentation methods 11.3.4 ccw
are operational and effective, and isolate all out-of-scope systems from
systems in the CDE.
11.4 Use intrusion-detection systems and/or intrusion-prevention
techniques to detect and/or prevent intrusions into the network. Monitor
all traffic at the perimeter of the cardholder data environment as well as
11.4 ccw
at critical points in the cardholder data environment, and alert personnel
to suspected compromises. Keep all intrusion-detection and prevention
engines, baselines, and signatures up-to-date.
11.5 ccw
11.5.1 Implement a process to respond to any alerts generated by the
11.5.1 ccw
change-detection solution.
11.6 Ensure that security policies and operational procedures for security
monitoring and testing are documented, in use, and known to all affected 11.6 ccw
parties.
A.1.3 Ensure logging and audit trails are enabled and unique to each
entity’s cardholder data environment and consistent with PCI DSS a.1.3 constraint
Requirement 10.
4.14 Disclosure summary for “Not Tested” responses

 Identify whether there were any responses indicated as “Not Tested”:
Yes
(yes/no)
 If “yes,” complete the table below:
List of all requirements/testing procedures with this result

Summary of the issue
(for example, not deemed in scope for the assessment, reliance on a third-party service provider who is compliant to PCI DSS v2.0 and hasn’t yet assessed against 3.0 or
3.1, etc.)
marking all of req 3 as NT. This is the mark all resp

3.2.2 Do not store the card verification code or value (three-digit or four-digit number printed on the front or back of a payment card) used to verify card-not-present
transactions after authorization.
3.2.3 Do not store the personal identification number (PIN) or the encrypted PIN block after authorization.

3.4.1 If disk encryption is used (rather than file- or column-level database encryption), logical access must be managed separately and independently of native operating
system authentication and access control mechanisms (for example, by not using local user account databases or general network login credentials). Decryption keys
must not be associated with user accounts.

3.5.1 Restrict access to cryptographic keys to the fewest number of custodians necessary.

3.5.3 Store cryptographic keys in the fewest possible locations.
3.6.1 Generation of strong cryptographic keys.
3.6.2 Secure cryptographic key distribution.
3.6.3 Secure cryptographic key storage.
3.6.4 Cryptographic key changes for keys that have reached the end of their cryptoperiod (for example, after a defined period of time has passed and/or after a certain
amount of cipher-text has been produced by a given key), as defined by the associated application vendor or key owner, and based on industry best practices and
guidelines (for example, NIST Special Publication 800-57).

3.6.7 Prevention of unauthorized substitution of cryptographic keys.
3.6.8 Requirement for cryptographic key custodians to formally acknowledge that they understand and accept their key-custodian responsibilities.
3.7 Ensure that security policies and operational procedures for protecting stored cardholder data are documented, in use, and known to all affected parties.
7.1.4 Require documented approval by authorized parties specifying required privileges.
7.1.4 NT respo
second para
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.
7.3 NT resp
12.1 Establish, publish, maintain, and disseminate a security policy.
nt resp for req 12
12.1.1 Review the security policy at least annually and update the policy when business objectives or the risk environment change.
nt resp for req 12
nt resp for req 12
nt resp for req 12

12.3.1 Explicit approval by authorized parties.
nt resp for req 12
12.3.2 Authentication for use of the technology.
nt resp for req 12
12.3.3 A list of all such devices and personnel with access.
nt resp for req 12
12.3.4 A method to accurately and readily determine owner, contact information, and purpose (for example, labeling, coding, and/or inventorying of devices).
nt resp for req 12
12.3.5 Acceptable uses of the technology.
nt resp for req 12
12.3.6 Acceptable network locations for the technologies.
nt resp for req 12
12.3.7 List of company-approved products.
nt resp for req 12
12.3.8 Automatic disconnect of sessions for remote-access technologies after a specific period of inactivity.
nt resp for req 12
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.
nt resp for req 12
12.3.10 For personnel accessing cardholder data via remote-access technologies, prohibit the copying, moving, and storage of cardholder data onto local hard drives and
removable electronic media, unless explicitly authorized for a defined business need. Where there is an authorized business need, the usage policies must require the
data be protected in accordance with all applicable PCI DSS Requirements.
nt resp for req 12
12.4 Ensure that the security policy and procedures clearly define information security responsibilities for all personnel.
nt resp for req 12
12.5 Assign to an individual or team the following information security management responsibilities:
nt resp for req 12
12.5.1 Establish, document, and distribute security policies and procedures.
nt resp for req 12
12.5.2 Monitor and analyze security alerts and information, and distribute to appropriate personnel.
nt resp for req 12
12.5.3 Establish, document, and distribute security incident response and escalation procedures to ensure timely and effective handling of all situations.
nt resp for req 12
12.5.4 Administer user accounts, including additions, deletions, and modifications.
nt resp for req 12
12.5.5 Monitor and control all access to data.
nt resp for req 12
12.6 Implement a formal security awareness program to make all personnel aware of the importance of cardholder data security.
nt resp for req 12
nt resp for req 12

12.6.2 Require personnel to acknowledge at least annually that they have read and understood the security policy and procedures.
nt resp for req 12
nt resp for req 12

12.8 Maintain and implement policies and procedures to manage service providers with whom cardholder data is shared, or that could affect the security of cardholder
data, as follows:
nt resp for req 12
12.8.1 Maintain a list of service providers.
nt resp for req 12
nt resp for req 12

12.8.3 Ensure there is an established process for engaging service providers including proper due diligence prior to engagement.
nt resp for req 12
12.8.4 Maintain a program to monitor service providers’ PCI DSS compliance status at least annually.
nt resp for req 12
12.8.5 Maintain information about which PCI DSS requirements are managed by each service provider, and which are managed by the entity.
nt resp for req 12
nt resp for req 12

12.10 Implement an incident response plan. Be prepared to respond immediately to a system breach.
nt resp for req 12
nt resp for req 12

12.10.2 Test the plan at least annually.
nt resp for req 12
12.10.3 Designate specific personnel to be available on a 24/7 basis to respond to alerts.
nt resp for req 12
12.10.4 Provide appropriate training to staff with security breach response responsibilities.
nt resp for req 12
12.10.5 Include alerts from security monitoring systems, including but not limited to intrusion-detection, intrusion-prevention, firewalls, and file-integrity monitoring
systems.
nt resp for req 12
12.10.6 Develop a process to modify and evolve the incident response plan according to lessons learned and to incorporate industry developments.
nt resp for req 12
5. Quarterly Scan Results
5.1 Quarterly scan results – initial PCI DSS compliance validation
 Is this the assessed entity’s initial PCI DSS compliance validation? (yes/no) No
 If “yes,” complete the remainder of Table 5.1 below.
If “no,” proceed to Table 5.2.
 Identify how many external quarterly ASV scans were performed within the last 12 months: Not Applicable
 Summarize the four most recent quarterly ASV scan results in the Summary Overview as well as in comments at Requirement 11.2.2.
Note: It is not required that four passing quarterly scans must be completed for initial PCI DSS compliance if the assessor verified:
 The most recent scan result was a passing scan,
 The entity has documented policies and procedures requiring quarterly scanning going forward, and
 Any vulnerabilities noted in the initial scan have been corrected as shown in a re-scan.
For subsequent years after the initial PCI DSS review, four passing quarterly scans must have occurred.
 For each quarterly ASV scan performed within the last 12 months, identify:
Were any vulnerabilities found that resulted

in a failed initial scan? For all scans resulting in a Fail, provide date(s) of re-scans
Date of the scan(s) (yes/no) showing that the vulnerabilities have been corrected
Not Applicable Not Applicable Not Applicable

 Provide the name of the assessor who attests that the most recent scan result was verified to Not Applicable
be a passing scan.
 Identify the name of the document the assessor verified to include the entity’s documented Not Applicable
policies and procedures requiring quarterly scanning going forward.
 Describe how the assessor verified that any vulnerabilities noted in the initial scan have been Not Applicable
corrected, as shown in a re-scan.
5.2 Quarterly scan results – all other PCI DSS compliance validation
 Identify whether this is the assessed entity’s initial PCI DSS compliance validation. (yes/no) No
 If “yes,” complete the remainder of Table 5.1 above.
If “no,” complete the table below.
Results of Scans For all scans resulting in a Fail, provide date(s) of re-scans showing that the
Date of the scan(s) (Pass/Fail) vulnerabilities have been corrected
2015-06-15 PASS

Assessor comments, if applicable:
5.3 Attestations of scan compliance

Scan must cover all externally accessible (Internet-facing) IP addresses in existence at the entity, in accordance with the PCI DSS Approved
Scanning Vendors (ASV) Program Guide.
Provide the name of the assessor who attests that the ASV and the entity have completed
the Attestations of Scan Compliance confirming that all externally accessible (Internet-
facing) IP addresses in existence at the entity were appropriately scoped for the ASV scans:
6. Findings and Observations
Build and Maintain a Secure Network and Systems
Requirement 1: Install and maintain a firewall configuration to protect cardholder data
(check one)
PCI DSS Requirements Reporting Details:
In In Place Not Not in
and Testing Procedures Reporting Instruction Assessor’s Response Place w/ CCW N/A Tested Place
1.1 Establish and implement firewall and router configuration standards that include the following:
1.1 Inspect the firewall and router configuration standards and other documentation specified below and verify that standards are
complete and implemented as follows:
1.1.1 A formal process for approving and testing all network connections and changes to the
☒ ☐ ☐ ☐ ☐
firewall and router configurations.
1.1.1.a Examine documented Identify the document(s) reviewed to verify procedures define the formal processes for:
procedures to verify there is a  Testing and approval of all network
formal process for testing and connections.
approval of all:
 Testing and approval of all changes
 Network connections, and
to firewall and router configurations.
 Changes to firewall and
router configurations.
1.1.1.b For a sample of Identify the sample of records for
network connections, interview network connections that were
responsible personnel and examined.
examine records to verify that Identify the responsible personnel
network connections were interviewed who confirm that network
approved and tested. connections were approved and tested.
Describe how the sampled records were examined to verify that network connections were:
 Approved
 Tested
(check one)
1.1.1.c Identify a sample of Identify the sample of records for

actual changes made to firewall firewall and router configuration
and router configurations, changes that were examined.
compare to the change Identify the responsible personnel
records, and interview interviewed who confirm that changes
responsible personnel to verify made to firewall and router
the changes were approved configurations were approved and
and tested. tested.
Describe how change records were compared to actual changes made to firewall and router configurations to verify the changes
were:
 Approved
 Tested
1.1.2 Current diagram that identifies all connections between the cardholder data environment ☒ ☐ ☐ ☐ ☐
and other networks, including any wireless networks.
1.1.2.a Examine diagram(s) Identify the current network
and observe network diagram(s) examined.
configurations to verify that a Describe how network connections were observed and compared to the diagram(s) to verify that
current network diagram exists the diagram:
and that it documents all
 Is current.
connections to the cardholder
data environment, including  Includes all connections to
any wireless networks. cardholder data.
 Includes any wireless network
connections.
1.1.2.b Interview responsible Identify the document examined to
personnel to verify that the verify processes require that the
diagram is kept current. network diagram is kept current.
(check one)
Identify the responsible personnel

interviewed for this testing procedure.
For the interview, summarize the
relevant details discussed to verify
that the diagram is kept current.
1.1.3 Current diagram that shows all cardholder data flows across systems and networks. ☒ ☐ ☐ ☐ ☐
1.1.3.a Examine data flow Identify the data-flow diagram(s)

diagram and interview examined.
personnel to verify the diagram: Identify the responsible personnel
 Shows all cardholder data interviewed for this testing procedure.
flows across systems and
For the interview, summarize the relevant details discussed to verify the diagram:
networks.
 Is kept current and updated  Shows all cardholder data flows
as needed upon changes to across systems and networks.
the environment.  Is kept current and updated as
needed upon changes to the
environment.
1.1.4 Requirements for a firewall at each Internet connection and between any demilitarized zone
☒ ☐ ☐ ☐ ☐
(DMZ) and the internal network zone.
1.1.4.a Examine the firewall Identify the firewall configuration
configuration standards and standards document examined to
verify that they include verify requirements for a firewall:
requirements for a firewall at  At each Internet connection.
each Internet connection and  Between any DMZ and the internal
between any DMZ and the network zone.
internal network zone.
(check one)
1.1.4.b Verify that the current Provide the name of the assessor
network diagram is consistent who attests that the current network
with the firewall configuration diagram identified at 1.1.2.a was
standards. compared to the firewall configuration
standards identified at 1.1.4.a to verify
they are consistent with each other.
1.1.4.c Observe network Describe how network configurations were observed to verify that, per the documented
configurations to verify that a configuration standards and network diagrams, a firewall is in place:
firewall is in place at each  At each Internet connection.
Internet connection and
 Between any DMZ and the internal
between any demilitarized zone
network zone.
(DMZ) and the internal network
zone, per the documented
configuration standards and
network diagrams.
1.1.5 Description of groups, roles, and responsibilities for management of network components. ☒ ☐ ☐ ☐ ☐
1.1.5.a Verify that firewall and Identify the firewall and router
router configuration standards configuration standards document(s)
include a description of groups, reviewed to verify they include a
roles, and responsibilities for description of groups, roles and
management of network responsibilities for management of
components. network components.
1.1.5.b Interview personnel Identify the personnel responsible for
responsible for management of management of network components
network components to confirm interviewed for this testing procedure.
(check one)
that roles and responsibilities For the interview, summarize the

are assigned as documented. relevant details discussed to verify
that roles and responsibilities are
assigned as documented for
management of firewall and router
components.
1.1.6 Documentation and business justification for use of all services, protocols, and ports
allowed, including documentation of security features implemented for those protocols considered
to be insecure. ☒ ☐ ☐ ☐ ☐
Examples of insecure services, protocols, or ports include but are not limited to FTP, Telnet,
POP3, IMAP, and SNMP v1 and v2.
1.1.6.a Verify that firewall and Identify the firewall configuration
router configuration standards standards document(s) reviewed to
include a documented list of all verify the document(s) contains a list of
services, protocols and ports, all services, protocols and ports
including business justification necessary for business, including a
for each—for example, business justification for each.
hypertext transfer protocol Identify the router configuration
(HTTP) and Secure Sockets standards document(s) reviewed to
Layer (SSL), Secure Shell verify the document contains a list of all
(SSH), and Virtual Private services, protocols and ports necessary
Network (VPN) protocols. for business, including a business
justification for each.
1.1.6.b Identify insecure Indicate whether any insecure No
services, protocols, and ports services, protocols or ports are allowed.
allowed; and verify that security (yes/no)
(check one)
features are documented for If “yes,” complete the instructions below for EACH insecure service, protocol, and port allowed:
each service. (add rows as needed)
Identify the documented justification. Not Applicable
Identify the firewall and router Not Applicable

configuration standards reviewed to
verify that security features are
documented for each insecure
service/protocol/port.
1.1.6.c Examine firewall and If “yes” at 1.1.6.b, complete the following for each insecure service, protocol, and/or port present
router configurations to verify (add rows as needed):
that the documented security Describe how the firewall and router Not Applicable
features are implemented for configurations were examined to verify
each insecure service, protocol, that the documented security features
and port. are implemented for each insecure
service, protocol and/or port.
1.1.7 Requirement to review firewall and router rule sets at least every six months. ☒ ☐ ☐ ☐ ☐
1.1.7.a Verify that firewall and Identify the firewall and router
router configuration standards configuration standards reviewed to
require review of firewall and verify they require a review of firewall
router rule sets at least every rule sets at least every six months.
six months.
1.1.7.b Examine Identify the document(s) relating to
documentation relating to rule rule set reviews that were examined to
set reviews and interview verify that rule sets are reviewed at
responsible personnel to verify least every six months for firewall and
router rule sets.
(check one)
that the rule sets are reviewed Identify the responsible personnel
at least every six months. interviewed who confirm that rule sets
are reviewed at least every six months
for firewall and router rule sets.
1.2 Build firewall and router configurations that restrict connections between untrusted networks and any system components in the
cardholder data environment.
Note: An “untrusted network” is any network that is external to the networks belonging to the entity under review, and/or which is out
of the entity's ability to control or manage.
1.2 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 Restrict inbound and outbound traffic to that which is necessary for the cardholder data
☒ ☐ ☐ ☐ ☐
environment, and specifically deny all other traffic.
1.2.1.a Examine firewall Identify the firewall and router
and router configuration configuration standards reviewed to
standards to verify that they verify they identify inbound and
identify inbound and outbound outbound traffic necessary for the
traffic necessary for the cardholder data environment.
1.2.1.b Examine firewall and Describe how firewall and router configurations were examined to verify that the following traffic is
router configurations to verify limited to that which is necessary for the cardholder data environment:
that inbound and outbound  Inbound traffic
traffic is limited to that which is
 Outbound traffic
necessary for the cardholder
data environment.
1.2.1.c Examine firewall and Describe how firewall and router configurations were examined to verify the following is specifically
router configurations to verify denied:
(check one)
that all other inbound and  All other inbound traffic

outbound traffic is specifically  All other outbound traffic
denied, for example by using
an explicit “deny all” or an
implicit deny after allow
statement.
1.2.2 Secure and synchronize router configuration files. ☒ ☐ ☐ ☐ ☐
1.2.2.a Examine router Describe how router configuration files

configuration files to verify they were examined to verify they are
are secured from unauthorized secured from unauthorized access.
access.
1.2.2.b Examine router Describe how router configuration files
configurations to verify they are were examined to verify they are
synchronized—for example, the synchronized.
running (or active) configuration
matches the start-up
configuration (used when
machines are booted).
1.2.3 Install perimeter firewalls between all wireless networks and the cardholder data
environment, and configure these firewalls to deny or, if traffic is necessary for business
☒ ☐ ☐ ☐ ☐
purposes, permit only authorized traffic between the wireless environment and the cardholder
data environment.
(check one)
1.2.3.a Examine firewall and Describe how firewall and router

router configurations to verify configurations were examined to verify
that there are perimeter perimeter firewalls are in place between
firewalls installed between all all wireless networks and the cardholder
wireless networks and the data environment.
1.2.3.b Verify that the firewalls Indicate whether traffic between the No
deny or, if traffic is necessary wireless environment and the
for business purposes, permit cardholder data environment is
only authorized traffic between necessary for business purposes.
the wireless environment and (yes/no)
the cardholder data If “no”:
environment.
Describe how firewall and/or router
configurations were observed to verify
firewalls deny all traffic from any
wireless environment into the
cardholder environment.
If “yes”:
Describe how firewall and/or router Not Applicable

configurations were observed to verify
firewalls permit only authorized traffic
from any wireless environment into the
cardholder environment.
1.3 Prohibit direct public access between the Internet and any system component in the cardholder data environment.
1.3 Examine firewall and router configurations—including but not limited to the choke router at the Internet, the DMZ router and
firewall, the DMZ cardholder segment, the perimeter router, and the internal cardholder network segment—and perform the following
to determine that there is no direct access between the Internet and system components in the internal cardholder network segment:
(check one)
1.3.1 Implement a DMZ to limit inbound traffic to only system components that provide authorized
☒ ☐ ☐ ☐ ☐
publicly accessible services, protocols, and ports.
1.3.1 Examine firewall and Describe how the firewall and router
that a DMZ is implemented to that the DMZ is implemented to limit
limit inbound traffic to only inbound traffic to only system
system components that components that provide authorized
provide authorized publicly publicly accessible services, protocols,
accessible services, protocols, and ports.
and ports.
1.3.2 Limit inbound Internet traffic to IP addresses within the DMZ. ☒ ☐ ☐ ☐ ☐
1.3.2 Examine firewall and Describe how the firewall and router
that inbound Internet traffic is that configurations limit inbound Internet
limited to IP addresses within traffic to IP addresses within the DMZ.
the DMZ.
1.3.3 Do not allow any direct connections inbound or outbound for traffic between the Internet and
☒ ☐ ☐ ☐ ☐
the cardholder data environment.
1.3.3 Examine firewall and Describe how the examined firewall and router configurations were observed to prevent direct connections between the Internet and
router configurations to verify the cardholder data environment:
direct connections inbound or  Inbound
outbound are not allowed for
 Outbound
traffic between the Internet and
the cardholder data
environment.
(check one)
1.3.4 Implement anti-spoofing measures to detect and block forged source IP addresses from
entering the network. ☒ ☐ ☐ ☐ ☐
(For example, block traffic originating from the Internet with an internal source address)
1.3.4 Examine firewall and Describe how firewall and router
that anti-spoofing measures are that anti-spoofing measures are
implemented, for example implemented.
internal addresses cannot pass Describe the anti-spoofing measures
from the Internet into the DMZ. implemented
1.3.5 Do not allow unauthorized outbound traffic from the cardholder data environment to the
☒ ☐ ☐ ☐ ☐
Internet.
that outbound traffic from the that outbound traffic from the cardholder
cardholder data environment to data environment to the Internet is
the Internet is explicitly explicitly authorized.
authorized.
1.3.6 Implement stateful inspection, also known as dynamic packet filtering. (That is, only
☒ ☐ ☐ ☐ ☐
“established” connections are allowed into the network.)
that the firewall performs that the firewall performs stateful
stateful inspection (dynamic inspection.
(check one)
packet filtering). (Only Describe how observed firewall

established connections should configurations implement stateful
be allowed in, and only if they inspection
are associated with a
previously established
session.)
1.3.7 Place system components that store cardholder data (such as a database) in an internal
☒ ☐ ☐ ☐ ☐
network zone, segregated from the DMZ and other untrusted networks.
1.3.7 Examine firewall and Indicate whether any system No
router configurations to verify components store cardholder data.
that system components that (yes/no)
store cardholder data are on an If “yes”:
internal network zone,
Describe how firewall and router Not Applicable
segregated from the DMZ and
configurations were examined to verify
other untrusted networks.
that the system components that store
cardholder data are located on an
internal network zone, and are
segregated from the DMZ and other
untrusted networks.
1.3.8 Do not disclose private IP addresses and routing information to unauthorized parties.
Note: Methods to obscure IP addressing may include, but are not limited to:
 Network Address Translation (NAT),
 Placing servers containing cardholder data behind proxy servers/firewalls, ☒ ☐ ☐ ☐ ☐
 Removal or filtering of route advertisements for private networks that employ registered
addressing,
 Internal use of RFC1918 address space instead of registered addresses.
(check one)
1.3.8.a Examine firewall and Describe the methods in place to

router configurations to verify prevent the disclosure of private IP
that methods are in place to addresses and routing information from
prevent the disclosure of internal networks to the Internet.
private IP addresses and Describe how firewall and router
routing information from configurations were examined to verify
internal networks to the that methods are in place to prevent the
Internet. disclosure of private IP addresses and
routing information from internal
networks to the Internet.
1.3.8.b Interview personnel and Identify the document reviewed that
examine documentation to specifies whether any disclosure of
verify that any disclosure of private IP addresses and routing
private IP addresses and information to external parties is
routing information to external permitted.
entities is authorized. For each permitted disclosure, identify
the responsible personnel interviewed
who confirm that the disclosure is
authorized.
1.4 Install personal firewall software on any mobile and/or employee-owned devices that connect
to the Internet when outside the network (for example, laptops used by employees), and which
are also used to access the network. Firewall configurations include:
☒ ☐ ☐ ☐ ☐
 Specific configuration settings are defined for personal firewall software.
 Personal firewall software is actively running.
 Personal firewall software is not alterable by users of mobile and/or employee-owned devices.
(check one)
1.4.a Examine policies and Indicate whether mobile and/or No

configuration standards to employee-owned computers with direct
verify: connectivity to the Internet when outside
 Personal firewall software is the network are used to access the
required for all mobile and/or organization’s network. (yes/no)
employee-owned devices If “no,” identify the document reviewed
that connect to the Internet that explicitly prohibits mobile and/or
when outside the network, employee-owned computers with direct
(for example, laptops used connectivity to the Internet when outside
by employees), and which the network from being used to access
are also used to access the the organization’s network.
network. Mark 1.4.b as “not applicable”
(check one)
 Specific configuration If “yes,” identify the documented Not Applicable

settings are defined for policies and configuration standards
personal firewall software. that define the following:
 Personal firewall software is  Personal firewall software is
configured to actively run. required for all mobile and/or
 Personal firewall software is employee-owned devices that
configured to not be connect to the Internet when
alterable by users of mobile outside the network, and which
and/or employee-owned are also used to access the
devices. network.
 Specific configuration settings are
defined for personal firewall
software.
 Personal firewall software is
configured to actively run.
configured to not be alterable by
users of mobile and/or employee-
owned devices.
(check one)
1.4.b Inspect a sample of Identify the sample of mobile and/or Not Applicable
mobile and/or employee-owned employee-owned devices selected for
devices to verify that: this testing procedure.
 Personal firewall software is Describe how the sample of mobile and/or employee-owned devices was inspected to verify that
installed and configured per personal firewall software is:
the organization’s specific  Installed and configured per the Not Applicable
configuration settings. organization’s specific configuration
 Personal firewall software is settings.
actively running.  Actively running. Not Applicable
 Not alterable by users of mobile Not Applicable
not alterable by users of
and/or employee-owned devices.
mobile and/or employee-
owned devices.
1.5 Ensure that security policies and operational procedures for managing firewalls are
☒ ☐ ☐ ☐ ☐
documented, in use, and known to all affected parties.
1.5 Examine documentation Identify the document reviewed to
and interview personnel to verify that security policies and
verify that security policies and operational procedures for managing
operational procedures for firewalls are documented.
managing firewalls are: Identify responsible personnel
 Documented, interviewed who confirm that the above
 In use, and documented security policies and
operational procedures for managing
 Known to all affected parties.
firewalls are:
 In use
 Known to all affected parties
Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters
(check one)
2.1 Always change vendor-supplied defaults and remove or disable unnecessary default accounts
before installing a system on the network.
This applies to ALL default passwords, including but not limited to those used by operating ☐ ☐ ☒ ☐ ☐
systems, software that provides security services, application and system accounts, POS
terminals, Simple Network Management Protocol (SNMP) community strings, etc.
2.1.a Choose a sample of Identify the sample of system marking all of req 2 as n/a. this is the response
system components, and components selected.
attempt to log on (with system Identify the vendor manuals and Not Applicable
administrator help) to the sources on the Internet used to find
devices and applications using vendor-supplied accounts/passwords.
default vendor-supplied
For each item in the sample, describe Not Applicable
accounts and passwords, to
how attempts to log on (with system
verify that ALL default
administrator help) to the sample of
passwords (including those on
devices and applications using default
operating systems, software
vendor-supplied accounts and
that provides security services,
passwords were performed to verify that
application and system
all default passwords have been
accounts, POS terminals, and
changed.
Simple Network Management
Protocol (SNMP) community
strings) have been changed.
(Use vendor manuals and
sources on the Internet to find
vendor-supplied
accounts/passwords.)
(check one)
2.1.b For the sample of system For each item in the sample of system components indicated at 2.1.a, describe how all
components, verify that all unnecessary default accounts were verified to be either:
unnecessary default accounts  Removed Not Applicable
(including accounts used by
operating systems, security
software, applications,  Disabled Not Applicable
systems, POS terminals,

SNMP, etc.) are removed or
disabled.
2.1.c Interview personnel and Identify responsible personnel Not Applicable
examine supporting interviewed who verify that:
documentation to verify that:  All vendor defaults (including
 All vendor defaults (including default passwords on operating
default passwords on systems, software providing
operating systems, software security services, application and
providing security services, system accounts, POS terminals,
application and system Simple Network Management
accounts, POS terminals, Protocol (SNMP) community
Simple Network strings, etc.) are changed before a
Management Protocol system is installed on the network.
(SNMP) community strings,  Unnecessary default accounts
etc.) are changed before a (including accounts used by
system is installed on the operating systems, security
network. software, applications, systems,
 Unnecessary default POS terminals, SNMP, etc.) are
accounts (including accounts removed or disabled before a
system is installed on the network.
(check one)
used by operating systems, Identify supporting documentation Not Applicable

security software, examined for this testing procedure.
applications, systems, POS Describe how the supporting documentation examined verified that:
terminals, SNMP, etc.) are
removed or disabled before  All vendor defaults are changed Not Applicable
a system is installed on the before a system is installed on the

network. network.
 Unnecessary default accounts are Not Applicable
removed or disabled before a system
is installed on the network.
2.1.1 For wireless environments connected to the cardholder data environment or transmitting
cardholder data, change ALL wireless vendor defaults at installation, including but not limited to ☐ ☐ ☒ ☐ ☐
default wireless encryption keys, passwords, and SNMP community strings.
2.1.1.a Interview responsible Indicate whether there are wireless marking all of req 2 as n/a. this is the response
personnel and examine environments connected to the
supporting documentation to cardholder data environment or
verify that: transmitting cardholder data. (yes/no)
If “no,” mark 2.1.1 as “Not Applicable” and proceed to
2.2.
(check one)
 Encryption keys were If “yes”:
changed from default at
Identify responsible personnel Not Applicable
installation
interviewed who verify that encryption
 Encryption keys are changed keys are changed:
anytime anyone with
 From default at installation
knowledge of the keys leaves
the company or changes  Anytime anyone with knowledge of
positions. the keys leaves the company or
changes positions.
Identify supporting documentation Not Applicable
examined for this testing procedure.
Describe how the supporting documentation was examined to verify that encryption keys are changed:
 From default at installation Not Applicable
 Anytime anyone with knowledge of Not Applicable

the keys leaves the company or
changes positions.
(check one)
2.1.1.b Interview personnel and Identify responsible personnel Not Applicable

examine policies and interviewed who verify that:
procedures to verify:  Default SNMP community strings
 Default SNMP community are required to be changed upon
strings are required to be installation.
changed upon installation.  Default passwords/phrases on
 Default passwords/phrases
access points are required to be
on access points are required changed upon installation.
to be changed upon
Identify policies and procedures Not Applicable
installation.
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 installation.
2.1.1.c Examine vendor Identify vendor documentation Not Applicable
documentation and login to examined for this testing procedure.
wireless devices, with system
Describe how examined vendor documentation was used to attempt to login to wireless devices (with system administrator help) to
administrator help, to verify:
verify:
 Default SNMP community
 Default SNMP community strings are Not Applicable
strings are not used.
not used.
 Default
passwords/passphrases on  Default passwords/passphrases on Not Applicable
access points are not used. access points are not used.
2.1.1.d Examine vendor Identify vendor documentation Not Applicable
documentation and observe examined for this testing procedure.
(check one)
wireless configuration settings Describe how wireless configuration settings were observed with examined vendor documentation to verify that firmware on
to verify firmware on wireless wireless devices is updated to support strong encryption for:
devices is updated to support  Authentication over wireless Not Applicable
strong encryption for: networks.
 Authentication over wireless  Transmission over wireless networks. Not Applicable
networks
 Transmission over wireless
networks
2.1.1.e Examine vendor Identify vendor documentation Not Applicable
documentation and observe examined for this testing procedure.
wireless configuration settings Describe how wireless configuration Not Applicable
to verify other security-related settings were observed with examined
wireless vendor defaults were vendor documentation to verify other
changed, if applicable. security-related wireless vendor defaults
were changed, if applicable.
2.2 Develop configuration standards for all system components. Assure that these standards
address all known security vulnerabilities and are consistent with industry-accepted system
hardening standards.
Sources of industry-accepted system hardening standards may include, but are not limited to:
☐ ☐ ☒ ☐ ☐
 Center for Internet Security (CIS)
 International Organization for Standardization (ISO)
 SysAdmin Audit Network Security (SANS) Institute
 National Institute of Standards Technology (NIST)
2.2.a Examine the Identify the documented system marking all of req 2 as n/a. this is the response
organization’s system configuration standards for all types
configuration standards for all of system components examined.
(check one)
types of system components Identify the industry-accepted Not Applicable

and verify the system hardening standards the system
configuration standards are configuration standards were verified to
consistent with industry- be consistent with.
accepted hardening standards.
2.2.b Examine policies and Identify the policy documentation Not Applicable
interview personnel to verify verified to define that system
that system configuration configuration standards are updated as
standards are updated as new new vulnerability issues are identified
vulnerability issues are Identify the personnel interviewed for Not Applicable
identified, as defined in this testing procedure.
Requirement 6.1.
For the interview, summarize the Not Applicable
relevant details discussed that verify
that the process is implemented.
2.2.c Examine policies and Identify the policy documentation Not Applicable
interview personnel to verify examined to verify it defines that system
that system configuration configuration standards are applied
standards are applied when when new systems are configured and
new systems are configured verified as being in place before a
and verified as being in place system is installed on the network
before a system is installed on Identify the personnel interviewed for Not Applicable
the network. this testing procedure.
For the interview, summarize the relevant details discussed that verify:
 System configuration standards are Not Applicable

applied when new systems are
configured
(check one)
 System configuration standards are Not Applicable

verified as being in place before a
system is installed on the network.
(check one)
2.2.d Verify that system Identify the system configuration Not Applicable
configuration standards include standards for all types of system
the following procedures for all components that include the following
types of system components: procedures:
 Changing of all vendor-  Changing of all vendor-supplied
supplied defaults and defaults and elimination of
elimination of unnecessary unnecessary default accounts
default accounts  Implementing only one primary
 Implementing only one function per server to prevent
primary function per server functions that require different
to prevent functions that security levels from co-existing on
require different security the same server
levels from co-existing on  Enabling only necessary services,
the same server protocols, daemons, etc., as
 Enabling only necessary required for the function of the
services, protocols, system
daemons, etc., as required  Implementing additional security
for the function of the system features for any required services,
 Implementing additional protocols or daemons that are
security features for any considered to be insecure
required services, protocols  Configuring system security
or daemons that are parameters to prevent misuse
considered to be insecure  Removing all unnecessary
 Configuring system security functionality, such as scripts,
parameters to prevent drivers, features, subsystems, file
misuse systems, and unnecessary web
 Removing all unnecessary servers
functionality, such as scripts,
drivers, features,
(check one)
2.2.1 Implement only one primary function per server to prevent functions that require different
security levels from co-existing on the same server. (For example, web servers, database
servers, and DNS should be implemented on separate servers.) ☐ ☐ ☒ ☐ ☐
Note: Where virtualization technologies are in use, implement only one primary function per
virtual system component.
2.2.1.a Select a sample of Identify the sample of system marking all of req 2 as n/a. this is the response
system components and components observed.
inspect the system For each item in the sample, describe Not Applicable
configurations to verify that only how system configurations were
one primary function is inspected to verify that only one primary
implemented per server. function per server is implemented.
2.2.1.b If virtualization Indicate whether virtualization Not Applicable
technologies are used, inspect technologies are used. (yes/no)
the system configurations to If “no,” describe how systems were Not Applicable
verify that only one primary observed to verify that no
function is implemented per virtualization technologies are used.
virtual system component or
If “yes”:
device.
Identify the functions for which Not Applicable
virtualization technologies are used.
Identify the sample of virtual system Not Applicable
components or devices observed.
(check one)
For each virtual system component and Not Applicable

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.
2.2.2 Enable only necessary services, protocols, daemons, etc., as required for the function of the
☐ ☐ ☒ ☐ ☐
system.
system components and components selected.
inspect enabled system For each item in the sample, describe Not Applicable
services, daemons, and how the enabled system services,
protocols to verify that only daemons, and protocols were inspected
necessary services or protocols to verify that only necessary services or
are enabled. protocols are enabled.
2.2.2.b Identify any enabled For each item in the sample of system Not Applicable
insecure services, daemons, or components from 2.2.2.a, indicate
protocols and interview whether any insecure services,
personnel to verify they are daemons, or protocols are enabled.
justified per documented (yes/no)
configuration standards. If “no,” mark the remainder of 2.2.2.b and 2.2.3 as
“Not Applicable.”
If “yes,” identify responsible Not Applicable

personnel interviewed who confirm that
a documented business justification was
present for each insecure service,
daemon, or protocol
(check one)
2.2.3 Implement additional security features for any required services, protocols, or daemons that
are considered to be insecure—for example, use secured technologies such as SSH, S-FTP,
TLS, or IPSec VPN to protect insecure services such as NetBIOS, file-sharing, Telnet, FTP, etc.
Note: SSL and early TLS are not considered strong cryptography and cannot be used as a
security control after 30th June, 2016. Prior to this date, existing implementations that use SSL
☐ ☐ ☒ ☐ ☐
and/or early TLS must have a formal Risk Mitigation and Migration Plan in place.
Effective immediately, new implementations must not use SSL or early TLS.
POS POI terminals (and the SSL/TLS termination points to which they connect) that can be
verified as not being susceptible to any known exploits for SSL and early TLS may continue using
these as a security control after 30th June, 2016.
2.2.3.a Inspect configuration If “yes” at 2.2.2.b, perform the following:
settings to verify that security Identify configuration settings Not Applicable
features are documented and inspected.
implemented for all insecure
Describe how configuration settings were inspected to verify that security features for all insecure services, daemons, or protocols
services, daemons, or
are:
protocols.
 Documented Not Applicable
 Implemented Not Applicable
2.2.3.b For POS POI terminals Indicate whether the assessed entity Not Applicable
(and the SSL/TLS termination includes POS POI terminals (and the
points to which they connect) SSL/TLS termination points to which
using SSL and/or early TLS they connect) using SSL and/or early
and for which the entity asserts TLS – for which the entity asserts are
are not susceptible to any not susceptible to any known exploits
known exploits for those for those protocols. (yes/no)
protocols: If ‘no,’ mark the remainder of 2.2.3.b as
‘not applicable.’
(check one)
Confirm that the entity has If ‘yes,’ identify the document(s) Not Applicable
documentation (for example, examined to verify that the entity
vendor documentation, maintains documentation that verifies
system/network configuration the devices are not susceptible to any
details, etc.) that verifies the known exploits for SSL/early TLS.
devices are not susceptible to
any known exploits for
SSL/early TLS.
2.2.3.c For all other Indicate whether the assessed entity Not Applicable
environments using SSL and/or includes any other environments using
early TLS: SSL and/or early TLS (yes/no)
If ‘no,’ mark the remainder of 2.2.3.c as
‘not applicable.’
(check one)
Review the documented Risk If ‘yes,’ identify the Risk Mitigation Not Applicable
Mitigation and Migration Plan to and Migration Plan document(s)
verify it includes: examined to verify that it includes:
 Description of usage,  Description of usage, including; what
including; what data is data is being transmitted, types and
being transmitted, types number of systems that use and/or
and number of systems support SSL/early TLS, type of
that use and/or support environment;
SSL/early TLS, type of  Risk assessment results and risk
environment; reduction controls in place;
 Risk assessment results  Description of processes to monitor
and risk reduction for new vulnerabilities associated
controls in place; with SSL/early TLS;
 Description of processes  Description of change control
to monitor for new processes that are implemented to
vulnerabilities associated ensure SSL/early TLS is not
with SSL/early TLS; implemented into new environments;
 Description of change  Overview of migration project plan
control processes that are including target migration completion
implemented to ensure date no later than 30th June 2016.
SSL/early TLS is not
implemented into new
environments;
 Overview of migration
project plan including
target migration
completion date no later
than 30th June 2016.
(check one)
2.2.4 Configure system security parameters to prevent misuse. ☐ ☐ ☒ ☐ ☐
2.2.4.a Interview system Identify the system administrators marking all of req 2 as n/a. this is the response
administrators and/or security and/or security managers interviewed
managers to verify that they for this testing procedure.
have knowledge of common For the interview, summarize the Not Applicable
security parameter settings for relevant details discussed to verify that
system components. they have knowledge of common
security parameter settings for system
components.
2.2.4.b Examine the system Identify the system configuration Not Applicable
configuration standards to standards examined to verify that
verify that common security common security parameter settings are
parameter settings are included.
included.
2.2.4.c Select a sample of Identify the sample of system Not Applicable
inspect the common security For each item in the sample, describe Not Applicable
parameters to verify that they how the common security parameters
are set appropriately and in were inspected to verify that they are
accordance with the set appropriately and in accordance
configuration standards. with the configuration standards.
2.2.5 Remove all unnecessary functionality, such as scripts, drivers, features, subsystems, file
☐ ☐ ☒ ☐ ☐
systems, and unnecessary web servers.
(check one)
inspect the configurations to For each item in the sample, describe Not Applicable
verify that all unnecessary how the configurations were inspected
functionality (for example, to verify that all unnecessary
scripts, drivers, features, functionality is removed.
subsystems, file systems, etc.)
is removed.
2.2.5.b. Examine the Describe how the security parameters were examined with relevant documentation to verify that enabled functions are:
documentation and security
 Documented Not Applicable
parameters to verify enabled
functions are documented and  Support secure configuration Not Applicable
support secure configuration.

2.2.5.c. Examine the Identify documentation examined for Not Applicable
documentation and security this testing procedure.
parameters to verify that only Describe how the security parameters Not Applicable
documented functionality is were examined with relevant
present on the sampled system documentation to verify that only
components. documented functionality is present on
the sampled system components from
2.2.5.a.
(check one)
2.3 Encrypt all non-console administrative access using strong cryptography. Use technologies
such as SSH, VPN, or TLS for web-based management and other non-console administrative
access.
and/or early TLS must have a formal Risk Mitigation and Migration Plan in place. ☐ ☐ ☒ ☐ ☐
2.3 Select a sample of system Identify the sample of system marking all of req 2 as n/a. this is the response
components and verify that components selected for 2.3.a-2.3.d to
non-console administrative verify that non-console administrative
access is encrypted by access is encrypted
performing the following:
For each item in the sample from 2.3:
(check one)
2.3.a Observe an administrator Describe how the administrator log on Not Applicable
log on to each system and for each system was observed to verify
examine system configurations that a strong encryption method is
to verify that a strong invoked before the administrator’s
encryption method is invoked password is requested.
before the administrator’s Describe how system configurations Not Applicable
password is requested. for each system were examined to
verify that a strong encryption method is
invoked before the administrator’s
password is requested.
Identify the strong encryption Not Applicable
method used for non-console
administrative access.
2.3.b Review services and For each item in the sample from 2.3:
parameter files on systems to Describe how services on systems Not Applicable
determine that Telnet and other were reviewed to determine that Telnet
insecure remote-login and other insecure remote-login
commands are not available for commands are not available for non-
non-console access. console access.
Describe how parameter files on Not Applicable
systems were reviewed to determine
that Telnet and other insecure remote-
login commands are not available for
non-console access.
For each item in the sample from 2.3:
(check one)
2.3.c Observe an administrator Describe how the administrator log on Not Applicable
log on to each system to verify to each system was observed to verify
that administrator access to that administrator access to any web-
any web-based management based management interfaces was
interfaces is encrypted with encrypted with strong cryptography.
strong cryptography. Identify the strong encryption Not Applicable
method used for any web-based
management interfaces.
2.3.d Examine vendor Identify the vendor documentation Not Applicable
documentation and interview examined to verify that strong
personnel to verify that strong cryptography for the technology in use
cryptography for the technology is implemented according to industry
in use is implemented best practices and/or vendor
according to industry best recommendations.
(check one)
practices and/or vendor Identify the personnel interviewed for Not Applicable
recommendations. this testing procedure.
that strong cryptography for the
technology in use is implemented
according to industry best practices
and/or vendor recommendations.
2.3.e For POS POI terminals Indicate whether the assessed entity Not Applicable
protocols: If ‘no,’ mark the remainder of 2.3.e as
Confirm that the entity has ‘not applicable.’
documentation (for example, If ‘yes,’ identify the document(s) Not Applicable
vendor documentation, examined to verify that the entity
system/network configuration
maintains documentation that verifies
details, etc.) that verifies the
devices are not susceptible to the devices are not susceptible to any
any known exploits for known exploits for SSL/early TLS.
SSL/early TLS.
(check one)
2.3.f For all other environments Indicate whether the assessed entity Not Applicable
using SSL and/or early TLS: includes any other environments using
Review the documented Risk SSL and/or early TLS (yes/no)
Mitigation and Migration Plan to If ‘no,’ mark the remainder of 2.3.f as
verify it includes: ‘not applicable.’
(check one)
 Description of usage, If ‘yes,’ identify the Risk Mitigation Not Applicable

including; what data is and Migration Plan document(s)
being transmitted, types examined to verify that it includes:
and number of systems  Description of usage, including; what
that use and/or support data is being transmitted, types and
SSL/early TLS, type of number of systems that use and/or
environment; support SSL/early TLS, type of
 Risk assessment results environment;
and risk reduction controls  Risk assessment results and risk
in place; reduction controls in place;
 Description of processes  Description of processes to monitor
to monitor for new for new vulnerabilities associated
vulnerabilities associated with SSL/early TLS;
with SSL/early TLS;  Description of change control
 Description of change processes that are implemented to
control processes that are ensure SSL/early TLS is not
implemented to ensure implemented into new environments;
SSL/early TLS is not  Overview of migration project plan
implemented into new including target migration completion
environments; date no later than 30th June 2016.
target migration
2.4 Maintain an inventory of system components that are in scope for PCI DSS. ☐ ☐ ☒ ☐ ☐
Describe how the system inventory was examined to verify that a list of hardware and software components is:
(check one)
2.4.a Examine system  Maintained marking all of req 2 as n/a. this is the response
inventory to verify that a list of  Includes a description of function/use Not Applicable
hardware and software for each
components is maintained and
includes a description of
function/use for each.
2.4.b Interview personnel to Identify the personnel interviewed for Not Applicable
verify the documented this testing procedure.
inventory is kept current. For the interview, summarize the Not Applicable
that the documented inventory is kept
current.
2.5 Ensure that security policies and operational procedures for managing vendor defaults and
☐ ☐ ☒ ☐ ☐
other security parameters are documented, in use, and known to all affected parties.
2.5 Examine documentation Identify the document reviewed to marking all of req 2 as n/a. this is the response
verify that security policies and operational procedures for managing
operational procedures for vendor defaults and other security
parameters are documented.
(check one)
managing vendor defaults and Identify responsible personnel Not Applicable

other security parameters are: interviewed who confirm that the above
 Documented, documented security policies and
operational procedures for managing
 In use, and
vendor defaults and other security
 Known to all affected parties. parameters are:
 In use
2.6 Shared hosting providers must protect each entity’s hosted environment and cardholder data.
These providers must meet specific requirements as detailed in Appendix A: Additional PCI DSS ☒ ☐ ☐ ☐ ☐
Requirements for Shared Hosting Providers.
2.6 Perform testing procedures Indicate whether the assessed entity is Yes
A.1.1 through A.1.4 detailed in a shared hosting provider. (yes/no)
Appendix A: Additional PCI If “yes,” provide the name of the
DSS Requirements for Shared assessor who attests that Appendix A:
Hosting Providers for PCI DSS Additional PCI DSS Requirements for
assessments of shared hosting Shared Hosting Providers has been
providers, to verify that shared completed.
hosting providers protect their
entities’ (merchants and service
providers) hosted environment
and data.
Protect Stored Cardholder Data
Requirement 3: Protect stored cardholder data
(check one)
3.1 Keep cardholder data storage to a minimum by implementing data-retention and disposal
policies, procedures and processes that include at least the following for all CHD storage:
 Limiting data storage amount and retention time to that which is required for legal, regulatory,
and/or business requirements.
 Specific retention requirements for cardholder data ☐ ☐ ☐ ☒ ☐
 Processes for secure deletion of data when no longer needed.
 A quarterly process for identifying and securely deleting stored cardholder data that exceeds
defined retention.
(check one)
3.1.a Examine the data- Identify the data-retention and marking all of req 3 as NT. This is the mark all resp
retention and disposal policies, disposal documentation examined to
procedures and processes to verify policies, procedures, and
verify they include the following processes define the following for all
for all cardholder data (CHD) cardholder data (CHD) storage:
storage:  Limiting data storage amount and
 Limiting data storage retention time to that which is
amount and retention time to required for legal, regulatory,
that which is required for and/or business requirements for
legal, regulatory, and/or data retention.
business requirements.  Specific requirements for retention
 Specific requirements for of cardholder data.
retention of cardholder data  Processes for secure deletion of
(for example, cardholder cardholder data when no longer
data needs to be held for X needed for legal, regulatory, or
period for Y business business reasons.
reasons).  A quarterly process for identifying
 Processes for secure and securely deleting stored
deletion of cardholder data cardholder data that exceeds
when no longer needed for defined retention requirements.
legal, regulatory, or business
reasons
 A quarterly process for
identifying and securely
deleting stored cardholder
data that exceeds defined
retention requirements.
(check one)
3.1.b Interview personnel to Identify the personnel interviewed Not Tested

verify that: who confirm that:
 All locations of stored  All locations of stored cardholder
cardholder data are included data are included in the data-
in the data-retention and retention and disposal processes.
disposal processes.  Either a quarterly automatic or
 Either a quarterly automatic manual process is in place to
or manual process is in identify and securely delete stored
place to identify and cardholder data.
securely delete stored  The quarterly automatic or manual
cardholder data. process is performed for all
 The quarterly automatic or locations of cardholder data.
manual process is For the interview, summarize the relevant details discussed that verify the following:
performed for all locations of  All locations of stored cardholder Not Tested
cardholder data. data are included in the data-
retention and disposal process.
 Either a quarterly automatic or Not Tested
manual process is in place to identify
and securely delete stored
cardholder data.
 The quarterly automatic or manual Not Tested
process is performed for all locations
of cardholder data.
Describe the quarterly process in place Not Tested
to identify and securely delete stored
cardholder data, including whether it is
an automatic or manual process.
(check one)
3.1.c For a sample of system Identify the sample of system Not Tested
components that store components selected.
cardholder data: For each item in the sample, describe Not Tested
 Examine files and system how files and system records were
records to verify that the examined to verify that the data stored
data stored does not exceed does not exceed the requirements
the requirements defined in defined in the data-retention policy.
the data-retention policy. Describe how the deletion mechanism Not Tested
 Observe the deletion was observed to verify data is deleted
mechanism to verify data is securely.
deleted securely.
3.2 Do not store sensitive authentication data after authorization (even if encrypted). If sensitive
authentication data is received, render all data unrecoverable upon completion of the
authorization process.
It is permissible for issuers and companies that support issuing services to store sensitive
authentication data if: ☐ ☐ ☐ ☒ ☐
 There is a business justification, and
 The data is stored securely.
Sensitive authentication data includes the data as cited in the following Requirements 3.2.1
through 3.2.3:
3.2.a For issuers and/or Indicate whether the assessed entity is marking all of req 3 as NT. This is the mark all resp
companies that support issuing an issuer or supports issuing service.
services and store sensitive (yes/no)
(check one)
authentication data, review 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.”
policies and interview 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.
personnel to verify there is a Identify the documentation reviewed Not Applicable
documented business to verify there is a documented
justification for the storage of business justification for the storage of
sensitive authentication data. sensitive authentication data.
Identify the interviewed personnel Not Applicable
who confirm there is a documented
business justification for the storage of
sensitive authentication data.
relevant details of the business
justification described.
3.2.b For issuers and/or If “yes” at 3.2.a,
companies that support issuing Identify data stores examined. Not Applicable
services and store sensitive
Identify the system configurations Not Applicable
authentication data, examine
examined.
data stores and system
configurations to verify that the Describe how the data stores and Not Applicable
sensitive authentication data is system configurations were examined to
secured. verify that the sensitive authentication
data is secured.
3.2.c For all other entities, if Indicate whether sensitive Not Applicable
sensitive authentication data is authentication data is received.
received, review policies and (yes/no)
procedures, and examine If “yes,” complete 3.2.c and 3.2.d.
system configurations to verify If “no,” mark the remainder of 3.2.c and 3.2.d as “Not Applicable” and proceed to 3.2.1.
(check one)
the data is not retained after Identify the document(s) reviewed to Not Applicable
authorization. verify that it defines that data is not
retained after authorization.
Describe how system configurations Not Applicable
were examined to verify the data is not
retained after authorization.
3.2.d For all other entities, if Identify the document(s) reviewed to Not Applicable
sensitive authentication data is verify that it defines processes for
received, review procedures securely deleting the data to verify that
and examine the processes for the data is unrecoverable.
securely deleting the data to Describe how the processes for Not Applicable
verify that the data is securely deleting the data were
unrecoverable. examined to verify that the data is
unrecoverable.
3.2.1 Do not store the full contents of any track (from the magnetic stripe located on the back of a
card, equivalent data contained on a chip, or elsewhere) after authorization. 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.1 For a sample of system Identify the sample of system marking all of req 3 as NT. This is the mark all resp
components, examine data components selected for 3.2.1-3.2.3.
(check one)
sources, including but not For each data source type below from the sample of system of components examined, summarize the specific examples of each
limited to the following, and 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.
verify that the full contents of
any track from the magnetic  Incoming transaction data Not Tested
stripe on the back of card or  All logs (for example, transaction, Not Tested
equivalent data on a chip are history, debugging error)
not stored after authorization:
 History files Not Tested
 Incoming transaction data
 All logs (for example,
 Trace files Not Tested
transaction, history,  Database schemas Not Tested

debugging, error)  Database contents Not Tested
 History files
 If applicable, any other output Not Tested
 Trace files
observed to be generated
 Several database schemas
 Database contents
3.2.2 Do not store the card verification code or value (three-digit or four-digit number printed on
the front or back of a payment card) used to verify card-not-present transactions after ☐ ☐ ☐ ☒ ☐
authorization.
3.2.2 For a sample of system For each data source type below from the sample of system of components at 3.2.1, summarize the specific examples of each
components, examine data 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,
sources, including but not
indicate that in the space.
limited to the following, and
verify that the three-digit or  Incoming transaction data marking all of req 3 as NT. This is the mark all resp
four-digit card verification code  All logs (for example, transaction, Not Tested
or value printed on the front of history, debugging error)
the card or the signature panel
 History files Not Tested
(CVV2, CVC2, CID, CAV2
 Trace files Not Tested
(check one)
data) is not stored after  Database schemas Not Tested

authorization:  Database contents Not Tested
 Incoming transaction data
 All logs (for example,
transaction, history,
debugging, error)
 History files
 Trace files
3.2.3 Do not store the personal identification number (PIN) or the encrypted PIN block after
☐ ☐ ☐ ☒ ☐
authorization.
3.2.3 For a sample of system For each data source type below from the sample of system of components at 3.2.1, summarize the specific examples of each
data source type observed. If that type of data source is not present, indicate that in the space.
components, examine data
sources, including but not  Incoming transaction data marking all of req 3 as NT. This is the mark all resp
limited to the following and  All logs (for example, transaction, Not Tested
verify that PINs and encrypted history, debugging error)
PIN blocks are not stored after
authorization:  History files Not Tested
 Incoming transaction data  Trace files Not Tested
 All logs (for example,  Database schemas Not Tested

transaction, history,  Database contents Not Tested
debugging, error)
 History files
 Trace files
(check one)
3.3 Mask PAN when displayed (the first six and last four digits are the maximum number of digits
to be displayed), such that only personnel with a legitimate business need can see the full PAN.
Note: This requirement does not supersede stricter requirements in place for displays of ☐ ☐ ☐ ☒ ☐
cardholder data—for example, legal or payment card brand requirements for point-of-sale (POS)
receipts.
3.3.a Examine written policies Identify the document(s) reviewed to marking all of req 3 as NT. This is the mark all resp
and procedures for masking the verify that written policies and
display of PANs to verify: procedures for masking the displays of
 A list of roles that need PANs include the following:
access to displays of full  A list of roles that need access to
PAN is documented, displays of full PAN is
together with a legitimate documented, together with a
business need for each role legitimate business need for each
to have such access. role to have such access.
 PAN must be masked when  PAN must be masked when
displayed such that only displayed such that only personnel
personnel with a legitimate with a legitimate business need
business need can see the can see the full PAN.
full PAN.  All other roles not specifically
 All other roles not authorized to see the full PAN
specifically authorized to see must only see masked PANs.
the full PAN must only see
masked PANs.
3.3.b Examine system Describe how system configurations were examined to verify that:
configurations to verify that full  Full PAN is only displayed for Not Tested
PAN is only displayed for users/roles with a documented
users/roles with a documented business need.
(check one)
business need, and that PAN is  PAN is masked for all other requests. Not Tested
masked for all other requests.
3.3.c Examine displays of PAN Describe how displays of PAN were examined to verify that:
(for example, on screen, on  PANs are masked when displaying Not Tested
paper receipts) to verify that cardholder data.
PANs are masked when
 Only those with a legitimate business Not Tested
displaying cardholder data, and
need are able to see full PAN.
that only those with a legitimate
business need are able to see
full PAN.
3.4 Render PAN unreadable anywhere it is stored (including on portable digital media, backup
media, and in logs) by using any of the following approaches:
 One-way hashes based on strong cryptography, (hash must be of the entire PAN).
 Truncation (hashing cannot be used to replace the truncated segment of PAN).
 Index tokens and pads (pads must be securely stored).
 Strong cryptography with associated key-management processes and procedures. ☐ ☐ ☐ ☒ ☐
Note: It is a relatively trivial effort for a malicious individual to reconstruct original PAN data if they
have access to both the truncated and hashed version of a PAN. Where hashed and truncated
versions of the same PAN are present in an entity’s environment, additional controls must be in
place to ensure that the hashed and truncated versions cannot be correlated to reconstruct the
original PAN.
3.4.a Examine documentation Identify the documentation examined marking all of req 3 as NT. This is the mark all resp
about the system used to about the system used to protect the
protect the PAN, including the PAN.
(check one)
vendor, type of Briefly describe the documented Not Tested

system/process, and the methods—including the vendor, type of
encryption algorithms (if system/process, and then encryption
applicable) to verify that the algorithms (if applicable)— used to
PAN is rendered unreadable protect the PAN.
using any of the following Identify which of the following methods Not Tested
methods: is used to render the PAN unreadable:
 One-way hashes based on  One-way hashes based on strong
strong cryptography, cryptography
 Truncation  Truncation
 Index tokens and pads, with  Index token and pads, with the
the pads being securely pads being securely stored
stored  Strong cryptography, with
 Strong cryptography, with associated key-management
associated key-management processes and procedures
processes and procedures
3.4.b Examine several tables or Identify the sample of data Not Tested
files from a sample of data repositories selected.
repositories to verify the PAN is Identify the tables or files examined
rendered unreadable (that is, for each item in the sample of data
not stored in plain-text). repositories.
For each item in the sample, describe Not Tested
how the table or file was examined to
verify the PAN is rendered unreadable.
3.4.c Examine a sample of Identify the sample of removable Not Tested
removable media (for example, media selected.
(check one)
backup tapes) to confirm that For each item in the sample, describe Not Tested
the PAN is rendered how the sample of removable media
unreadable. was examined to confirm that the PAN
is rendered unreadable.
3.4.d Examine a sample of Identify the sample of audit logs Not Tested
audit logs to confirm that the selected.
PAN is rendered unreadable or For each item in the sample, describe Not Tested
removed from the logs. how the sample of audit logs was
examined to confirm that the PAN is
rendered unreadable or removed from
the logs.
3.4.e If hashed and truncated versions of Identify whether hashed and truncated Not Tested
the same PAN are present in the
environment, examine implemented versions of the same PAN are present
controls to verify that the hashed and in the environment (yes/no)
truncated versions cannot be correlated to
reconstruct the original PAN. If ‘no,’ mark 3.4.e as ‘not applicable’ and
proceed to 3.4.1.
If ‘yes,’ describe the implemented Not Applicable
controls examined to verify that the
hashed and truncated versions cannot
be correlated to reconstruct the original
PAN.
3.4.1 If disk encryption is used (rather than file- or column-level database encryption), logical
access must be managed separately and independently of native operating system authentication
☐ ☐ ☐ ☒ ☐
and access control mechanisms (for example, by not using local user account databases or
general network login credentials). Decryption keys must not be associated with user accounts.
(check one)
3.4.1.a If disk encryption is Indicate whether disk encryption is marking all of req 3 as NT. This is the mark all resp
used, inspect the configuration used. (yes/no)
and observe the authentication If “yes,” complete the remainder of 3.4.1.a, 3.4.1.b, and 3.4.1.c.
process to verify that logical If “no,” mark the remainder of 3.4.1.a, 3.4.1.b and 3.4.1.c as “Not Applicable.’
access to encrypted file
systems is implemented via a Describe the disk encryption Not Applicable
mechanism that is separate mechanism(s) in use.

from the native operating For each disk encryption mechanism in Not Applicable
system’s authentication use, describe how the configuration
mechanism (for example, not was inspected and the authentication
using local user account process observed to verify that logical
databases or general network access to encrypted file systems is
login credentials). separate from the native operating
system’s authentication mechanism.
3.4.1.b Observe processes and Describe how processes were Not Applicable
interview personnel to verify observed to verify that cryptographic
that cryptographic keys are keys are stored securely.
stored securely (for example, Identify the personnel interviewed who Not Applicable
stored on removable media that confirm that cryptographic keys are
is adequately protected with stored securely.
strong access controls).
Identify the configurations examined. Not Applicable
(check one)
3.4.1.c Examine the Describe how the configurations were Not Applicable
configurations and observe the examined and the processes observed
processes to verify that to verify that cardholder data on
cardholder data on removable removable media is encrypted wherever
media is encrypted wherever stored.
stored.
Note: If disk encryption is not
used to encrypt removable
media, the data stored on this
media will need to be rendered
unreadable through some other
method.
3.5 Document and implement procedures to protect keys used to secure stored cardholder data
against disclosure and misuse:
Note: This requirement applies to keys used to encrypt stored cardholder data, and also applies ☐ ☐ ☐ ☒ ☐
to key-encrypting keys used to protect data-encrypting keys—such key-encrypting keys must be
at least as strong as the data-encrypting key.
(check one)
3.5 Examine key-management Identify the documented key- marking all of req 3 as NT. This is the mark all resp
policies and procedures to management policies and processes
verify processes are specified examined to verify processes are
to protect keys used for defined to protect keys used for
encryption of cardholder data encryption of cardholder data against
against disclosure and misuse disclosure and misuse and include at
and include at least the least the following:
following:  Access to keys is restricted to the
 Access to keys is restricted fewest number of custodians
to the fewest number of necessary.
custodians necessary.  Key-encrypting keys are at least
 Key-encrypting keys are at as strong as the data-encrypting
least as strong as the data- keys they protect.
encrypting keys they protect.  Key-encrypting keys are stored
 Key-encrypting keys are separately from data-encrypting
stored separately from data- keys.
encrypting keys.  Keys are stored securely in the
 Keys are stored securely in fewest possible locations and
the fewest possible locations forms.
and forms.
3.5.1 Restrict access to cryptographic keys to the fewest number of custodians necessary. ☐ ☐ ☐ ☒ ☐
3.5.1 Examine user access lists Identify user access lists examined. marking all of req 3 as NT. This is the mark all resp
to verify that access to keys is Describe how user access lists were Not Tested
restricted to the fewest number examined to verify that access to keys
of custodians necessary. is restricted to the fewest number of
custodians necessary.
(check one)
3.5.2 Store secret and private keys used to encrypt/decrypt cardholder data 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 hardware/host security module (HSM) or PTS- ☐ ☐ ☐ ☒ ☐
approved point-of-interaction device).
 As at least two full-length key components or key shares, in accordance with an industry-
accepted method.
Note: It is not required that public keys be stored in one of these forms.
(check one)
3.5.2.a Examine documented Identify the documented procedures marking all of req 3 as NT. This is the mark all resp
procedures to verify that examined to verify that cryptographic
cryptographic keys used to keys used to encrypt/decrypt cardholder
encrypt/decrypt cardholder data data must only exist in one (or more) of
must only exist in one (or more) the following forms at all times.
of the following forms at all  Encrypted with a key-encrypting
times. key that is at least as strong as the
 Encrypted with a key- data-encrypting key, and that is
encrypting key that is at least stored separately from the data-
as strong as the data- encrypting key.
encrypting key, and that is  Within a secure cryptographic
stored separately from the device (such as a hardware (host)
data-encrypting key. security module (HSM) or PTS-
 Within a secure cryptographic approved point-of-interaction
device (such as a hardware device).
(host) security module (HSM)  As key components or key shares,
or PTS-approved point-of- in accordance with an industry-
interaction device). accepted method.
 As key components or key
shares, in accordance with
an industry-accepted method.
(check one)
3.5.2.b Examine system Provide the name of the assessor Not Tested
configurations and key storage who attests that all locations where keys
locations to verify that are stored were identified.
cryptographic keys used to Describe how system configurations Not Tested
encrypt/decrypt cardholder data and key storage locations were
exist in one, (or more), of the examined to verify that cryptographic
following form at all times. keys used to encrypt/decrypt cardholder
 Encrypted with a key- data must only exist in one (or more) of
encrypting key. the following forms at all times.
 Within a secure cryptographic  Encrypted with a key-encrypting
device (such as a hardware key that is at least as strong as the
(host) security module (HSM) data-encrypting key, and that is
or PTS-approved point-of- stored separately from the data-
interaction device). encrypting key.
 As key components or key
 Within a secure cryptographic
shares, in accordance with device (such as a hardware (host)
an industry-accepted method. 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- Describe how system configurations and key storage locations were examined to verify that, wherever key-encrypting keys are
encrypting keys are used, used:
examine system configurations  Key-encrypting keys are at least as Not Tested
and key storage locations to strong as the data-encrypting keys
verify: they protect
(check one)
 Key-encrypting keys are at  Key-encrypting keys are stored Not Tested
least as strong as the data- separately from data-encrypting
encrypting keys they protect. keys.
 Key-encrypting keys are
stored separately from data-
encrypting keys.
3.5.3 Store cryptographic keys in the fewest possible locations. ☐ ☐ ☐ ☒ ☐
3.5.3 Examine key storage Describe how key storage locations marking all of req 3 as NT. This is the mark all resp
locations and observe were examined and processes were
processes to verify that keys observed to verify that keys are stored
are stored in the fewest in the fewest possible locations.
possible locations.
3.6 Fully document and implement all key-management processes and procedures for
cryptographic keys used for encryption of cardholder data, including the following:
☐ ☐ ☐ ☒ ☐
Note: Numerous industry standards for key management are available from various resources
including NIST, which can be found at http://csrc.nist.gov.
3.6.a Additional Procedure Indicate whether the assessed entity is marking all of req 3 as NT. This is the mark all resp
for service provider a service provider that shares keys with
assessments only: If the their customers for transmission or
service provider shares keys storage of cardholder data. (yes/no)
(check one)
with their customers for If “yes,” Identify the document that the Not Applicable
transmission or storage of service provider provides to their
cardholder data, examine the customers examined to verify that it
documentation that the service includes guidance on how to securely
provider provides to their transmit, store and update customers’
customers to verify that it keys, in accordance with Requirements
includes guidance on how to 3.6.1 through 3.6.8 below.
securely transmit, store, and
update customers’ keys, in
accordance with Requirements
3.6.1 through 3.6.8 below.
3.6.b Examine the key-management procedures and processes for keys used for encryption of cardholder data and perform the following:
3.6.1 Generation of strong cryptographic keys. ☐ ☐ ☐ ☒ ☐
3.6.1.a Verify that key- Identify the documented key- marking all of req 3 as NT. This is the mark all resp
management procedures management procedures examined to
specify how to generate strong verify procedures specify how to
keys. generate strong keys.
3.6.1.b Observe the method for Describe how the method for Not Tested
generating keys to verify that generating keys was observed to verify
strong keys are generated. that strong keys are generated.
3.6.2 Secure cryptographic key distribution. ☐ ☐ ☐ ☒ ☐
management procedures management procedures examined to
specify how to securely verify procedures specify how to
distribute keys. securely distribute keys.
(check one)
3.6.2.b Observe the method for Describe how the method for Not Tested
distributing keys to verify that distributing keys was observed to verify
keys are distributed securely. that keys are distributed securely.
3.6.3 Secure cryptographic key storage. ☐ ☐ ☐ ☒ ☐
management procedures management procedures examined
specify how to securely store to verify procedures specify how to
keys. securely store keys.
3.6.3.b Observe the method for Describe how the method for storing Not Tested
storing keys to verify that keys keys was observed to verify that keys
are stored securely. are stored securely.
3.6.4 Cryptographic key changes for keys that have reached the end of their cryptoperiod (for
example, after a defined period of time has passed and/or after a certain amount of cipher-text
has been produced by a given key), as defined by the associated application vendor or key ☐ ☐ ☐ ☒ ☐
owner, and based on industry best practices and guidelines (for example, NIST Special
Publication 800-57).
3.6.4.a Verify that key- Identify the document that defines: marking all of req 3 as NT. This is the mark all resp
management procedures  Key cryptoperiod(s) for each key
include a defined cryptoperiod type in use
for each key type in use and  A process for key changes at the
define a process for key end of the defined cryptoperiod(s)
changes at the end of the
defined cryptoperiod(s).
3.6.4.b Interview personnel to Identify personnel interviewed for this Not Tested
verify that keys are changed at testing procedure who confirm that keys
the end of the defined are changed at the end of the defined
cryptoperiod(s). cryptoperiod(s).
(check one)
3.6.5 Retirement or replacement (for example, archiving, destruction, and/or revocation) of keys
as deemed necessary when the integrity of the key has been weakened (for example, departure
of an employee with knowledge of a clear-text key component), or keys are suspected of being
compromised. ☐ ☐ ☐ ☒ ☐
Note: If retired or replaced cryptographic keys need to be retained, these keys must be securely
archived (for example, by using a key-encryption key). Archived cryptographic keys should only
be used for decryption/verification purposes.
3.6.5.a Verify that key- Identify the key-management marking all of req 3 as NT. This is the mark all resp
management procedures document examined to verify that key-
specify processes for the management processes specify the
following: following:
 The retirement or  The retirement or replacement of
replacement of keys when keys when the integrity of the key
the integrity of the key has has been weakened.
been weakened.  The replacement of known or
 The replacement of known or suspected compromised keys.
suspected compromised  Any keys retained after retiring or
keys. replacing are not used for
 Any keys retained after
encryption operations.
retiring or replacing are not
used for encryption
operations.
(check one)
3.6.5.b Interview personnel to Identify the personnel interviewed for Not Tested
verify the following processes this testing procedure.
are implemented: For the interview, summarize the relevant details discussed that verify the following processes are implemented:
 Keys are retired or replaced
 Keys are retired or replaced as Not Tested
as necessary when the
necessary when the integrity of the
integrity of the key has been
key has been weakened, including
weakened, including when
when someone with knowledge of
someone with knowledge of
the key leaves the company.
the key leaves the company.
 Keys are replaced if known or
 Keys are replaced if known or Not Tested
suspected to be suspected to be compromised.

compromised.  Any keys retained after retiring or Not Tested
 Any keys retained after replacing are not used for encryption
retiring or replacing are not operations.
used for encryption
operations.
3.6.6 If manual clear-text cryptographic key-management operations are used, these operations
must be managed using split knowledge and dual control.
☐ ☐ ☐ ☒ ☐
Note: Examples of manual key-management operations include, but are not limited to: key
generation, transmission, loading, storage and destruction.
3.6.6.a Verify that manual Indicate whether manual clear-text marking all of req 3 as NT. This is the mark all resp
clear-text key-management cryptographic key-management
procedures specify processes operations are used. (yes/no)
for the use of the following: If “no,” mark the remainder of 3.6.6.a and 3.6.6.b as “Not Applicable.”
If “yes,” complete 3.6.6.a and 3.6.6.b.
(check one)
 Split knowledge of keys, such Identify the document examined to Not Applicable
that key components are verify that manual clear-text key-
under the control of at least management procedures define
two people who only have processes for the use of the following:
knowledge of their own key  Split knowledge of keys, such that
components; AND key components are under the
 Dual control of keys, such control of at least two people who
that at least two people are only have knowledge of their own
required to perform any key- key components; AND
management operations and
 Dual control of keys, such that at
no one person has access to
least two people are required to
the authentication materials
perform any key-management
(for example, passwords or
operations and no one person has
keys) of another.
access to the authentication
materials of another.
3.6.6 b Interview personnel Identify the personnel interviewed for Not Applicable
and/or observe processes to this testing procedure, if applicable.
verify that manual clear-text For the interview, summarize the relevant details discussed and/or describe how processes were observed to verify the
keys are managed with: following processes are implemented:
 Split knowledge, AND  Split knowledge Not Applicable
 Dual control
 Dual Control Not Applicable
3.6.7 Prevention of unauthorized substitution of cryptographic keys. ☐ ☐ ☐ ☒ ☐
3.6.7.a Verify that key- Identify the document examined to marking all of req 3 as NT. This is the mark all resp
management procedures verify that key-management procedures
specify processes to prevent specify processes to prevent
unauthorized substitution of unauthorized substitution of keys.
keys.
(check one)
3.6.7.b Interview personnel Identify the personnel interviewed for Not Tested
and/or observe process to this testing procedure, if applicable.
verify that unauthorized For the interview, summarize the Not Tested
substitution of keys is relevant details discussed and/or
prevented. describe how processes were
observed to verify that unauthorized
substitution of keys is prevented.
3.6.8 Requirement for cryptographic key custodians to formally acknowledge that they understand
☐ ☐ ☐ ☒ ☐
and accept their key-custodian responsibilities.
3.6.8.a Verify that key- Identify the document examined to marking all of req 3 as NT. This is the mark all resp
management procedures verify that key-management procedures
specify processes for key specify processes for key custodians to
custodians to acknowledge (in acknowledge that they understand and
writing or electronically) that accept their key-custodian
they understand and accept responsibilities.
their key-custodian
responsibilities.
3.6.8.b Observe documentation Describe how key custodian Not Tested
or other evidence showing that acknowledgements or other evidence
key custodians have were observed to verify that key
acknowledged (in writing or custodians have acknowledged that
electronically) that they they understand and accept their key-
understand and accept their custodian responsibilities.
key-custodian responsibilities.
(check one)
3.7 Ensure that security policies and operational procedures for protecting stored cardholder data
☐ ☐ ☐ ☒ ☐
are documented, in use, and known to all affected parties.
3.7 Examine documentation Identify the document reviewed to marking all of req 3 as NT. This is the mark all resp
verify that security policies and operational procedures for protecting
operational procedures for stored cardholder data are documented.
protecting stored cardholder Identify responsible personnel Not Tested
data are: interviewed who confirm that the above
 In use, and operational procedures for protecting
stored cardholder data are:
 In use
Requirement 4: Encrypt transmission of cardholder data across open, public networks
(check one)
and Testing Procedures Reporting Instruction Assessor’s Response Place w/CCW N/A Tested Place
4.1 Use strong cryptography and security protocols (for example, TLS, IPSEC, SSH, etc.) to
safeguard sensitive cardholder data during transmission over open, public networks, including the
following:
 Only trusted keys and certificates are accepted.
 The protocol in use only supports secure versions or configurations.
 The encryption strength is appropriate for the encryption methodology in use.
and/or early TLS must have a formal Risk Mitigation and Migration Plan in place.
☐ ☐ ☐ ☐ ☒
Examples of open, public networks include but are not limited to:
 The Internet
 Wireless technologies, including 802.11 and Bluetooth
 Cellular technologies, for example, Global System for Mobile communications (GSM), Code
division multiple access (CDMA)
 General Packet Radio Service (GPRS)
 Satellite communications
4.1.a Identify all locations Identify all locations where cardholder
where cardholder data is data is transmitted or received over
transmitted or received over open, public networks.
(check one)
open, public networks. Identify the documented standards

Examine documented examined.
standards and compare to Describe how the documented standards were examined and compared to system configurations to verify the use of:
system configurations to verify
 Security protocols observed in use
the use of security protocols
and strong cryptography for all
 Strong cryptography for all locations
locations.
4.1.b Review documented Identify the document reviewed to
policies and procedures to verify that processes are specified for
verify processes are specified the following:
for the following:  For acceptance of only trusted
 For acceptance of only keys and/or certificates.
trusted keys and/or  For the protocol in use to only
certificates. support secure versions and
 For the protocol in use to configurations (that insecure
only support secure versions versions or configurations are not
and configurations (that supported).
insecure versions or  For implementation of proper
configurations are not encryption strength per the
supported). encryption methodology in use.
 For implementation of proper
encryption strength per the
encryption methodology in
use.
4.1.c Select and observe a Describe the sample of inbound and
sample of inbound and outbound transmissions observed as
outbound transmissions as they they occurred.
(check one)
occur to verify that all Describe how the samples of inbound

cardholder data is encrypted and outbound transmissions were
with strong cryptography during observed as they occurred to verify that
transit. all cardholder data is encrypted with
strong cryptography during transit.
4.1.d Examine keys and For all instances where cardholder data is transmitted or received over open, public networks:
certificates to verify that only Describe the mechanisms used to
trusted keys and/or certificates ensure that only trusted keys and/or
are accepted. certificates are accepted.
Describe how the mechanisms were
observed to accept only trusted keys
and/or certificates.
4.1.e Examine system For all instances where cardholder data Is transmitted or received over open, public networks, describe how system configurations
configurations to verify that the were observed to verify that the protocol is implemented:
protocol is implemented to use  To use only secure configurations.
only secure configurations and
 Does not support insecure versions
does not support insecure
or configurations.
versions or configurations.
4.1.f Examine system For each encryption methodology in use,
configurations to verify that the Identify vendor recommendations/best
proper encryption strength is practices for encryption strength.
implemented for the encryption
Identify the encryption strength
methodology in use. (Check
observed to be implemented.
vendor recommendations/best
practices.)
(check one)
4.1.g For TLS implementations, Indicate whether TLS is implemented No

examine system configurations to encrypt cardholder data over open,
to verify that TLS is enabled public networks in the CDE. (yes/no)
whenever cardholder data is If “yes,” for all instances where TLS is used to encrypt cardholder data over open, public networks, describe how system
transmitted or received. configurations were examined to verify that TLS is enabled whenever cardholder data is transmitted or received, as follows:
For example, for browser-  HTTPS appears as part of the Not Applicable
based implementations: browser URL.
 “HTTPS” appears as the  Cardholder data is only requested if Not Applicable
browser Universal Record HTTPS appears as part of the URL.
Locator (URL) protocol; and
 Cardholder data is only
requested if “HTTPS”
appears as part of the URL.
4.1.h For POS POI terminals Indicate whether the assessed entity Not answered
protocols: If ‘no,’ mark the remainder of 4.1.h as
Confirm that the entity has documentation ‘not applicable.’
(for example, vendor documentation,
system/network configuration details, etc.) If ‘yes,’ identify the document(s) Not Applicable
that verifies the devices are not examined to verify that the entity
susceptible to any known exploits for
SSL/early TLS. maintains documentation that verifies
the devices are not susceptible to any
known exploits for SSL/early TLS.
(check one)
4.1.i For all other environments Indicate whether the assessed entity Not answered
using SSL and/or early TLS: includes any other environments using
Review the documented Risk SSL and/or early TLS (yes/no)
Mitigation and Migration Plan to If ‘no,’ mark the remainder of 4.1.i as
verify it includes: ‘not applicable.’
(check one)
 Description of usage, If ‘yes,’ identify the Risk Mitigation Not Applicable

including; what data is and Migration Plan document(s)
being transmitted, types examined to verify that it includes:
and number of systems  Description of usage, including; what
that use and/or support data is being transmitted, types and
SSL/early TLS, type of number of systems that use and/or
environment; support SSL/early TLS, type of
 Risk assessment results environment;
and risk reduction controls  Risk assessment results and risk
in place; reduction controls in place;
 Description of processes  Description of processes to monitor
to monitor for new for new vulnerabilities associated
vulnerabilities associated with SSL/early TLS;
with SSL/early TLS;  Description of change control
 Description of change processes that are implemented to
control processes that are ensure SSL/early TLS is not
implemented to ensure implemented into new environments;
SSL/early TLS is not  Overview of migration project plan
implemented into new including target migration completion
environments; date no later than 30th June 2016.
target migration
(check one)
4.1.1 Ensure wireless networks transmitting cardholder data or connected to the cardholder data
environment, use industry best practices (for example, IEEE 802.11i) to implement strong
☐ ☐ ☐ ☐ ☒
encryption for authentication and transmission.
Note: The use of WEP as a security control is prohibited.
4.1.1 Identify all wireless Identify all wireless networks
networks transmitting transmitting cardholder data or
cardholder data or connected connected to the cardholder data
to the cardholder data environment.
environment. Examine Identify the documented standards
documented standards and examined to verify processes define the
compare to system following for all wireless networks
configuration settings to verify identified:
the following for all wireless
 Industry best practices (for
networks identified:
example, IEEE 802.11i) are used
 Industry best practices (for
to implement strong encryption for
example, IEEE 802.11i) are authentication and transmission.
used to implement strong
 Weak encryption is not used as a
encryption for authentication
security control for authentication
and transmission.
or transmission.
 Weak encryption (for
Describe how documented standards were examined and compared to system configuration settings to verify the following for all
example, WEP, SSL) is not
wireless networks identified:
used as a security control for
authentication or  Industry best practices are used to
transmission. implement strong encryption for
authentication and transmission.
 Weak encryption is not used as a
security control for authentication or
transmission.
(check one)
4.2 Never send unprotected PANs by end-user messaging technologies (for example, e-mail,
☐ ☐ ☐ ☐ ☒
instant messaging, SMS, chat, etc.).
4.2.a If end-user messaging Indicate whether end-user messaging Not answered
technologies are used to send technologies are used to send
cardholder data, observe cardholder data. (yes/no)
processes for sending PAN and If “no,” mark the remainder of 4.2.a as “Not Applicable” and proceed to 4.2.b.
examine a sample of outbound If “yes,” complete the following:
transmissions as they occur to
verify that PAN is rendered Describe how processes for sending Not Applicable
unreadable or secured with PAN were observed to verify that PAN

strong cryptography whenever is rendered unreadable or secured with
it is sent via end-user strong cryptography whenever it is sent
messaging technologies. via end-user messaging technologies.
Describe how the sample of outbound Not Applicable
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.
4.2.b Review written policies to If “yes” at 4.2.a:
verify the existence of a policy
Identify the policy document stating Not Applicable
stating that unprotected PANs
that unprotected PANs must not be sent
are not to be sent via end-user
via end-user messaging technologies.
messaging technologies.
If “no” at 4.2.a:
(check one)
Identify the policy document that Not Applicable

explicitly prohibits PAN from being sent
via end-user messaging technologies
under any circumstances.
4.3 Ensure that security policies and operational procedures for encrypting transmissions of
☐ ☐ ☐ ☐ ☒
cardholder data are documented, in use, and known to all affected parties.
verify that security policies and operational procedures for encrypting
operational procedures for transmissions of cardholder data are
encrypting transmissions of documented.
cardholder data are: Identify responsible personnel
operational procedures for encrypting
transmissions of cardholder data are:
 In use
Maintain a Vulnerability Management Program
Requirement 5: Protect all systems against malware and regularly update anti-virus software or programs
(check one)
In Place Not Not in
and Testing Procedures Reporting Instruction Assessor’s Response In Place w/ CCW N/A Tested Place
5.1 Deploy anti-virus software on all systems commonly affected by malicious software
☐ ☒ ☐ ☐ ☐
(particularly personal computers and servers).
5.1 For a sample of system Identify the sample of system
components including all components selected (including all
operating system types operating system types commonly
commonly affected by affected by malicious software).
malicious software, verify that For each item in the sample, describe
anti-virus software is deployed how anti-virus software was observed
if applicable anti-virus to be deployed.
technology exists.
5.1.1 Ensure that anti-virus programs are capable of detecting, removing, and protecting against
☐ ☒ ☐ ☐ ☐
all known types of malicious software.
5.1.1 Review vendor Identify the vendor documentation
documentation and examine reviewed to verify that anti-virus
anti-virus configurations to programs:
verify that anti-virus programs;  Detect all known types of
 Detect all known types of malicious software,
malicious software,  Remove all known types of
 Remove all known types of malicious software, and
malicious software, and  Protect against all known types of
 Protect against all known malicious software.
types of malicious software. Describe how anti-virus configurations were examined to verify that anti-virus programs:
(check one)
In Place Not Not in
(Examples of types of malicious software  Detect all known types of malicious
include viruses, Trojans, worms, spyware,
adware, and rootkits). software,
 Remove all known types of malicious
software, and
 Protect against all known types of
malicious software.
5.1.2 For systems considered to be not commonly affected by malicious software, perform
periodic evaluations to identify and evaluate evolving malware threats in order to confirm whether ☐ ☒ ☐ ☐ ☐
such systems continue to not require anti-virus software.
5.1.2 Interview personnel to Identify the personnel interviewed for
verify that evolving malware this testing procedure.
threats are monitored and For the interview, summarize the
evaluated for systems not relevant details discussed and/or
currently considered to be describe how processes were
commonly affected by observed to verify that evolving malware
malicious software, in order to threats are monitored and evaluated for
confirm whether such systems systems not currently considered to be
continue to not require anti- commonly affected by malicious
virus software. software, and that such systems
continue to not require anti-virus
software.
5.2 Ensure that all anti-virus mechanisms are maintained as follows:
 Are kept current.
☐ ☒ ☐ ☐ ☐
 Perform periodic scans.
 Generate audit logs which are retained per PCI DSS Requirement 10.7.
(check one)
In Place Not Not in
5.2.a Examine policies and Identify the documented policies and

procedures to verify that anti- procedures examined to verify that
virus software and definitions anti-virus software and definitions are
are required to be kept up-to- required to be kept up to date.
date.
5.2.b Examine anti-virus Describe how anti-virus configurations, including the master installation of the software, were examined to verify anti-virus
configurations, including the mechanisms are:
master installation of the
software, to verify anti-virus
mechanisms are:
 Configured to perform automatic
 Configured to perform automatic
updates, and
 Configured to perform periodic
updates, and
scans.  Configured to perform periodic
scans.
5.2.c Examine a sample of Identify the sample of system
system components, including components, including all operating
all operating system types system types commonly affected by
commonly affected by malicious software, selected for this
malicious software, to verify testing procedure.
that: Describe how system components were examined to verify that:
 The anti-virus software and  The anti-virus software and
definitions are current. definitions are current.
 Periodic scans are  Periodic scans are performed.
performed.
5.2.d Examine anti-virus Identify the sample of system
configurations, including the components selected for this testing
master installation of the procedure.
(check one)
In Place Not Not in
software and a sample of For each item in the sample, describe how anti-virus configurations, including the master installation of the software, were
system components, to verify examined to verify that:
that:  Anti-virus software log generation is
 Anti-virus software log enabled, and
generation is enabled, and  Logs are retained in accordance with
 Logs are retained in PCI DSS Requirement 10.7.
accordance with PCI DSS
Requirement 10.7.
5.3 Ensure that anti-virus mechanisms are actively running and cannot be disabled or altered by
users, unless specifically authorized by management on a case-by-case basis for a limited time
period.
Note: Anti-virus solutions may be temporarily disabled only if there is legitimate technical need,
☐ ☒ ☐ ☐ ☐
as authorized by management on a case-by-case basis. If anti-virus protection needs to be
disabled for a specific purpose, it must be formally authorized. Additional security measures may
also need to be implemented for the period of time during which anti-virus protection is not
active.
5.3.a Examine anti-virus Identify the sample of system
configurations, including the components selected.
master installation of the For each item in the sample, describe
software and a sample of how anti-virus configurations, including
system components, to verify the master installation of the software,
the anti-virus software is were examined to verify that the anti-
actively running. virus software is actively running.
(check one)
In Place Not Not in
5.3.b Examine anti-virus For each item in the sample from 5.3.a,
configurations, including the describe how anti-virus configurations,
master installation of the including the master installation of the
software and a sample of software, were examined to verify that
system components, to verify the anti-virus software cannot be
that the anti-virus software disabled or altered by users.
cannot be disabled or altered
by users.
5.3.c Interview responsible Identify the responsible personnel
personnel and observe interviewed who confirm that anti-virus
processes to verify that anti- software cannot be disabled or altered
virus software cannot be by users, unless specifically authorized
disabled or altered by users, by management on a case-by-case
unless specifically authorized basis for a limited time period.
by management on a case-by- Describe how the process was
case basis for a limited time observed to verify that anti-virus
period. software cannot be disabled or altered
by users, unless specifically authorized
by management on a case-by-case
basis for a limited time period.
(check one)
In Place Not Not in
5.4 Ensure that security policies and operational procedures for protecting systems against
☐ ☒ ☐ ☐ ☐
malware are documented, in use, and known to all affected parties.
verify that security policies and operational procedures for protecting
operational procedures for systems against malware are
protecting systems against documented.
malware are: Identify responsible personnel
operational procedures for protecting
systems against malware are:
 In use
Requirement 6: Develop and maintain secure systems and applications
(check one)
In Place Not Not in
6.1 Establish a process to identify security vulnerabilities, using reputable outside sources for
security vulnerability information, and assign a risk ranking (for example, as “high,” “medium,” or
“low”) to newly discovered security vulnerabilities.
Note: Risk rankings should be based on industry best practices as well as consideration of
potential impact. For example, criteria for ranking vulnerabilities may include consideration of the
CVSS base score, and/or the classification by the vendor, and/or type of systems affected.
Methods for evaluating vulnerabilities and assigning risk ratings will vary based on an ☐ ☐ ☐ ☒
organization’s environment and risk assessment strategy. Risk rankings should, at a minimum,
identify all vulnerabilities considered to be a “high risk” to the environment. In addition to the risk
ranking, vulnerabilities may be considered “critical” if they pose an imminent threat to the
environment, impact critical systems, and/or would result in a potential compromise if not
addressed. Examples of critical systems may include security systems, public-facing devices and
systems, databases, and other systems that store, process, or transmit cardholder data.
6.1.a Examine policies and Identify the documented policies
procedures to verify that and procedures examined to confirm
processes are defined for the that processes are defined:
following:  To identify new security
 To identify new security vulnerabilities.
vulnerabilities.  To assign a risk ranking to
 To assign a risk ranking to vulnerabilities that includes
vulnerabilities that includes identification of all “high risk” and
identification of all “high risk” “critical” vulnerabilities.
and “critical” vulnerabilities.  To include using reputable outside
 To include using reputable sources for security vulnerability
outside sources for security information.
vulnerability information.
(check one)
In Place Not Not in
6.1.b Interview responsible Identify the responsible personnel

personnel and observe interviewed who confirm that:
processes to verify that:  New security vulnerabilities are
 New security vulnerabilities identified.
are identified.  A risk ranking is assigned to
 A risk ranking is assigned to vulnerabilities that includes
vulnerabilities that includes identification of all “high” risk and
identification of all “high” risk “critical” vulnerabilities.
and “critical” vulnerabilities.  Processes to identify new security
 Processes to identify new vulnerabilities include using
security vulnerabilities reputable outside sources for
include using reputable security vulnerability information.
outside sources for security 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.
 Processes to identify new security
vulnerabilities include using reputable
outside sources for security
Identify the outside sources used.
(check one)
In Place Not Not in
6.2 Ensure that all system components and software are protected from known vulnerabilities by
installing applicable vendor-supplied security patches. Install critical security patches within one
month of release. ☐ ☐ ☐ ☐ ☒
Note: Critical security patches should be identified according to the risk ranking process defined
in Requirement 6.1.
6.2.a Examine policies and Identify the documented policies
procedures related to security- and procedures related to security-
patch installation to verify patch installation examined to verify
processes are defined for: processes are defined for:
 Installation of applicable  Installation of applicable critical
critical vendor-supplied vendor-supplied security patches
security patches within one within one month of release.
month of release.  Installation of all applicable
 Installation of all applicable vendor-supplied security patches
vendor-supplied security within an appropriate time frame.
patches within an
appropriate time frame (for
example, within three
months).
6.2.b For a sample of system Identify the sample of system
components and related components and related software
software, compare the list of selected for this testing procedure.
(check one)
In Place Not Not in
security patches installed on Identify the vendor security patch list

each system to the most recent reviewed.
vendor security-patch list, to For each item in the sample, describe how the list of security patches installed on each system was compared to the most recent
verify the following: vendor security-patch list to verify that:
 That applicable critical  Applicable critical vendor-supplied

vendor-supplied security security patches are installed within
patches are installed within one month of release.
one month of release.  All applicable vendor-supplied
 All applicable vendor- security patches are installed within
supplied security patches an appropriate time frame.
are installed within an
appropriate time frame (for
example, within three
months).
6.3 Develop internal and external software applications (including web-based administrative
access to applications) securely, as follows:
 In accordance with PCI DSS (for example, secure authentication and logging).
 Based on industry standards and/or best practices. ☐ ☐ ☐ ☐ ☒
 Incorporate information security throughout the software development life cycle.

Note: this applies to all software developed internally as well as bespoke or custom software
developed by a third party.
6.3.a Examine written software- Identify the document that defines
development processes to software development processes based
verify that the processes are on industry standards and/or best
practices.
(check one)
In Place Not Not in
based on industry standards Identify the industry standards and/or

and/or best practices. best practices used.
6.3.b Examine written software Identify the documented software
development processes to development processes examined to
verify that information security verify that information security is
is included throughout the life included throughout the life cycle.
cycle.
6.3.c Examine written software Identify the documented software
development processes to development processes examined to
verify that software applications verify that software applications are
are developed in accordance developed in accordance with PCI DSS.
with PCI DSS.
6.3.d Interview software Identify the software developers
developers to verify that written interviewed for this testing procedure.
software development For the interview, summarize the
processes are implemented. relevant details discussed to verify
that written software development
processes are implemented.
(check one)
In Place Not Not in
6.3.1 Remove development, test and/or custom application accounts, user IDs, and passwords
☐ ☐ ☐ ☐ ☒
before applications become active or are released to customers.
6.3.1 Examine written software- Identify the documented software-
development procedures and development processes examined to
interview responsible personnel verify processes define that pre-
to verify that pre-production production and/or custom application
and/or custom application accounts, user IDs and/or passwords
accounts, user IDs and/or are removed before an application goes
passwords are removed before into production or is released to
an application goes into customers.
production or is released to Identify the responsible personnel
customers. interviewed for this testing procedure.
relevant details discussed to confirm
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.
(check one)
In Place Not Not in
6.3.2 Review custom code prior to release to production or customers in order to identify any
potential coding vulnerability (using either manual or automated processes) to include at least
the following:
 Code changes are reviewed by individuals other than the originating code author, and by
individuals knowledgeable about code review techniques and secure coding practices.
 Code reviews ensure code is developed according to secure coding guidelines.
 Appropriate corrections are implemented prior to release. ☐ ☐ ☐ ☐ ☒
 Code review results are reviewed and approved by management prior to release.
Note: This requirement for code reviews applies to all custom code (both internal and public-
facing), as part of the system development life cycle.
Code reviews can be conducted by knowledgeable internal personnel or third parties. Public-facing web applications are also
subject to additional controls, to address ongoing threats and vulnerabilities after implementation, as defined at PCI DSS
Requirement 6.6.
(check one)
In Place Not Not in
6.3.2.a Examine written Identify the documented software-

software development development processes examined to
procedures and interview verify processes define that all custom
responsible personnel to verify application code changes must be
that all custom application code reviewed (using either manual or
changes must be reviewed automated processes) as follows:
(using either manual or  Code changes are reviewed by
automated processes) as individuals other than the
follows: originating code author, and by
 Code changes are reviewed individuals who are
by individuals other than the knowledgeable in code review
originating code author, and techniques and secure coding
by individuals who are practices.
knowledgeable in code  Code reviews ensure code is
review techniques and developed according to secure
secure coding practices. coding guidelines (see PCI DSS
 Code reviews ensure code is Requirement 6.5).
developed according to  Appropriate corrections are
secure coding guidelines implemented prior to release.
(see PCI DSS Requirement
 Code-review results are reviewed
6.5).
and approved by management
 Appropriate corrections are
prior to release.
implemented prior to release.
 Code-review results are
reviewed and approved by
management prior to release.
(check one)
In Place Not Not in

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).
 Appropriate corrections are
 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.
6.3.2.b Select a sample of Identify the sample of recent custom
recent custom application application changes selected for this
changes and verify that custom testing procedure.
(check one)
In Place Not Not in
application code is reviewed For each item in the sample, describe how code review processes were observed to verify custom application code is reviewed as
according to 6.3.2.a, above. follows:
 Code changes are reviewed by

individuals other than the originating
code author.
 Code changes are reviewed 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
 Code-review results are reviewed
and approved by management prior
to release.
(check one)
In Place Not Not in
6.4 Follow change control processes and procedures for all changes to system components. The
☐ ☐ ☐ ☐ ☒
processes must include the following:
(check one)
In Place Not Not in
6.4 Examine policies and Identify the documented policies and

procedures to verify the procedures examined to verify that the
following are defined: following are defined:
 Development/test  Development/test environments
environments are separate are separate from production
from production environments with access control
environments with access in place to enforce separation.
control in place to enforce  A separation of duties between
separation. personnel assigned to the
 A separation of duties development/test environments
between personnel assigned and those assigned to the
to the development/test production environment.
environments and those  Production data (live PANs) are
assigned to the production not used for testing or
environment. development.
 Production data (live PANs)  Test data and accounts are
are not used for testing or removed before a production
development. system becomes active.
 Test data and accounts are  Change-control procedures
removed before a production related to implementing security
system becomes active. patches and software
 Change control procedures modifications are documented.
related to implementing
security patches and
software modifications are
documented.
(check one)
In Place Not Not in
6.4.1 Separate development/test environments from production environments, and enforce the
☐ ☐ ☐ ☐ ☒
separation with access controls.
6.4.1.a Examine network Identify the network documentation
documentation and network that illustrates that the development/test
device configurations to verify environments are separate from the
that the development/test production environment(s).
environments are separate Describe how network device
from the production configurations were examined to verify
environment(s). that the development/test environments
are separate from the production
environment(s).
6.4.1.b Examine access Identify the access control settings
controls settings to verify that examined for this testing procedure.
access controls are in place to Describe how the access control
enforce separation between the settings were examined to verify that
development/test environments access controls are in place to enforce
and the production separation between the
environment(s). development/test environments and the
production environment(s).
6.4.2 Separation of duties between development/test and production environments. ☐ ☐ ☐ ☐ ☒
6.4.2 Observe processes and Identify the personnel assigned to

interview personnel assigned to development/test environments
development/test environments interviewed who confirm that separation
and personnel assigned to of duties is in place between
production environments to development/test environments and the
verify that separation of duties production environment.
(check one)
In Place Not Not in
is in place between Identify the personnel assigned to

development/test environments production environments interviewed
and the production who confirm that separation of duties is
environment. in place between development/test
environments and the production
environment.
Describe how processes were
observed to verify that separation of
duties is in place between
development/test environments and the
production environment.
6.4.3 Production data (live PANs) are not used for testing or development. ☐ ☐ ☐ ☐ ☒
6.4.3.a Observe testing Identify the personnel interviewed who

processes and interview confirm that procedures are in place to
personnel to verify procedures ensure production data (live PANs) are
are in place to ensure not used for testing or development.
production data (live PANs) are Describe how testing processes were
not used for testing or observed to verify procedures are in
development. place to ensure production data (live
PANs) are not used for testing.
Describe how testing processes were
observed to verify procedures are in
place to ensure production data (live
PANs) are not used for development.
6.4.3.b Examine a sample of Describe how a sample of test data
test data to verify production was examined to verify production data
(live PANs) is not used for testing.
(check one)
In Place Not Not in
data (live PANs) is not used for Describe how a sample of test data
testing or development. was examined to verify production data
(live PANs) is not used for development.
6.4.4 Removal of test data and accounts before production systems become active. ☐ ☐ ☐ ☐ ☒
6.4.4.a Observe testing Identify the personnel interviewed who

processes and interview confirm that test data and accounts are
personnel to verify test data removed before a production system
and accounts are removed becomes active.
before a production system Describe how testing processes were
becomes active. observed to verify that test data is
removed before a production system
becomes active.
Describe how testing processes were
observed to verify that test accounts are
removed before a production system
becomes active.
6.4.4.b Examine a sample of Describe how a sample of data from
data and accounts from production systems recently installed or
production systems recently updated was examined to verify test
installed or updated to verify data is removed before the system
test data and accounts are becomes active.
removed before the system Describe how a sample of accounts
becomes active. from production systems recently
installed or updated was examined to
verify test accounts are removed before
the system becomes active.
(check one)
In Place Not Not in
6.4.5 Change control procedures for the implementation of security patches and software
☐ ☐ ☐ ☐ ☒
modifications must include the following:
6.4.5.a Examine documented Identify the documented change-
change-control procedures control procedures related to
related to implementing implementing security patches and
security patches and software software modification examined to verify
modifications and verify procedures are defined for:
procedures are defined for:  Documentation of impact.
 Documentation of impact.  Documented change approval by
 Documented change authorized parties.
approval by authorized  Functionality testing to verify that
parties. the change does not adversely
 Functionality testing to verify
impact the security of the system.
that the change does not
 Back-out procedures.
adversely impact the security
of the system.
 Back-out procedures.
6.4.5.b For a sample of system Identify the sample of system

components, interview components selected.
responsible personnel to Identify the responsible personnel
determine recent interviewed to determine recent
changes/security patches. changes/security patches.
Trace those changes back to
For each item in the sample, identify
related change control
the sample of changes and the related
documentation. For each
change control documentation selected
change examined, perform the
for this testing procedure (through
following:
6.4.5.4)
(check one)
In Place Not Not in
6.4.5.1 Documentation of impact. ☐ ☐ ☐ ☐ ☒
6.4.5.1 Verify that For each change from 6.4.5.b, describe

documentation of impact is how the changes were traced back to
included in the change control the identified related change control
documentation for each documentation to verify that
sampled change. documentation of impact is included in
the change control documentation for
each sampled change.
6.4.5.2 Documented change approval by authorized parties. ☐ ☐ ☐ ☐ ☒
6.4.5.2 Verify that documented For each change from 6.4.5.b, describe
approval by authorized parties how the changes were traced back to
is present for each sampled the identified related change control
change. documentation to verify that
documented approval by authorized
parties is present in the change control
documentation for each sampled
change.
6.4.5.3 Functionality testing to verify that the change does not adversely impact the security of
☐ ☐ ☐ ☐ ☒
the system.
(check one)
In Place Not Not in
6.4.5.3.a For each sampled For each change from 6.4.5.b, describe
change, verify that functionality how the changes were traced back to
testing is performed to verify the identified related change control
that the change does not documentation to verify that the change
adversely impact the security of control documentation for each sampled
the system. change includes evidence 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 Identify the sample of system
changes, verify that all updates components selected for this testing
are tested for compliance with procedure.
PCI DSS Requirement 6.5 For each item in the sample, identify
before being deployed into the sample of custom code changes
production. and the related change control
documentation selected for this testing
procedure.
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
compliance with PCI DSS Requirement
6.5 before being deployed into
production.
(check one)
In Place Not Not in
6.4.5.4 Back-out procedures. ☐ ☐ ☐ ☐ ☒
6.4.5.4 Verify that back-out For each change from 6.4.5.b, describe
procedures are prepared for how the changes were traced back to
each sampled change. the 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.
6.5 Address common coding vulnerabilities in software-development processes as follows:
 Train developers in secure coding techniques, including how to avoid common coding vulnerabilities, and understanding
how sensitive data is handled in memory.
 Develop applications based on secure coding guidelines.
☐ ☐ ☐ ☐ ☒
Note: The vulnerabilities listed at 6.5.1 through 6.5.10 were current with industry best practices
when this version of PCI DSS was published. However, as industry best practices for
vulnerability management are updated (for example, the OWASP Guide, SANS CWE Top 25,
CERT Secure Coding, etc.), the current best practices must be used for these requirements.
6.5.a Examine software Identify the document reviewed to
development policies and verify that training in secure coding
procedures to verify that techniques is required for developers.
training in secure coding Identify the industry best practices and
techniques is required for guidance that training is based on.
developers, based on industry
best practices and guidance.
6.5.b Interview a sample of Identify the developers interviewed for
developers to verify that they this testing procedure.
(check one)
In Place Not Not in
are knowledgeable in secure For the interview, summarize the

coding techniques. relevant details discussed to verify
that they are knowledgeable in secure
coding techniques.
6.5.c Examine records of Identify the records of training that
training to verify that software were examined to verify that software
developers received training on developers received training on secure
secure coding techniques, coding techniques, including how to
including how to avoid common avoid common coding vulnerabilities,
coding vulnerabilities, and and understanding how sensitive data is
understanding how sensitive handled in memory.
data is handled in memory.
6.5.d. Verify that processes are Identify the software-development
in place to protect applications policies and procedures examined to
from, at a minimum, the verify that processes are in place to
following vulnerabilities: protect applications from, at a minimum,
the following vulnerabilities:
interviewed to verify that processes are
in place to protect applications from, at
a minimum, the following vulnerabilities:
Note: Requirements 6.5.1 through 6.5.6, below, apply to all applications (internal or
external):
6.5.1 Injection flaws, particularly SQL injection. Also consider OS Command Injection, LDAP and
☐ ☐ ☐ ☐ ☒
XPath injection flaws as well as other injection flaws.
6.5.1 Examine software- For the interviews at 6.5.d, summarize the relevant interview details that confirm processes are in place, consistent with the
development policies and software development documentation at 6.5.d, to ensure that injection flaws are addressed by coding techniques that include:
(check one)
In Place Not Not in
procedures and interview  Validating input to verify user data

responsible personnel to verify cannot modify meaning of commands
that injection flaws are and queries.
addressed by coding  Utilizing parameterized queries.
techniques that include:
 Validating input to verify user
data cannot modify meaning
of commands and queries.
 Utilizing parameterized
queries.
6.5.2 Buffer overflow. ☐ ☐ ☐ ☐ ☒
development policies and software development documentation at 6.5.d, to ensure that buffer overflows are addressed by coding techniques that include:
procedures and interview
responsible personnel to verify  Validating buffer boundaries.
that buffer overflows are  Truncating input strings.
addressed by coding
 Validating buffer boundaries.
 Truncating input strings.
6.5.3 Insecure cryptographic storage. ☐ ☐ ☐ ☐ ☒
development policies and software development documentation at 6.5.d, to ensure that insecure cryptographic storage is addressed by coding techniques that:
procedures and interview  Prevent cryptographic flaws.
responsible personnel to verify
 Use strong cryptographic algorithms
and keys.
6.5.4 Insecure communications. ☐ ☐ ☐ ☐ ☒
(check one)
In Place Not Not in
development policies and software development documentation at 6.5.d, to ensure that insecure communications are addressed by coding techniques that
properly:
responsible personnel to verify  Authenticate all sensitive
that insecure communications communications.
are addressed by coding  Encrypt all sensitive communications.
techniques that properly
authenticate and encrypt all
sensitive communications.
6.5.5 Improper error handling. ☐ ☐ ☐ ☐ ☒
6.5.5 Examine-software For the interviews at 6.5.d, summarize

development policies and the relevant interview details that
procedures and interview confirm processes are in place,
responsible personnel to verify consistent with the software
that improper error handling is development documentation at 6.5.d, to
addressed by coding ensure that improper error handling is
techniques that do not leak addressed by coding techniques that do
information via error messages not leak information via error messages.
(for example, by returning
generic rather than specific
error details).
6.5.6 All “high risk” vulnerabilities identified in the vulnerability identification process (as defined
☐ ☐ ☐ ☐ ☒
in PCI DSS Requirement 6.1).
(check one)
In Place Not Not in
6.5.6 Examine software- For the interviews at 6.5.d, summarize

that coding techniques address development documentation at 6.5.d, to
any “high risk” vulnerabilities ensure that applications are not
that could affect the application, vulnerable to “High” vulnerabilities, as
as identified in PCI DSS identified in PCI DSS Requirement 6.1.
Requirement 6.1.
Note: Requirements 6.5.7 through 6.5.10, below, apply to web applications and application interfaces
(internal or external):
Indicate whether web applications and application interfaces are present. (yes/no) Not answered
If “no,” mark the below 6.5.7-6.5.10 as “Not Applicable.”
If “yes,” complete the following:
6.5.7 Cross-site scripting (XSS). ☐ ☐ ☐ ☐ ☒
(check one)
In Place Not Not in
development policies and software development documentation at 6.5.d, to ensure that cross-site scripting (XSS) is addressed by coding techniques that
include:
responsible personnel to verify  Validating all parameters before
that cross-site scripting (XSS) inclusion.
is addressed by coding  Utilizing context-sensitive escaping.
 Validating all parameters
before inclusion.
 Utilizing context-sensitive
escaping.
6.5.8 Improper access control (such as insecure direct object references, failure to restrict URL
☐ ☐ ☐ ☐ ☒
access, directory traversal, and failure to restrict user access to functions).
development policies and software development documentation at 6.5.d, to ensure that improper access control is addressed by coding techniques that
procedures and interview include:

 Proper authentication of users.
that improper access control—
such as insecure direct object  Sanitizing input.
references, failure to restrict
 Not exposing internal object
URL access, and directory
references to users.
(check one)
In Place Not Not in
traversal—is addressed by  User interfaces that do not permit

coding technique that include: access to unauthorized functions.
 Proper authentication of
users.
 Sanitizing input.
 Not exposing internal object
references to users.
 User interfaces that do not
permit access to
unauthorized functions.
6.5.9 Cross-site request forgery (CSRF). ☐ ☐ ☐ ☐ ☒
6.5.9 Examine software For the interviews at 6.5.d, summarize

that cross-site request forgery development documentation at 6.5.d, to
(CSRF) is addressed by coding ensure that cross-site request forgery
techniques that ensure (CSRF) is addressed by coding
applications do not rely on techniques that ensure applications do
authorization credentials and not rely on authorization credentials and
tokens automatically submitted tokens automatically submitted by
by browsers. browsers.
(check one)
In Place Not Not in
6.5.10 Broken authentication and session management.

Note: Requirement 6.5.10 is a best practice until June 30, 2015, after which it becomes a ☐ ☐ ☐ ☐ ☒
requirement.
6.5.10 Examine software Indicate whether this ROC is being No
development policies and completed prior to June 30, 2015.
procedures and interview (yes/no)
responsible personnel to verify 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
that broken authentication and as “Not Applicable.”
session management are If “no” OR if the assessed entity has this in place ahead of the requirement’s effective date, complete the following:
addressed via coding
For the interviews at 6.5.d, summarize the relevant interview details that confirm processes are in place, consistent with the
techniques that commonly
software development documentation at 6.5.d, to ensure that broken authentication and session management are addressed via
include: coding techniques that protect credentials and session IDs, including:
 Flagging session tokens (for
 Flagging session tokens (for
example cookies) as
example cookies) as “secure.”
“secure.”
 Not exposing session IDs in  Not exposing session IDs in the
the URL. URL.
 Incorporating appropriate  Implementing appropriate time-outs
time-outs and rotation of and rotation of session IDs after a
session IDs after a successful login
successful login.
(check one)
In Place Not Not in
6.6 For public-facing web applications, address new threats and vulnerabilities on an ongoing
basis and ensure these applications are protected against known attacks by either of the
following methods:
 Reviewing public-facing web applications via manual or automated application vulnerability
security assessment tools or methods, at least annually and after any changes.
☐ ☐ ☐ ☐ ☒
Note: This assessment is not the same as the vulnerability scans performed for Requirement
11.2.
 Installing an automated technical solution that detects and prevents web-based attacks (for
example, a web-application firewall) in front of public-facing web applications, to continually
check all traffic.
6.6 For public-facing web For each public-facing web application,
applications, ensure that either identify which of the two methods are
one of the following methods is implemented:
in place as follows:  Web application vulnerability
 Examine documented security assessments, AND/OR
processes, interview  Automated technical solution that
personnel, and examine detects and prevents web-based
records of application attacks, such as web application
security assessments to firewalls.
verify that public-facing web If application vulnerability security assessments are indicated above:
applications are reviewed—
Describe the tools and/or methods Not Applicable
using either manual or
used (manual or automated, or a
automated vulnerability
combination of both).
security assessment tools or
methods—as follows: Identify the organization(s) confirmed Not Applicable
- At least annually.
to specialize in application security that
is performing the assessments.
(check one)
In Place Not Not in
- After any changes. Identify the documented processes Not Applicable

- By an organization that that were examined to verify that public-
specializes in application facing web applications are reviewed
security. using the tools and/or methods
- That, at a minimum, all indicated above, as follows:
vulnerabilities in  At least annually.
Requirement 6.5 are  After any changes.
included in the  By an organization that specializes
assessment. in application security.
- That all vulnerabilities are
 That, at a minimum, all
corrected.
vulnerabilities in Requirement 6.5
- That the application is re- are included in the assessment.
evaluated after the
 That all vulnerabilities are
corrections.
corrected
 Examine the system
 That the application is re-
configuration settings and
evaluated after the corrections.
(check one)
In Place Not Not in
interview responsible Identify the responsible personnel Not Applicable

personnel to verify that an interviewed who confirm that public-
automated technical solution facing web applications are reviewed,
that detects and prevents as follows:
web-based attacks (for  At least annually.
example, a web-application
 After any changes.
firewall) is in place as
follows:  By an organization that specializes
in application security.
- Is situated in front of
public-facing web  That, at a minimum, all
applications to detect and vulnerabilities in Requirement 6.5
prevent web-based are included in the assessment.
attacks.  That all vulnerabilities are
- Is actively running and up- corrected.
to-date as applicable.  That the application is re-
- Is generating audit logs. evaluated after the corrections.
- Is configured to either Identify the records of application Not Applicable
block web-based attacks, security assessments examined for
or generate an alert that is this testing procedure.
immediately investigated. Describe how the records of application security assessments were examined to verify that public-
facing web applications are reviewed as follows:
 At least annually. Not Applicable
 After any changes. Not Applicable
 By an organization that Not Applicable

specialized in application security.
(check one)
In Place Not Not in
 That at a minimum, all Not Applicable

vulnerabilities in requirement 6.5
are included in the assessment.
 That all vulnerabilities are Not Applicable
corrected.
 That the application is re- Not Applicable
evaluated after the corrections.
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 Not Applicable
solution in use that detects and
prevents web-based attacks.
Identify the responsible personnel Not Applicable
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 that is immediately
investigated.
(check one)
In Place Not Not in
Identify the system configuration Not Applicable

settings examined for this testing
procedure.
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 Not Applicable
web applications to detect and
prevent web-based attacks.
 Is actively running and up-to-date Not Applicable
as applicable.
 Is generating audit logs. Not Applicable
 Is configured to either block web- Not Applicable

based attacks, or generate an
alert that is immediately
investigated.
6.7 Ensure that security policies and operational procedures for developing and maintaining
☐ ☐ ☐ ☐ ☒
secure systems and applications are documented, in use, and known to all affected parties.
verify that security policies and operational procedures for developing
operational procedures for and maintaining secure systems and
developing and maintaining applications are documented.
(check one)
In Place Not Not in
secure systems and Identify responsible personnel

applications are: interviewed who confirm that the above
operational procedures for developing
 In use, and
and maintaining secure systems and
 Known to all affected parties. applications are:
 In use
Implement Strong Access Control Measures
Requirement 7: Restrict access to cardholder data by business need to know
PCI DSS Requirements

and Testing Procedures
Reporting Instruction
Reporting Details:
Assessor’s Response
(check one)
In Place
In Place w/CCW
N/A
Not Tested
Not in Place
7.1 Limit access to system components and cardholder data to only those individuals whose job requires such access.
☐
☐
☐
☐
☒
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.
Identify the written policy for access control that was examined to verify 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 Define access needs for each role, including:
 System components and data resources that each role needs to access for their job function.
 Level of privilege required (for example, user, administrator, etc.) for accessing resources.
☒
☐
☐
☐
☐
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.
Identify the selected sample of roles for this testing procedure.

For each role in the selected sample, describe how the role was examined to 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.
7.1.2 Restrict access to privileged user IDs to least privileges necessary to perform job responsibilities.
☐
☒
☐
☐
☐
7.1.2.a Interview personnel responsible for assigning access to verify that access to privileged user IDs is:
 Assigned only to roles that specifically require such privileged access.
 Restricted to least privileges necessary to perform job responsibilities.
Identify the responsible personnel interviewed who confirm that access to privileged user IDs is:
 Assigned only to roles that specifically require such privileged access.
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.
Identify the sample of user IDs with privileged access selected for this testing procedure.
Identify the responsible management personnel interviewed to confirm that privileges assigned are:
 Necessary for that individual’s job function.
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.
7.1.3 Assign access based on individual personnel’s job classification and function.
☐
☐
☒
☐
☐
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.
Identify the sample of user IDs examined for this testing procedure.
7.1.3 na2nd rowsecond paragraph
Identify the responsible management personnel interviewed who confirm that privileges assigned are based on that individual’s job classification and function.
Not Applicable
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.
Not Applicable
7.1.4 Require documented approval by authorized parties specifying required privileges.
☐
☐
☐
☒
☐
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.
Identify the sample of user IDs examined for this testing procedure.
7.1.4 NT respo
second para
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.

Not Tested
 The approval was by authorized parties.

Not Tested
 That specified privileges match the roles assigned to the individual.

Not Tested
7.2 Establish an access control system for systems components that restricts access based on a user’s need to know, and is set to “deny all” unless specifically allowed.
This access control system must include the following:

7.2 Examine system settings and vendor documentation to verify that an access control system is implemented as follows:
7.2.1 Coverage of all system components.
☐
☐
☐
☐
☒
7.2.1 Confirm that access control systems are in place on all system components.
Identify vendor documentation examined.
Describe how system settings were examined with the vendor documentation to verify that access control systems are in place on all system components.
7.2.2 Assignment of privileges to individuals based on job classification and function.

☒
☐
☐
☐
☐
7.2.2 Confirm that access control systems are configured to enforce privileges assigned to individuals based on job classification and function.
Describe how system settings were examined with the vendor documentation at 7.2.1 to verify that access control systems are configured to enforce privileges assigned
to individuals based on job classification and function.
7.2.3 Default “deny-all” setting.

☐
☒
☐
☐
☐
7.2.3 Confirm that the access control systems have a default “deny-all” setting.
Describe how system settings were examined with vendor documentation at 7.2.1 to verify that access control systems have a default “deny-all” setting.
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.
☐
☐
☐
☒
☐
7.3 Examine documentation and interview personnel to verify that security policies and operational procedures for restricting access to cardholder data are:
 Documented,
 In use, and
Identify the document reviewed to verify that security policies and operational procedures for restricting access to cardholder data are documented.
7.3 NT resp
Identify responsible personnel interviewed who confirm that the above documented security policies and operational procedures for restricting access to cardholder
data are:
 In use
Not Tested
Requirement 8: Identify and authenticate access to system components
(check one)
In Place Not Not in
8.1 Define and implement policies and procedures to ensure proper user identification
☐ ☐ ☐ ☐ ☒
management for non-consumer users and administrators on all system components as follows:
(check one)
In Place Not Not in
8.1.a Review procedures and Identify the written procedures for

confirm they define processes user identification management
for each of the items below at examined to verify processes are
8.1.1 through 8.1.8. 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.
(check one)
In Place Not Not in
8.1.b Verify that procedures are implemented for user identification management, by performing the following:
8.1.1 Assign all users a unique ID before allowing them to access system components or
☐ ☐ ☐ ☐ ☒
cardholder data.
8.1.1 Interview administrative Identify the responsible
personnel to confirm that all administrative personnel interviewed
users are assigned a unique ID for this testing procedure.
for access to system For the interview, summarize the
components or cardholder relevant details discussed to confirm
data. that all users are assigned a unique ID
for access to system components or
cardholder data.
8.1.2 Control addition, deletion, and modification of user IDs, credentials, and other identifier
☐ ☐ ☐ ☐ ☒
objects.
8.1.2 For a sample of privileged Identify the sample of privileged user
user IDs and general user IDs, IDs selected for this testing procedure.
examine associated Identify the sample of general user IDs
authorizations and observe selected for this testing procedure.
system settings to verify each
Describe how observed system settings and the associated authorizations documented for the user IDs were compared to verify
user ID and privileged user ID that each ID has been implemented with only the privileges specified on the documented approval:
has been implemented with
only the privileges specified on  For the sample of privileged user IDs.
the documented approval.  For the sample of general user IDs.
8.1.3 Immediately revoke access for any terminated users. ☐ ☐ ☐ ☐ ☒
(check one)
In Place Not Not in
8.1.3.a Select a sample of Identify the sample of users

users terminated in the past six terminated in the past six months
months, and review current selected.
user access lists—for both local Describe how the current user access
and remote access—to verify lists for local access were reviewed to
that their IDs have been verify that the sampled user IDs have
deactivated or removed from been deactivated or removed from the
the access lists. access lists.
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.
8.1.3.b Verify all physical For the sample of users terminated in
authentication methods—such the past six months at 8.1.3.a, describe
as, smart cards, tokens, etc.— how it was determined which, if any,
have been returned or physical authentication methods, the
deactivated. terminated users had access to prior to
termination.
Describe how the physical
authentication method(s) for the
terminated employees were verified to
have been returned or deactivated.
8.1.4 Remove/disable inactive user accounts within 90 days. ☐ ☐ ☐ ☐ ☒
(check one)
In Place Not Not in
8.1.4 Observe user accounts to Describe how user accounts were

verify that any inactive observed to verify that any inactive
accounts over 90 days old are accounts over 90 days old are either
either removed or disabled. removed or disabled.
8.1.5 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.
8.1.5.a Interview personnel and Identify the personnel interviewed who

observe processes for confirm that accounts used by vendors
managing accounts used by for remote access are:
vendors to access, support, or  Disabled when not in use.
maintain system components to  Enabled only when needed by the
verify that accounts used by vendor, and disabled when not in
vendors for remote access are: use.
 Disabled when not in use.
Describe how processes for managing accounts used by vendors to access, support, or maintain system components were
 Enabled only when needed observed to verify that accounts used by vendors for remote access are:
by the vendor, and disabled
 Disabled when not in use.
when not in use.
 Enabled only when needed by the
vendor, and disabled when not in
use.
8.1.5.b Interview personnel and Identify the personnel interviewed who
observe processes to verify confirm that accounts used by vendors
that vendor remote access for remote access are monitored while
being used.
(check one)
In Place Not Not in
accounts are monitored while Describe how processes for managing

being used. 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.
8.1.6 Limit repeated access attempts by locking out the user ID after not more than six attempts. ☐ ☐ ☐ ☐ ☒
8.1.6.a For a sample of system Identify the sample of system

components, inspect system components selected for this testing
configuration settings to verify procedure.
that authentication parameters For each item in the sample, describe
are set to require that user how system configuration settings were
accounts be locked out after inspected to verify that authentication
not more than six invalid logon parameters are set to require that user
attempts. accounts be locked after not more than
six invalid logon attempts.
8.1.6.b Additional procedure Additional procedure for service
for service provider provider assessments only, identify the
assessments only: Review documented internal processes and
internal processes and customer/user documentation
customer/user documentation, reviewed to verify that non-consumer
and observe implemented customer user accounts are temporarily
processes to verify that non- locked-out after not more than six
consumer customer user invalid access attempts.
(check one)
In Place Not Not in
accounts are temporarily Describe the implemented processes

locked-out after not more than that were observed to verify that non-
six invalid access attempts. consumer customer user accounts are
temporarily locked-out after not more
than six invalid access attempts.
8.1.7 Set the lockout duration to a minimum of 30 minutes or until an administrator enables the
☐ ☐ ☐ ☐ ☒
user ID.
8.1.7 For a sample of system Identify the sample of system
that password parameters are For each item in the sample, describe
set to require that once a user how system configuration settings were
account is locked out, it inspected to verify that password
remains locked for a minimum parameters are set to require that once
of 30 minutes or until a system a user account is locked out, it remains
administrator resets the locked for a minimum of 30 minutes or
account. until a system administrator resets the
account.
8.1.8 If a session has been idle for more than 15 minutes, require the user to re-authenticate to
☐ ☐ ☐ ☐ ☒
re-activate the terminal or session.
8.1.8 For a sample of system Identify the sample of system
(check one)
In Place Not Not in
that system/session idle time For each item in the sample, describe
out features have been set to how system configuration settings were
15 minutes or less. inspected to verify that system/session
idle time out features have been set to
15 minutes or less.
8.2 In addition to assigning a unique ID, ensure proper user-authentication management for non-
consumer users and administrators on all system components by employing at least one of the
following methods to authenticate all users:
☐ ☐ ☐ ☐ ☒
 Something you know, such as a password or passphrase.
 Something you have, such as a token device or smart card.
 Something you are, such as a biometric.
8.2 To verify that users are Identify the document describing the
authenticated using unique ID authentication method(s) used that was
and additional authentication reviewed to verify that the methods
(for example, a require users to be authenticated using
password/phrase) for access to a unique ID and additional
the cardholder data authentication for access to the
(check one)
In Place Not Not in
environment, perform the Describe the authentication methods

following: used (for example, a password or
 Examine documentation passphrase, a token device or smart
describing the authentication card, a biometric, etc.) for each type of
method(s) used. system component.
 For each type of For each type of authentication method used and for each type of system component, describe how the authentication method was
observed to be:
authentication method used
and for each type of system  Used for access to the cardholder
component, observe an data environment.
authentication to verify  Functioning consistently with the
authentication is functioning documented authentication
consistent with documented method(s).
authentication method(s).
8.2.1 Using strong cryptography, render all authentication credentials (such as
☐ ☐ ☐ ☐ ☒
passwords/phrases) unreadable during transmission and storage on all system components.
8.2.1.a Examine vendor Identify the vendor documentation
documentation and system reviewed for this testing procedure.
configuration settings to verify Identify the sample of system
that passwords are protected components selected.
with strong cryptography during
For each item in the sample, describe
transmission and storage.
how system configuration settings were
examined to verify that passwords are
protected with strong cryptography
during transmission.
(check one)
In Place Not Not in

how system configuration settings were
examined to verify that passwords are
protected with strong cryptography
during storage.
8.2.1.b For a sample of system For each item in the sample at 8.2.1.a,
components, examine describe how password files were
password files to verify that examined to verify that passwords are
passwords are unreadable unreadable during storage.
during storage.
8.2.1.c For a sample of system For each item in the sample at 8.2.1.a,
components, examine data describe how password files were
transmissions to verify that examined to verify that passwords are
passwords are unreadable unreadable during transmission.
during transmission.
8.2.1.d Additional procedure Additional procedure for service
for service provider provider assessments only: for each
assessments only: Observe item in the sample at 8.2.1.a, describe
password files to verify that how password files were examined to
non-consumer customer verify that non-consumer customer
passwords are unreadable passwords are unreadable during
during storage. storage.
(check one)
In Place Not Not in
8.2.1.e Additional procedure Additional procedure for service

for service provider provider assessments only: for each
assessments only: Observe item in the sample at 8.2.1.a, describe
data transmissions to verify that how password files were examined to
non-consumer customer verify that non-consumer customer
passwords are unreadable passwords are unreadable during
during transmission. transmission.
8.2.2 Verify user identity before modifying any authentication credential—for example,
☐ ☐ ☐ ☐ ☒
performing password resets, provisioning new tokens, or generating new keys.
8.2.2 Examine authentication Identify the document examined to
procedures for modifying verify that authentication procedures for
authentication credentials and modifying authentication credentials
observe security personnel to define that if a user requests a reset of
verify that, if a user requests a an authentication credential by a non-
reset of an authentication face-to-face method, the user’s identity
credential by phone, e-mail, is verified before the authentication
web, or other non-face-to-face credential is modified.
method, the user’s identity is Describe the non-face-to-face methods
verified before the used for requesting password resets.
authentication credential is
Describe how security personnel were
modified.
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.
(check one)
In Place Not Not in
8.2.3 Passwords/phrases must meet the following:

 Require a minimum length of at least seven characters.
 Contain both numeric and alphabetic characters. ☐ ☐ ☐ ☐ ☒
Alternatively, the passwords/phrases must have complexity and strength at least equivalent to
the parameters specified above.
that user password parameters 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 are set to require at least the following strength/complexity:
following strength/complexity:
 Require a minimum length of at least
 Require a minimum length of seven characters.
at least seven characters.
 Contain both numeric and alphabetic
 Contain both numeric and characters.
alphabetic characters.
(check one)
In Place Not Not in

for service provider provider assessments only: Identify the
customer/user documentation reviewed to verify that non-consumer
to verify that non-consumer customer passwords are required to
customer passwords are meet at least the following
required to meet at least the strength/complexity:
following strength/complexity:  A minimum length of at least
 Require a minimum length of seven characters.
at least seven characters.  Non-consumer user passwords
 Contain both numeric and are required to contain both
alphabetic characters. numeric and alphabetic
characters.
Describe how internal processes were reviewed to verify that non-consumer customer passwords are required to meet at least the
following strength/complexity:
 A minimum length of at least seven

characters.
 Non-consumer customer passwords
are required to contain both numeric
and alphabetic characters.
8.2.4 Change user passwords/passphrases at least once every 90 days. ☐ ☐ ☐ ☐ ☒

(check one)
In Place Not Not in
that user password parameters For each item in the sample, describe
are set to require users to how system configuration settings were
change passwords at least inspected to verify that user password
once every 90 days. parameters are set to require users to
change passwords at least once every
90 days.
customer/user documentation reviewed to verify that:
to verify that:  Non-consumer customer user
 Non-consumer customer user passwords are required to change
passwords are required to periodically; and
change periodically; and  Non-consumer customer users are
 Non-consumer customer given guidance as to when, and
users are given guidance as under what circumstances,
to when, and under what passwords must change.
circumstances, passwords Describe how internal processes were reviewed to verify that:
must change.
 Non-consumer customer user
passwords are required to change
periodically; and
 Non-consumer customer users are
given guidance as to when, and
under what circumstances,
passwords must change.
(check one)
In Place Not Not in
8.2.5 Do not allow an individual to submit a new password/phrase that is the same as any of the
☐ ☐ ☐ ☐ ☒
last four passwords/phrases he or she has used.
components, obtain and components selected for this testing
inspect system configuration procedure.
settings to verify that password For each item in the sample, describe
parameters are set to require how system configuration settings were
that new passwords cannot be inspected to verify that password
the same as the four previously parameters are set to require that new
used passwords. passwords cannot be the same as the
four previously used passwords.
8.2.5.b Additional Procedure Additional procedure for service
customer/user documentation reviewed to verify that new non-
to verify that new non- consumer customer user passwords
consumer customer user cannot be the same as the previous four
passwords cannot be the same passwords.
as the previous four Describe how internal processes were
passwords. reviewed to verify that new non-
consumer customer user passwords
cannot be the same as the previous four
passwords.
8.2.6 Set passwords/phrases for first-time use and upon reset to a unique value for each user,
☐ ☐ ☐ ☐ ☒
and change immediately after the first use.
(check one)
In Place Not Not in
8.2.6 Examine password Identify the documented password

procedures and observe procedures examined to verify the
security personnel to verify that procedures define that:
first-time passwords for new  First-time passwords must be set
users, and reset passwords for to a unique value for each user.
existing users, are set to a  First-time passwords must be
unique value for each user and changed after the first use.
changed after first use.
 Reset passwords must be set to a
unique value for each user.
 Reset passwords must be
changed after the first use.
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.
 Set reset passwords to a unique
value for each existing user.
 Set reset passwords to be changed
after first use.
(check one)
In Place Not Not in
8.3 Incorporate two-factor authentication for remote network access originating from outside the
network, by personnel (including users and administrators) and all third parties, (including vendor
access for support or maintenance).
Note: Two-factor authentication requires that two of the three authentication methods (see
Requirement 8.2 for descriptions of authentication methods) be used for authentication. Using
☐ ☐ ☐ ☐ ☒
one factor twice (for example, using two separate passwords) is not considered two-factor
authentication.
Examples of two-factor technologies include remote authentication and dial-in service (RADIUS)
with tokens; terminal access controller access control system (TACACS) with tokens; and other
technologies that facilitate two-factor authentication.
8.3.a Examine system Describe how system configurations for remote access servers and systems were examined to verify two-factor authentication is
configurations for remote required for:
access servers and systems to  All remote access by personnel.
verify two-factor authentication
 All third-party/vendor remote access
is required for:
(including access to applications and
 All remote access by system components for support or
personnel. maintenance purposes).
 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 Identify the sample of personnel
personnel (for example, users observed connecting remotely to the
and administrators) connecting network selected.
(check one)
In Place Not Not in
remotely to the network and For each item in the sample, describe
verify that at least two of the how two-factor authentication was
three authentication methods observed to be required for remote
are used. access to the network.
Identify which two factors are used:
 Something you know
 Something you are
 Something you have
8.4 Document and communicate authentication policies and procedures to all users including:
 Guidance on selecting strong authentication credentials.
 Guidance for how users should protect their authentication credentials.
☐ ☐ ☐ ☐ ☒
 Instructions not to reuse previously used passwords.
 Instructions to change passwords if there is any suspicion the password could be
compromised.
8.4.a Examine procedures and Identify the documented policies and
interview personnel to verify procedures examined to verify
that authentication policies and authentication procedures define that
procedures are distributed to all authentication procedures and policies
users. are distributed to all users.
Identify the personnel interviewed who
confirm that authentication policies and
procedures are distributed to all users.
(check one)
In Place Not Not in
8.4.b Review authentication Identify the documented

policies and procedures that authentication policies and
are distributed to users and procedures that are distributed to
verify they include: users reviewed to verify they include:
 Guidance on selecting  Guidance on selecting strong
strong authentication authentication credentials.
credentials.  Guidance for how users should
 Guidance for how users protect their authentication
should protect their credentials.
authentication credentials.  Instructions for users not to reuse
 Instructions for users not to previously used passwords.
reuse previously used  That users should change
passwords. passwords if there is any
 Instructions to change suspicion the password could be
passwords if there is any compromised.
suspicion the password
could be compromised.
(check one)
In Place Not Not in
8.4.c Interview a sample of Identify the sample of users

users to verify that they are interviewed for this testing procedure.
familiar with authentication For the interview, summarize the
policies and procedures. relevant details discussed that verify
that the sampled users are familiar with
authentication policies and procedures.
8.5 Do not use group, shared, or generic IDs, passwords, or other authentication methods as
follows:
 Generic user IDs are disabled or removed. ☐ ☐ ☐ ☐ ☒
 Shared user IDs do not exist for system administration and other critical functions.
 Shared and generic user IDs are not used to administer any system components.
8.5.a For a sample of system Identify the sample of system
components, examine user ID components selected for this testing
lists to verify the following: procedure.
 Generic user IDs are For each item in the sample, describe how user ID lists for the sample of system components were examined to verify that:
disabled or removed.  Generic user IDs are disabled or
 Shared user IDs for system removed.
administration activities and  Shared user IDs for system
other critical functions do not administration activities and other
exist. critical functions do not exist.
 Shared and generic user IDs
 Shared and generic user IDs are not
are not used to administer
used to administer any system
any system components.
components.
(check one)
In Place Not Not in
8.5.b Examine authentication Identify the documented policies and

policies and procedures to procedures examined to verify
verify that use of group and authentication policies/procedures
shared IDs and/or passwords define that use of group and shared IDs
or other authentication methods and/or passwords or other
are explicitly prohibited. authentication methods are explicitly
prohibited.
8.5.c Interview system Identify the system administrators
administrators to verify that interviewed who confirm that group and
group and shared IDs and/or shared IDs and/or passwords or other
passwords or other authentication methods are not
authentication methods are not distributed, even if requested.
distributed, even if requested.
8.5.1 Additional requirement for service providers only: Service providers with remote
access to customer premises (for example, for support of POS systems or servers) must use a
unique authentication credential (such as a password/phrase) for each customer.
This requirement is not intended to apply to shared hosting providers accessing their own ☐ ☐ ☐ ☐ ☒
hosting environment, where multiple customer environments are hosted.
Note: Requirement 8.5.1 is a best practice until June 30, 2015, after which it becomes a
requirement.
8.5.1 Additional procedure Additional procedure for service No
for service provider provider assessments only, indicate
assessments only: Examine whether this ROC is being completed
authentication policies and prior to June 30, 2015. (yes/no)
procedures and interview If “yes” AND the assessed entity does not have this in place ahead of the requirement’s effective date, mark this as “Not Applicable.”
personnel to verify that different
If “no” OR if the assessed entity has this in place ahead of the requirement’s effective date, complete the following:
(check one)
In Place Not Not in
authentication credentials are Identify the documented procedures

used for access to each examined to verify that different
customer. authentication credentials are used for
access to each customer.
Identify the personnel interviewed for
this testing procedure.
relevant details discussed to confirm
that different authentication credentials
are used for access to each customer.
8.6 Where other authentication mechanisms are used (for example, physical or logical security
tokens, smart cards, certificates, etc.) use of these mechanisms must be assigned as follows:
 Authentication mechanisms must be assigned to an individual account and not shared among
☐ ☐ ☐ ☐ ☒
multiple accounts.
 Physical and/or logical controls must be in place to ensure only the intended account can use
that mechanism to gain access.
(check one)
In Place Not Not in
8.6.a Examine authentication Identify the documented

policies and procedures to authentication policies and
verify that procedures for using procedures examined to verify the
authentication mechanisms procedures for using authentication
such as physical security mechanisms define that:
tokens, smart cards, and  Authentication mechanisms are
certificates are defined and assigned to an individual account
include: and not shared among multiple
 Authentication mechanisms accounts.
are assigned to an individual  Physical and/or logical controls
account and not shared are defined to ensure only the
among multiple accounts. intended account can use that
 Physical and/or logical mechanism to gain access.
controls are defined to
ensure only the intended
account can use that
mechanism to gain access.
8.6.b Interview security Identify the security personnel
personnel to verify interviewed who confirm that
authentication mechanisms are authentication mechanisms are
assigned to an account and not assigned to an account and not shared
shared among multiple among multiple accounts.
accounts.
(check one)
In Place Not Not in
8.6.c Examine system Identify the sample of system

configuration settings and/or components selected for this testing
physical controls, as applicable, procedure.
to verify that controls are For each item in the sample, describe
implemented to ensure only the how system configuration settings
intended account can use that and/or physical controls, as applicable,
mechanism to gain access. were examined to verify that controls
are implemented to ensure only the
intended account can use that
mechanism to gain access.
8.7 All access to any database containing cardholder data (including access by applications,
administrators, and all other users) is restricted as follows:
 All user access to, user queries of, and user actions on databases are through programmatic
methods. ☐ ☐ ☐ ☐ ☒
 Only database administrators have the ability to directly access or query databases.
 Application IDs for database applications can only be used by the applications (and not by
individual users or other non-application processes).
8.7.a Review database and Identify all databases containing
application configuration cardholder data.
settings and verify that all users Describe how authentication is
are authenticated prior to managed (for example, via application
access. and/or database interfaces).
Describe how database and/or
application configuration settings were
observed to verify that all users are
authenticated prior to access.
(check one)
In Place Not Not in
8.7.b Examine database and For each database from 8.7.a:

application configuration Describe how the database and application configuration settings were examined to verify that only programmatic methods are
settings to verify that all user used for:
access to, user queries of, and
 All user access to the database
user actions on (for example,
move, copy, delete), the  All user queries of the database
database are through  All user actions on the database
programmatic methods only Describe the process observed to verify that only programmatic methods are used for:
(for example, through stored
 All user access to the database
procedures).
 All user queries of the database
 All user actions on the database
8.7.c Examine database For each database from 8.7.a, describe how database application configuration settings were examined to verify that the following
access control settings and are restricted to only database administrators:
database application  User direct access to databases
configuration settings to verify
 Queries of databases
that user direct access to or
queries of databases are
restricted to database
administrators.
(check one)
In Place Not Not in
8.7.d Examine database For each database from 8.7.a:

access control settings,  Identify applications with access to
database application the database.
configuration settings, and the
 Describe the implemented methods
related application IDs to verify
for ensuring that application IDs can
that application IDs can only be
only be used by the applications.
used by the applications (and
not by individual users or other  Describe how database access
processes). 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.
8.8 Ensure that security policies and operational procedures for identification and authentication
☐ ☐ ☐ ☐ ☒
are documented, in use, and known to all affected parties.
verify that security policies and operational procedures for identification
operational procedures for and authentication are documented.
identification and authenticationIdentify responsible personnel
are: interviewed who confirm that the above
 In use, and operational procedures for identification
and authentication are:
 In use
Requirement 9: Restrict physical access to cardholder data
(check one)
In Place Not Not in
and Testing Procedures Reporting Instruction Assessor’s Response In Place w/CCW N/A Tested Place
9.1 Use appropriate facility entry controls to limit and monitor physical access to systems in the
☒ ☐ ☐ ☐ ☐
9.1 Verify the existence of Identify and briefly describe all of the following with systems in the cardholder data environment:
physical security controls for  All computer rooms
each computer room, data
 All data centers
center, and other physical
areas with systems in the  Any other physical areas
cardholder data environment. For each area identified (add rows as needed), complete the following:
 Verify that access is Describe the physical security controls
controlled with badge to be in place, including authorized
readers or other devices badges and lock and key.
including authorized badges Identify the randomly selected systems
and lock and key. in the cardholder environment for which
 Observe a system a system administrator login attempt
administrator’s attempt to was observed.
log into consoles for
Describe how consoles for the
randomly selected systems
randomly selected systems were
in the cardholder
observed to verify that they are “locked”
environment and verify that
when not in use to prevent unauthorized
they are “locked” to prevent
use.
unauthorized use.
(check one)
In Place Not Not in
9.1.1 Use video cameras and/or access control mechanisms to monitor individual physical
access to sensitive areas. Review collected data and correlate with other entries. Store for at
least three months, unless otherwise restricted by law.
☒ ☐ ☐ ☐ ☐
Note: “Sensitive areas” refers to any data center, server room, or any area that houses systems
that store, process, or transmit cardholder data. This excludes public-facing areas where only
point-of-sale terminals are present, such as the cashier areas in a retail store.
9.1.1.a Verify that video Describe the video cameras and/or
cameras and/or access control access control mechanisms observed to
mechanisms are in place to monitor the entry/exit points to sensitive
monitor the entry/exit points to areas.
sensitive areas.
9.1.1.b Verify that video Describe how the video cameras
cameras and/or access control and/or access control mechanisms
mechanisms are protected were observed to be protected from
from tampering or disabling. tampering and/or disabling.
9.1.1.c Verify that data from Describe how the data from video
video cameras and/or access cameras and/or access control
control mechanisms is mechanisms were observed to be
reviewed, and that data is reviewed.
stored for at least three Describe how data was observed to be
months. stored for at least three months.
9.1.2 Implement physical and/or logical controls to restrict access to publicly accessible network
jacks.
For example, network jacks located in public areas and areas accessible to visitors could be
☒ ☐ ☐ ☐ ☐
disabled and only enabled when network access is explicitly authorized. Alternatively, processes
could be implemented to ensure that visitors are escorted at all times in areas with active
network jacks.
(check one)
In Place Not Not in
9.1.2 Interview responsible Identify responsible personnel

personnel and observe interviewed who confirm that physical
locations of publicly accessible and/or logical controls are in place to
network jacks to verify that restrict access to publicly accessible
physical and/or logical controls network jacks.
are in place to restrict access Describe the physical and/or logical
to publicly-accessible network controls observed at the locations of
jacks. publicly accessible network jacks to
verify the controls are in place restrict
access.
9.1.3 Restrict physical access to wireless access points, gateways, handheld devices,
☒ ☐ ☐ ☐ ☐
networking/communications hardware, and telecommunication lines.
9.1.3 Verify that physical Describe how physical access was observed to be restricted to the following:
access to wireless access  Wireless access points
points, gateways, handheld
 Wireless gateways
devices,
networking/communications  Wireless handheld devices
hardware, and  Network/communications hardware
telecommunication lines is
 Telecommunication lines
appropriately restricted.
9.2 Develop procedures to easily distinguish between onsite personnel and visitors, to include:
 Identifying onsite personnel and visitors (for example, assigning badges).
 Changes to access requirements. ☒ ☐ ☐ ☐ ☐
 Revoking or terminating onsite personnel and expired visitor identification (such as ID

badges).
(check one)
In Place Not Not in
9.2.a Review documented Identify the documented processes

processes to verify that reviewed to verify that procedures are
procedures are defined for defined for identifying and distinguishing
identifying and distinguishing between onsite personnel and visitors,
between onsite personnel and including the following:
visitors.  Identifying onsite personnel and
Verify procedures include the visitors (for example, assigning
following: badges),
 Identifying onsite personnel  Changing access requirements,
and visitors (for example, and
assigning badges),  Revoking terminated onsite
 Changing access personnel and expired visitor
requirements, and identification (such as ID badges).
 Revoking terminated onsite
personnel and expired
visitor identification (such as
ID badges).
9.2.b Examine identification Identify the identification methods examined.
methods (such as ID badges) Describe how processes for identifying and distinguishing between onsite personnel and visitors were observed to verify that:
and observe processes for
 Visitors are clearly identified, and
(check one)
In Place Not Not in
identifying and distinguishing  It is easy to distinguish between

between onsite personnel and onsite personnel and visitors.
visitors to verify that:
 Visitors are clearly identified,
and
 It is easy to distinguish
between onsite personnel
and visitors.
9.2.c Verify that access to the Identify the document that defines that
identification process (such as access to the identification process is
a badge system) is limited to limited to authorized personnel.
authorized personnel. Describe how access to the
identification process was observed to
be limited to authorized personnel.
9.3 Control physical access for onsite personnel to sensitive areas as follows:
 Access must be authorized and based on individual job function.
☒ ☐ ☐ ☐ ☐
 Access is revoked immediately upon termination, and all physical access mechanisms, such
as keys, access cards, etc., are returned or disabled.
9.3.a For a sample of onsite Identify the sample of onsite
personnel with physical access personnel with physical access to
to sensitive areas, interview sensitive areas interviewed for this
responsible personnel and testing procedure.
observe access control lists to For all items in the sample, describe how responsible personnel were interviewed and access control lists observed to verify that:
verify that:
 Access to the sensitive area is
authorized.
(check one)
In Place Not Not in
 Access to the sensitive area  Access is required for the individual’s

is authorized. job function.
 Access is required for the
individual’s job function.
9.3.b Observe personnel Describe how personnel accessing
accessing sensitive areas to sensitive areas were observed to verify
verify that all personnel are that all personnel are authorized before
authorized before being being granted access.
granted access.
9.3.c Select a sample of Identify the sample of users recently
recently terminated employees terminated.
and review access control lists For all items in the sample, provide the
to verify the personnel do not name of the assessor who attests that
have physical access to the access control lists were reviewed to
sensitive areas. verify the personnel do not have
physical access to sensitive areas.
9.4 Implement procedures to identify and authorize visitors.
Procedures should include the following:
9.4 Verify that visitor authorization and access controls are in place as follows:
9.4.1 Visitors are authorized before entering, and escorted at all times within, areas where
☒ ☐ ☐ ☐ ☐
cardholder data is processed or maintained.
(check one)
In Place Not Not in
9.4.1.a Observe procedures Describe how visitor authorization

and interview personnel to processes were observed to verify that
verify that visitors must be visitors:
authorized before they are  Must be authorized before they are
granted access to, and granted access to areas where
escorted at all times within, cardholder data is processed or
areas where cardholder data is maintained.
processed or maintained.  Are escorted at all times within
areas where cardholder data is
processed and maintained.
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.
9.4.1.b Observe the use of Describe how the use of visitor badges
visitor badges or other or other identification was observed to
identification to verify that a verify that a physical token badge does
physical token badge does not not permit unescorted access to
permit unescorted access to physical areas where cardholder data is
physical areas where processed or maintained.
cardholder data is processed
or maintained.
9.4.2 Visitors are identified and given a badge or other identification that expires and that visibly
☒ ☐ ☐ ☐ ☐
distinguishes the visitors from onsite personnel.
(check one)
In Place Not Not in
9.4.2.a Observe people within Describe how people within the facility
the facility to verify the use of were observed to use visitor badges or
visitor badges or other other identification.
identification, and that visitors Describe how visitors within the facility
are easily distinguishable from were observed to be easily
onsite personnel. distinguishable from onsite personnel.
9.4.2.b Verify that visitor Describe how visitor badges or other
badges or other identification identification were verified to expire.
expire.
9.4.3 Visitors are asked to surrender the badge or identification before leaving the facility or at
☒ ☐ ☐ ☐ ☐
the date of expiration.
9.4.3 Observe visitors leaving Describe how visitors leaving the
the facility to verify visitors are facility were observed to verify they are
asked to surrender their badge asked to surrender their badge or other
or other identification upon identification upon departure or
departure or expiration. expiration.
9.4.4 A visitor log is used to maintain a physical audit trail of visitor activity to the facility as well
as for 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.
Describe how it was verified that a visitor log is in use to record physical access to:
(check one)
In Place Not Not in
9.4.4.a Verify that a visitor log  The facility.

is in use to record physical  Computer rooms and data centers
access to the facility as well as where cardholder data is stored or
computer rooms and data transmitted.
centers where cardholder data
is stored or transmitted.
9.4.4.b Verify that the log Provide the name of the assessor
contains: who attests that the visitor log contains:
 The visitor’s name,  The visitor’s name,
 The firm represented, and  The firm represented, and
 The onsite personnel
 The onsite personnel authorizing
authorizing physical access. physical access.
9.4.4.c Verify that the log is Identify the defined retention period for
retained for at least three visitor logs.
months. Describe how visitor logs were
observed to be retained for at least
three months.
9.5 Physically secure all media. ☒ ☐ ☐ ☐ ☐
9.5 Verify that procedures for Identify the documented procedures

protecting cardholder data for protecting cardholder data
include controls for physically reviewed to verify controls for physically
securing all media (including securing all media are defined.
but not limited to computers, For all types of media used, describe
removable electronic media, the controls for physically securing the
paper receipts, paper reports, media used.
and faxes).
(check one)
In Place Not Not in
9.5.1 Store media backups in a secure location, preferably an off-site facility, such as an
alternate or back-up site, or a commercial storage facility. Review the location’s security at least ☒ ☐ ☐ ☐ ☐
annually.
9.5.1.a Observe the storage Identify all locations where backup
location’s physical security to media is stored.
confirm that backup media Describe how it was observed that
storage is secure. backup media storage is stored in a
secure location.
9.5.1.b Verify that the storage Identify the document reviewed to
location security is reviewed at verify that the storage location must be
least annually. reviewed at least annually.
Describe how processes were
observed to verify that reviews of the
security of each storage location are
performed at least annually.
9.6 Maintain strict control over the internal or external distribution of any kind of media, including
☒ ☐ ☐ ☐ ☐
the following:
9.6 Verify that a policy exists to Identify the documented policy to
control distribution of media, control distribution of media that was
and that the policy covers all reviewed to verify the policy covers all
distributed media including that distributed media, including that
distributed to individuals. distributed to individuals.
Describe how media distribution is
controlled, including distribution to
individuals.
9.6.1 Classify media so the sensitivity of the data can be determined. ☒ ☐ ☐ ☐ ☐
(check one)
In Place Not Not in
9.6.1 Verify that all media is Identify the documented policy

classified so the sensitivity of reviewed to verify policy defines how
the data can be determined. media is classified.
Describe how the classifications were
observed to be implemented so the
sensitivity of the data can be
determined.
9.6.2 Send the media by secured courier or other delivery method that can be accurately
☒ ☐ ☐ ☐ ☐
tracked.
9.6.2.a Interview personnel and Identify the personnel interviewed who
examine records to verify that confirm that all media sent outside the
all media sent outside the facility is logged and sent via secured
facility is logged and sent via courier or other delivery method that can
secured courier or other be tracked.
delivery method that can be Identify the records examined for this
tracked. testing procedure.
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.
9.6.2.b Select a recent sample Identify the sample of recent offsite
of several days of offsite tracking logs for all media selected.
tracking logs for all media, and For each item in the sample, describe
verify tracking details are how the offsite tracking logs were
documented. reviewed to verify that tracking details
are documented.
(check one)
In Place Not Not in
9.6.3 Ensure management approves any and all media that is moved from a secured area
☒ ☐ ☐ ☐ ☐
(including when media is distributed to individuals).
9.6.3 Select a recent sample of Identify responsible personnel
several days of offsite tracking interviewed who confirm that proper
logs for all media. From management authorization is obtained
examination of the logs and whenever media is moved from a
interviews with responsible secured area (including when media is
personnel, verify proper distributed to individuals).
management authorization is For each item in the sample in 9.6.2.b,
obtained whenever media is describe how offsite tracking logs were
moved from a secured area examined to verify proper management
(including when media is authorization is obtained whenever
distributed to individuals). media is moved from a secured area
(including when media is distributed to
individuals).
9.7 Maintain strict control over the storage and accessibility of media. ☒ ☐ ☐ ☐ ☐
9.7 Obtain and examine the Identify the documented policy for
policy for controlling storage controlling storage and maintenance
and maintenance of all media of all media that was reviewed to verify
and verify that the policy that the policy defines required periodic
requires periodic media media inventories.
inventories.
9.7.1 Properly maintain inventory logs of all media and conduct media inventories at least
☒ ☐ ☐ ☐ ☐
annually.
9.7.1 Review media inventory Identify the media inventories logs
logs to verify that logs are reviewed.
maintained and media Describe how the media inventory logs were reviewed to verify that:
(check one)
In Place Not Not in
inventories are performed at  Media inventory logs of all media

least annually. were observed to be maintained.
 Media inventories are performed at
least annually.
9.8 Destroy media when it is no longer needed for business or legal reasons as follows: ☒ ☐ ☐ ☐ ☐
(check one)
In Place Not Not in
9.8 Examine the periodic Identify the policy document for

media destruction policy and periodic media destruction that was
verify that it covers all media examined to verify it covers all media
and defines requirements for and defines requirements for the
the following: following:
 Hard-copy materials must  Hard-copy materials must be
be crosscut shredded, crosscut shredded, incinerated, or
incinerated, or pulped such pulped such that there is
that there is reasonable reasonable assurance the hard-
assurance the hard-copy copy materials cannot be
materials cannot be reconstructed.
reconstructed.  Storage containers used for
 Storage containers used for materials that are to be destroyed
materials that are to be must be secured.
destroyed must be secured.  Cardholder data on electronic
 Cardholder data on media must be rendered
electronic media must be unrecoverable (e.g. via a secure
rendered unrecoverable wipe program in accordance with
(e.g. via a secure wipe industry-accepted standards for
program in accordance with secure deletion, or by physically
industry-accepted standards destroying the media).
for secure deletion, or by
physically destroying the
media).
9.8.1 Shred, incinerate, or pulp hard-copy materials so that cardholder data cannot be
☒ ☐ ☐ ☐ ☐
reconstructed. Secure storage containers used for materials that are to be destroyed.
(check one)
In Place Not Not in
9.8.1.a Interview personnel and Identify personnel interviewed who

examine procedures to verify confirm that hard-copy materials are
that hard-copy materials are crosscut shredded, incinerated, or
crosscut shredded, incinerated, pulped such that there is reasonable
or pulped such that there is assurance the hard-copy materials
reasonable assurance the cannot be reconstructed.
hard-copy materials cannot be Describe how the procedures were
reconstructed. 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.
9.8.1.b Examine storage Describe how the storage containers
containers used for materials used for materials to be destroyed are
that contain information to be secured.
destroyed to verify that the
containers are secured.
9.8.2 Render cardholder data on electronic media unrecoverable so that cardholder data cannot
☒ ☐ ☐ ☐ ☐
be reconstructed.
9.8.2 Verify that cardholder Describe how cardholder data on
data on electronic media is electronic media is rendered
rendered unrecoverable (e.g. unrecoverable, via secure wiping of
via a secure wipe program in media and/or physical destruction of
accordance with industry- media.
(check one)
In Place Not Not in
accepted standards for secure If data is rendered unrecoverable via

deletion, or by physically secure deletion or a secure wipe
destroying the media). program, identify the industry-
accepted standards used.
9.9 Protect devices that capture payment card data via direct physical interaction with the card
from tampering and substitution.
Note: These requirements apply to card-reading devices used in card-present transactions (that
is, card swipe or dip) at the point of sale. This requirement is not intended to apply to manual ☒ ☐ ☐ ☐ ☐
key-entry components such as computer keyboards and POS keypads.
Note: Requirement 9.9 is a best practice until June 30, 2015, after which it becomes a
requirement.
9.9 Examine documented Indicate whether this ROC is being No
policies and procedures to completed prior to June 30, 2015.
verify they include: (yes/no)
 Maintaining a list of devices. If “yes” AND the assessed entity does not have this in place ahead of the requirement’s effective date, mark 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:
(check one)
In Place Not Not in
 Periodically inspecting Identify the documented policies and

devices to look for procedures examined to verify they
tampering or substitution. include:
 Training personnel to be  Maintaining a list of devices.
aware of suspicious  Periodically inspecting devices to
behavior and to report look for tampering or substitution.
tampering or substitution of  Training personnel to be aware of
POS devices. suspicious behavior and to report
tampering or substitution of POS
devices.
9.9.1 Maintain an up-to-date list of devices. The list should include the following:
 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.a Examine the list of If “yes” at 9.9 AND the assessed entity does not have this in place ahead of the requirement’s effective date, mark 9.9.1.a -9.9.1.c as
devices to verify it includes: “Not Applicable.”
 Make, model of device. If not OR if the assessed entity has this in place ahead of the requirement’s effective date, complete the following:
 Location of device (for Identify the documented up-to-date
example, the address of the list of devices examined to verify it
site or facility where the includes:
device is located).  Make, model of device.
 Device serial number or
 Location of device (for example,
other method of unique
the address of the site or facility
identification.
where the device is located).
 Device serial number or other
method of unique identification.
(check one)
In Place Not Not in
9.9.1.b Select a sample of Identify the sample of devices from the

devices from the list and list selected for this testing procedure.
observe devices and device For all items in the sample, describe
locations to verify that the list is how the devices and device locations
accurate and up-to-date. for the sample of devices were observed
to verify that the list is accurate and up-
to-date.
9.9.1.c Interview personnel to Identify personnel interviewed for this
verify the list of devices is testing procedure.
updated when devices are For the interview, summarize the
added, relocated, relevant details discussed that verify
decommissioned, etc. the list of devices is updated when
devices are added, relocated,
decommissioned, etc.
9.9.2 Periodically inspect device surfaces to detect tampering (for example, addition of card
skimmers to devices), or substitution (for example, by checking the serial number or other device
characteristics to verify it has not been swapped with a fraudulent device).
☒ ☐ ☐ ☐ ☐
Note: Examples of signs that a device might have been tampered with or substituted include
unexpected attachments or cables plugged into the device, missing or changed security labels,
broken or differently colored casing, or changes to the serial number or other external markings.
9.9.2.a Examine documented If “yes” at 9.9 AND the assessed entity does not have this in place ahead of the requirement’s effective date, mark 9.9.2.a -9.9.2.b as
procedures to verify processes “Not Applicable.”
If not OR if the assessed entity has this in place ahead of the requirement’s effective date, complete the following:
(check one)
In Place Not Not in
are defined to include the Identify the documented procedures

following: examined to verify that processes are
 Procedures for inspecting defined to include the following:
devices.  Procedures for inspecting devices.
 Frequency of inspections.  Frequency of inspections.
9.9.2.b Interview responsible Identify responsible personnel
personnel and observe interviewed who confirm that:
inspection processes to verify:  Personnel are aware of
 Personnel are aware of procedures for inspecting devices.
procedures for inspecting  All devices are periodically
devices. inspected for evidence of
 All devices are periodically tampering and substitution.
inspected for evidence of Describe how inspection processes were observed to verify that:
tampering and substitution.
 All devices are periodically inspected
for evidence of tampering.
 All devices are periodically inspected
for evidence of substitution.
9.9.3 Provide training for personnel to be aware of attempted tampering or replacement of
devices. Training should include the following:
 Verify the identity of any third-party persons claiming to be repair or maintenance personnel,
prior to granting them access to modify or troubleshoot devices.
 Do not install, replace, or return devices without verification. ☒ ☐ ☐ ☐ ☐
 Be aware of suspicious behavior around devices (for example, attempts by unknown persons
to unplug or open devices).
 Report suspicious behavior and indications of device tampering or substitution to appropriate
personnel (for example, to a manager or security officer).
(check one)
In Place Not Not in
9.9.3.a Review training If “yes” at 9.9 AND the assessed entity does not have this in place ahead of the requirement’s effective date, mark 9.9.3.a -9.9.3.b as
materials for personnel at “Not Applicable.”
point-of-sale locations to verify If not OR if the assessed entity has this in place ahead of the requirement’s effective date, complete the following:
it includes training in the
following: Identify the training materials for
 Verifying the identity of any personnel at point-of-sale locations
third-party persons claiming that were reviewed to verify the
to be repair or maintenance materials include training in the
personnel, prior to granting following:
them access to modify or  Verifying the identity of any third-
troubleshoot devices. party persons claiming to be repair
 Not to install, replace, or or maintenance personnel, prior to
return devices without granting them access to modify or
verification. troubleshoot devices.
 Being aware of suspicious  Not to install, replace, or return
behavior around devices (for devices without verification.
example, attempts by  Being aware of suspicious
unknown persons to unplug behavior around devices (for
or open devices). example, attempts by unknown
 Reporting suspicious persons to unplug or open
behavior and indications of devices).
device tampering or  Reporting all suspicious behavior
substitution to appropriate to appropriate personnel (for
personnel (for example, to a example, a manager or security
manager or security officer). officer).
 Reporting tampering or substitution
of devices.
(check one)
In Place Not Not in
9.9.3.b Interview a sample of Identify the sample of personnel at

personnel at point-of-sale point-of-sale locations interviewed to
locations to verify they have verify they have received training.
received training and are For the interview, summarize the relevant details discussed that verify interviewees are aware of the procedures for the following:
aware of the procedures for the
 Verifying the identity of any third-
following:
party persons claiming to be repair or
 Verifying the identity of any
maintenance personnel, prior to
third-party persons claiming
granting them access to modify or
to be repair or maintenance
troubleshoot devices.
personnel, prior to granting
them access to modify or  Not to install, replace, or return
troubleshoot devices. devices without verification.
 Not to install, replace, or  Being aware of suspicious behavior
return devices without around devices (for example,
verification. attempts by unknown persons to
 Being aware of suspicious unplug or open devices).
behavior around devices (for  Reporting suspicious behavior and
example, attempts by indications of device tampering or
unknown persons to unplug substitution to appropriate personnel
or open devices). (for example, to a manager or
 Reporting suspicious security officer).
behavior and indications of
device tampering or
substitution to appropriate
personnel (for example, to a
manager or security officer).
9.10 Ensure that security policies and operational procedures for restricting physical access to
☒ ☐ ☐ ☐ ☐
cardholder data are documented, in use, and known to all affected parties.
(check one)
In Place Not Not in

verify that security policies and operational procedures for restricting
operational procedures for physical access to cardholder data are
restricting physical access to documented.
cardholder data are: Identify responsible personnel interviewed who confirm that the above documented security
 Documented, policies and operational procedures for restricting physical access to cardholder data are:
 In use, and  In use
 Known to all affected  Known to all affected parties
parties.
Regularly Monitor and Test Networks
Requirement 10: Track and monitor all access to network resources and cardholder data
(check one)
In Place Not Not in
10.1 Implement audit trails to link all access to system components to each individual user. ☐ ☐ ☒ ☐ ☐
10.1 Verify, through Identify the system administrator(s) here is my na resp for req 10
observation and interviewing interviewed who confirm that:
the system administrator, that:  Audit trails are enabled and active
 Audit trails are enabled and for system components.
active for system  Access to system components is
components. linked to individual users.
 Access to system Describe how audit trails were observed to verify the following:
components is linked to  Audit trails are enabled and active for Not Applicable
individual users. system components.
 Access to system components is Not Applicable
linked to individual users.
(check one)
In Place Not Not in
10.2 Implement automated audit trails for all system components to reconstruct the following
☐ ☐ ☒ ☐ ☐
events:
10.2 Through interviews of Identify the responsible personnel here is my na resp for req 10
responsible personnel, interviewed who confirm the following
observation of audit logs, and from 10.2.1-10.2.7 are logged:
examination of audit log  All individual access to cardholder
settings, perform the following: data.
 All actions taken by any individual
with root or administrative
privileges.
 Access to all audit trails.
 Invalid logical access attempts.Use
of and changes to identification and
authentication mechanisms,
including:
o All elevation of privileges.
o All changes, additions, or
deletions to any account
privileges.
 Initialization of audit logs.
 Stopping or pausing of audit logs.
 Creation and deletion of system
level objects.
(check one)
In Place Not Not in
Identify the sample of audit logs Not Applicable

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
privileges.
 Access to all audit trails.
 Invalid logical access attempts.
 Use of and changes to
identification and authentication
mechanisms, including.
o All elevation of privileges.
o All changes, additions, or
deletions to any account
privileges.
 Initialization of audit logs.
 Stopping or pausing of audit logs.
 Creation and deletion of system
level objects.
10.2.1 All individual user accesses to cardholder data. ☐ ☐ ☒ ☐ ☐
(check one)
In Place Not Not in
10.2.1 Verify all individual For all items in the sample at 10.2, here is my na resp for req 10
access to cardholder data is describe how configuration settings
logged. were observed to verify all individual
access to cardholder data is logged.
10.2.2 All actions taken by any individual with root or administrative privileges. ☐ ☐ ☒ ☐ ☐
10.2.2 Verify all actions taken For all items in the sample at 10.2, here is my na resp for req 10
by any individual with root or describe how configuration settings
administrative privileges are were observed to verify all actions taken
logged. by any individual with root or
administrative privileges are logged.
10.2.3 Access to all audit trails. ☐ ☐ ☒ ☐ ☐
10.2.3 Verify access to all For all items in the sample at 10.2, here is my na resp for req 10
audit trails is logged. describe how configuration settings
were observed to verify access to all
audit trails is logged.
10.2.4 Invalid logical access attempts. ☐ ☐ ☒ ☐ ☐
10.2.4 Verify invalid logical For all items in the sample at 10.2, here is my na resp for req 10
access attempts are logged. describe how configuration settings
were observed to verify invalid logical
access attempts are logged.
10.2.5 Use of and changes to identification and authentication mechanisms—including but not
limited to creation of new accounts and elevation of privileges—and all changes, additions, or ☐ ☐ ☒ ☐ ☐
deletions to accounts with root or administrative privileges.
(check one)
In Place Not Not in
10.2.5.a Verify use of For all items in the sample at 10.2, here is my na resp for req 10
identification and describe how configuration settings
authentication mechanisms is were observed to verify use of
logged. identification and authentication
mechanisms is logged.
10.2.5.b Verify all elevation of For all items in the sample at 10.2, Not Applicable
privileges is logged. describe how configuration settings
were observed to verify all elevation of
privileges is logged.
10.2.5.c Verify all changes, For all items in the sample at 10.2, Not Applicable
additions, or deletions to any describe how configuration settings
account with root or were observed to verify all changes,
administrative privileges are additions, or deletions to any account
logged. with root or administrative privileges are
logged.
10.2.6 Initialization, stopping, or pausing of the audit logs. ☐ ☐ ☒ ☐ ☐
10.2.6 Verify the following are For all items in the sample at 10.2, here is my na resp for req 10
logged: describe how configuration settings
 Initialization of audit logs. were observed to verify initialization of
 Stopping or pausing of audit audit logs is logged.
logs. For all items in the sample at 10.2, Not Applicable
describe how configuration settings
were observed to verify stopping and
pausing of audit logs is logged.
10.2.7 Creation and deletion of system-level objects. ☐ ☐ ☒ ☐ ☐
(check one)
In Place Not Not in
10.2.7 Verify creation and For all items in the sample at 10.2, here is my na resp for req 10
deletion of system level describe how configuration settings
objects are logged. were observed to verify creation and
deletion of system level objects are
logged.
10.3 Record at least the following audit trail entries for all system components for each event: ☐ ☐ ☒ ☐ ☐
10.3 Through interviews and Identify the responsible personnel here is my na resp for req 10
observation of audit logs, for interviewed who confirm that for each
each auditable event (from auditable event from 10.2.1-10.2.7, the
10.2), perform the following: following are included in log entries:
 User identification
 Type of event
 Date and time
 Success or failure indication
 Origination of event
Identify the sample of audit logs from Not Applicable
10.2.1-10.2.7 observed to verify the
following are included in log entries:
 User identification
 Type of event
 Date and time
 Success or failure indication
 Origination of event
10.3.1 User identification ☐ ☐ ☒ ☐ ☐
(check one)
In Place Not Not in
10.3.1 Verify user identification For all logs in the sample at 10.3, here is my na resp for req 10
is included in log entries. describe how the audit logs were
observed to verify user identification is
included in log entries.
10.3.2 Type of event ☐ ☐ ☒ ☐ ☐
10.3.2 Verify type of event is For all logs in the sample at 10.3, here is my na resp for req 10
included in log entries. describe how the audit logs were
observed to verify type of event is
10.3.3 Date and time ☐ ☐ ☒ ☐ ☐
10.3.3 Verify date and time For all logs in the sample at 10.3, here is my na resp for req 10
stamp is included in log describe how the audit logs were
entries. observed to verify date and time stamp
is included in log entries.
10.3.4 Success or failure indication ☐ ☐ ☒ ☐ ☐
10.3.4 Verify success or failure For all logs in the sample at 10.3, here is my na resp for req 10
indication is included in log describe how the audit logs were
entries. observed to verify success or failure
indication is included in log entries.
10.3.5 Origination of event ☐ ☐ ☒ ☐ ☐
10.3.5 Verify origination of For all logs in the sample at 10.3, here is my na resp for req 10
event is included in log entries. describe how the audit logs were
observed to verify origination of event is
10.3.6 Identity or name of affected data, system component, or resource ☐ ☐ ☒ ☐ ☐
(check one)
In Place Not Not in
10.3.6 Verify identity or name For all logs in the sample at 10.3, here is my na resp for req 10
of affected data, system describe how the audit logs were
component, or resources is observed to verify the identity or name of
included in log entries. affected data, system component, or
resource is included in log entries.
10.4 Using time-synchronization technology, synchronize all critical system clocks and times
and ensure that the following is implemented for acquiring, distributing, and storing time. ☐ ☐ ☒ ☐ ☐
Note: One example of time synchronization technology is Network Time Protocol (NTP).
10.4 Examine configuration Identify the time synchronization here is my na resp for req 10
standards and processes to technologies in use. (If NTP, include
verify that time- version)
synchronization technology is Identify the documented time- Not Applicable
implemented and kept current synchronization process that defines
per PCI DSS Requirements processes for ensuring the time
6.1 and 6.2. synchronization technologies are kept
current per PCI DSS Requirements 6.1
and 6.2.
Describe how processes were examined to verify that time synchronization technologies are:
 Implemented. Not Applicable
 Kept current, per the documented Not Applicable

process.
10.4.1 Critical systems have the correct and consistent time. ☐ ☐ ☒ ☐ ☐
(check one)
In Place Not Not in
10.4.1.a Examine the process Identify the documented process for here is my na resp for req 10
for acquiring, distributing and acquiring, distributing, and storing
storing the correct time within the correct time within the
the organization to verify that: organization examined to verify that the
 Only the designated central process defines the following:
time server(s) receive time  Only the designated central time
signals from external server(s) receive time signals from
sources, and time signals external sources, and time signals
from external sources are from external sources are based on
based on International International Atomic Time or UTC.
Atomic Time or UTC.  Where there is more than one
 Where there is more than designated time server, the time
one designated time server, servers peer with one another to
the time servers peer with keep accurate time.
one another to keep  Systems receive time information
accurate time. only from designated central time
 Systems receive time
server(s).
information only from
designated central time
server(s).
(check one)
In Place Not Not in
10.4.1.b Observe the time- Identify the sample of system Not Applicable
related system-parameter components selected for 10.4.1.b-
settings for a sample of 10.4.2.b
system components to verify: For all items in the sample, describe how the time-related system-parameter settings for the sample of system components were
 Only the designated central observed to verify:
time server(s) receive time  Only the designated central time Not Applicable
signals from external server(s) receive time signals from
sources, and time signals external sources, and time signals
from external sources are from external sources are based on
based on International International Atomic Time or UTC.
Atomic Time or UTC.
 Where there is more than one Not Applicable
 Where there is more than
designated time server, the
one designated time server,
designated central time server(s) peer
the designated central time
with one another to keep accurate
server(s) peer with one
time.
another to keep accurate
time.  Systems receive time only from Not Applicable
 Systems receive time only designated central time server(s).

from designated central time
server(s).
10.4.2 Time data is protected. ☐ ☐ ☒ ☐ ☐
(check one)
In Place Not Not in
10.4.2.a Examine system Identify the documented time- here is my na resp for req 10
configurations and time- synchronization procedures examined
synchronization settings to to verify procedures define that:
verify that access to time data  Access to time data is restricted to
is restricted to only personnel only personnel with a business
with a business need to need to access time data.
access time data.  Define which personnel have a
business need to access time data.
Identify the authorized personnel Not Applicable
interviewed who confirm that personnel
with access to time data have a business
need to access time data.
For all items in the sample from 10.4.1, Not Applicable
describe how configuration settings
were examined to restrict access to time
data to only personnel with a
documented need.
10.4.2.b Examine system Identify the documented time- Not Applicable
configurations, time synchronization procedures examined
synchronization settings and to verify procedures define that changes
logs, and processes to verify to time settings on critical systems must
that any changes to time be:
settings on critical systems are  Logged
logged, monitored, and  Monitored
reviewed.
 Reviewed
(check one)
In Place Not Not in

describe how configuration settings on
the sampled system components were
examined to log any changes to time
settings on critical systems.
describe how logs were examined to
log any changes to time settings on
critical systems.
Describe how time synchronization processes were examined to verify changes to time settings on
critical systems are:
 Logged Not Applicable
 Monitored Not Applicable
 Reviewed Not Applicable
10.4.3 Time settings are received from industry-accepted time sources. ☐ ☐ ☒ ☐ ☐
10.4.3 Examine systems Identify the document reviewed to here is my na resp for req 10
configurations to verify that the verify it defines that:
time server(s) accept time  Time settings are configured to
updates from specific, either accept time updates from
industry-accepted external specific, industry-accepted time
sources (to prevent a sources; OR
malicious individual from  The updates are encrypted with a
changing the clock). symmetric key and access control
Optionally, those updates can lists specify the IP addresses of
be encrypted with a symmetric client machines that will be
key, and access control lists provided with the time updates.
(check one)
In Place Not Not in
can be created that specify the Identify the sample of time servers Not Applicable
IP addresses of client selected.
machines that will be provided For all items in the sample, describe how configuration settings were examined to verify either of the following:
with the time updates (to
 That the time servers receive time Not Applicable
prevent unauthorized use of
updates from specific, industry-
internal time servers).
accepted external sources. OR
 That time updates are encrypted with Not Applicable
a symmetric key, and access control
lists specify the IP addresses of client
machines.
Identify the industry-accepted time Not Applicable
source indicated (if applicable).
10.5 Secure audit trails so they cannot be altered. ☐ ☐ ☒ ☐ ☐
(check one)
In Place Not Not in
10.5 Interview system Identify the system administrators here is my na resp for req 10
administrators and examine interviewed who confirm that audit trails
system configurations and are secured so that they cannot be
permissions to verify that audit altered as follows (from 10.5.1-10.5.5):
trails are secured so that they  Only individuals who have a job-
cannot be altered as follows: 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.
 for
PCI DSS Template for Report on Compliance Useuse file-integrity monitoring
with PCI DSS v3.1, or
Revision 1.0 April 2015
(check one)
In Place Not Not in
Identify the sample of system Not Applicable

components selected for this testing
procedure from 10.5.1-10.5.5.
10.5.1 Limit viewing of audit trails to those with a job-related need. ☐ ☐ ☒ ☐ ☐
10.5.1 Only individuals who For each item in the sample at 10.5, here is my na resp for req 10
have a job-related need can describe how system configurations
view audit trail files. and permissions were examined to verify
they restrict viewing of audit trail files to
only individuals who have a documented
job-related need.
10.5.2 Protect audit trail files from unauthorized modifications. ☐ ☐ ☒ ☐ ☐
10.5.2 Current audit trail files For each item in the sample at 10.5, here is my na resp for req 10
are protected from describe how system configurations
unauthorized modifications via and permissions were examined to verify
access control mechanisms, that current audit trail files are protected
physical segregation, and/or from unauthorized modifications. (e.g.,
network segregation. via access control mechanisms, physical
segregation, and/or network
segregation).
10.5.3 Promptly back up audit trail files to a centralized log server or media that is difficult to
☐ ☐ ☒ ☐ ☐
alter.
10.5.3 Current audit trail files For each item in the sample at 10.5, here is my na resp for req 10
are promptly backed up to a describe how system configurations
centralized log server or media and permissions were examined to verify
that is difficult to alter. that current audit trail files are promptly
backed up to a centralized log server or
media that is difficult to alter.
(check one)
In Place Not Not in
Identify and briefly describe the following:
 The centralized log server or media to Not Applicable

which audit trail files are backed up.
 How frequently the audit trail files are Not Applicable
backed up, and how the frequency is
appropriate.
 How the centralized log server or Not Applicable
media is difficult to alter.
10.5.4 Write logs for external-facing technologies onto a secure, centralized, internal log server
☐ ☐ ☒ ☐ ☐
or media device.
10.5.4 Logs for external-facing For each item in the sample at 10.5, here is my na resp for req 10
technologies (for example, describe how system configurations
wireless, firewalls, DNS, mail) and permissions were examined to verify
are written onto a secure, that logs for external-facing technologies
centralized, internal log server are written onto a secure, centralized,
or media. internal log server or media.
Describe how logs for external-facing Not Applicable
technologies are written onto a secure
centralized internal log server or media.
10.5.5 Use file-integrity monitoring or change-detection software on logs to ensure that existing
log data cannot be changed without generating alerts (although new data being added should ☐ ☐ ☒ ☐ ☐
not cause an alert).
10.5.5 Examine system For each item in the sample at 10.5, describe how the following were examined to verify the use of
settings, monitored files, and file-integrity monitoring or change-detection software on logs:
(check one)
In Place Not Not in
results from monitoring  System settings here is my na resp for req 10

activities to verify the use of  Monitored files Not Applicable
file-integrity monitoring or
 Results from monitoring activities Not Applicable
change-detection software on
logs. Identify the file-integrity monitoring Not Applicable
(FIM) or change-detection software
verified to be in use.
10.6 Review logs and security events for all system components to identify anomalies or suspicious activity.
Note: Log harvesting, parsing, and alerting tools may be used to meet this Requirement.
10.6 Perform the following:
10.6.1 Review the following at least daily:
 All security events
 Logs of all system components that store, process, or transmit 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.).
(check one)
In Place Not Not in
10.6.1.a Examine security Identify the documented security here is my na resp for req 10
policies and procedures to policies and procedures examined to
verify that procedures are verify that procedures define reviewing
defined for, reviewing the the following at least daily, either
following at least daily, either manually or via log tools:
manually or via log tools:  All security events
 All security events  Logs of all system components that
 Logs of all system store, process, or transmit CHD
components that store, and/or SAD
process, or transmit CHD  Logs of all critical system
and/or SAD components
 Logs of all critical system
 Logs of all servers and system
components
components that perform security
 Logs of all servers and
functions.
system components that
perform security functions Describe the manual or log tools used Not Applicable
(for example, firewalls, for daily review of logs.

intrusion-detection
systems/intrusion-prevention
systems (IDS/IPS),
authentication servers, e-
commerce redirection
servers, etc.).
(check one)
In Place Not Not in
10.6.1.b Observe processes Identify the personnel interviewed who Not Applicable
and interview personnel to confirm that the following are reviewed at
verify that the following are least daily:
reviewed at least daily:  All security events
 All security events  Logs of all system components that
 Logs of all system store, process, or transmit CHD
components that store, and/or SAD
process, or transmit CHD  Logs of all critical system
and/or SAD components
 Logs of all critical system
 Logs of all servers and system
components
 Logs of all servers and
functions.
system components that
Describe how processes were observed to verify that the following are reviewed at least daily:
perform security functions
(for example, firewalls,  All security events. Not Applicable
intrusion-detection
 Logs of all system components that Not Applicable
systems/intrusion-prevention
store, process, or transmit CHD
systems (IDS/IPS),
and/or SAD.
authentication servers, e-
commerce redirection  Logs of all critical system Not Applicable
servers, etc.) components.

 Logs of all servers and system Not Applicable
functions.
10.6.2 Review logs of all other system components periodically based on the organization’s
policies and risk management strategy, as determined by the organization’s annual risk ☐ ☐ ☒ ☐ ☐
assessment.
(check one)
In Place Not Not in
verify that procedures are verify that procedures define reviewing
defined for reviewing logs of logs of all other system components
all other system components periodically—either manually or via log
periodically—either manually tools—based on the organization’s
or via log tools—based on the policies and risk management strategy.
organization’s policies and risk Describe the manual or log tools Not Applicable
management strategy. defined for periodic review of logs of all
other system components.
10.6.2.b Examine the Identify the organization’s risk Not Applicable
organization’s risk assessment assessment documentation examined
documentation and interview to verify that reviews are performed in
personnel to verify that accordance with the organization’s
reviews are performed in policies and risk management strategy.
accordance with organization’s Identify the personnel interviewed for Not Applicable
policies and risk management this testing procedure.
strategy.
that reviews are performed in
accordance with the organization’s
policies and risk management strategy.
10.6.3 Follow up exceptions and anomalies identified during the review process. ☐ ☐ ☒ ☐ ☐
(check one)
In Place Not Not in
verify that procedures are verify that procedures define following up
defined for following up on on exceptions and anomalies identified
exceptions and anomalies during the review process.
identified during the review
process.
10.6.3.b Observe processes Describe how processes were observed Not Applicable
and interview personnel to to verify that follow-up to exceptions and
verify that follow-up to anomalies is performed.
exceptions and anomalies is Identify the personnel interviewed who Not Applicable
performed. confirm that follow-up to exceptions and
anomalies is performed.
10.7 Retain audit trail history for at least one year, with a minimum of three months immediately
☐ ☐ ☒ ☐ ☐
available for analysis (for example, online, archived, or restorable from backup).
10.7.a Examine security Identify the documented security here is my na resp for req 10
verify that they define the verify that procedures define the
following: following:
 Audit log retention policies.  Audit log retention policies.
 Procedures for retaining  Procedures for retaining audit logs
audit logs for at least one for at least one year, with a
year, with a minimum of minimum of three months
three months immediately immediately available online.
available online.
(check one)
In Place Not Not in
10.7.b Interview personnel Identify the personnel interviewed who Not Applicable
and examine audit logs to confirm that audit logs are retained for at
verify that audit logs are least one year.
retained for at least one year. Describe how the audit logs were Not Applicable
examined to verify that audit logs are
retained for at least one year.
10.7.c Interview personnel and observe Identify the personnel interviewed who Not Applicable
processes to verify that at least the last
three months’ logs are immediately confirm that at least the last three
available for analysis. months’ logs are immediately available
for analysis.
Describe the processes observed to Not Applicable
verify that at least the last three months’
logs are immediately available for
analysis.
10.8 Ensure 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.
10.8 Examine documentation Identify the document reviewed to here is my na resp for req 10
verify that security policies and operational procedures for monitoring all
operational procedures for access to network resources and
monitoring all access to cardholder data are documented.
(check one)
In Place Not Not in
network resources and Identify responsible personnel Not Applicable

cardholder data are: interviewed who confirm that the above
operational procedures for monitoring all
 In use, and
access to network resources and
 Known to all affected cardholder data are:
parties.
 In use
Requirement 11: Regularly test security systems and processes
(check one)
In In Place w/ Not Not in
and Testing Procedures Reporting Instruction Assessor’s Response Place CCW N/A Tested Place
11.1 Implement processes to test for the presence of wireless access points (802.11), and
detect and identify all authorized and unauthorized wireless access points on a quarterly basis.
Note: Methods that may be used in the process include but are not limited to wireless network
scans, physical/logical inspections of system components and infrastructure, network access ☐ ☒ ☐ ☐ ☐
control (NAC), or wireless IDS/IPS.
Whichever methods are used, they must be sufficient to detect and identify both authorized and
unauthorized devices.
11.1.a Examine policies and Identify the documented policies and
procedures to verify processes procedures examined to verify
are defined for detection and processes are defined for detection and
identification of both identification of authorized and
authorized and unauthorized unauthorized wireless access points on
wireless access points on a a quarterly basis.
quarterly basis.
11.1.b Verify that the Describe how the methodology/processes were verified to be adequate to detect and identify unauthorized wireless access points,
methodology is adequate to including the following:
detect and identify any  WLAN cards inserted into system
unauthorized wireless access components.
points, including at least the
 Portable or mobile devices attached to
following:
system components to create a
 WLAN cards inserted into wireless access point.
system components.  Wireless devices attached to a
network port or network device.
(check one)
 Portable or mobile devices  Any other unauthorized wireless

attached to system access point.
components to create a
wireless access point (for
example, by USB, etc.).
 Wireless devices attached
to a network port or network
device.
11.1.c If wireless scanning is Indicate whether wireless scanning is Not Applicable
utilized, examine output from utilized. (yes/no)
recent wireless scans to verify If ‘no,’ mark the remainder of 11.1.c as
that: ‘not applicable.’
 Authorized and If ‘yes,’ Identify/describe the output Not Applicable
unauthorized wireless from recent wireless scans examined to
access points are identified, verify that:
and  Authorized wireless access points
 The scan is performed at are identified.
least quarterly for all system  Unauthorized wireless access
components and facilities. points are identified.
 The scan is performed at least
quarterly.
 The scan covers all system
components.
 The scan covers all facilities.
11.1.d If automated monitoring Indicate whether automated monitoring Yes
is utilized (for example, is utilized. (yes/no)
(check one)
wireless IDS/IPS, NAC, etc.), If “no,” mark the remainder of 11.1.d as “Not Applicable.”
verify the configuration will If “yes,” complete the following:
generate alerts to notify Identify and describe any automated
personnel. monitoring technologies in use.
For each monitoring technology in use,
describe how the technology generates
alerts to personnel.
11.1.1 Maintain an inventory of authorized wireless access points including a documented
☐ ☒ ☐ ☐ ☐
business justification.
11.1.1 Examine documented Identify the documented inventory
records to verify that an records of authorized wireless access
inventory of authorized points examined to verify that an
wireless access points is inventory of authorized wireless access
maintained and a business points is maintained and a business
justification is documented for justification is documented for all
all authorized wireless access authorized wireless access points.
points.
11.1.2 Implement incident response procedures in the event unauthorized wireless access
☐ ☒ ☐ ☐ ☐
points are detected.
11.1.2.a Examine the Identify the Incident Response Plan
organization’s incident document examined that defines and
response plan (Requirement requires response in the event that an
12.10) to verify it defines and unauthorized wireless access point is
requires a response in the detected.
event that an unauthorized
wireless access point is
detected.
(check one)
11.1.2.b Interview responsible Identify the responsible personnel

personnel and/or inspect interviewed for this testing procedure.
recent wireless scans and For the interview, summarize the
related responses to verify relevant details discussed that verify
action is taken when that action is taken when unauthorized
unauthorized wireless access wireless access points are found.
points are found.
And/or:
Identify the recent wireless scans

inspected for this testing procedure.
Describe how the recent wireless scans
and related responses were inspected to
verify that action is taken when
unauthorized wireless access points are
found.
11.2 Run internal and external network vulnerability scans at least quarterly and after any
significant change in the network (such as new system component installations, changes in
network topology, firewall rule modifications, product upgrades).
Note: Multiple scan reports can be combined for the quarterly scan process to show that all
systems were scanned and all applicable vulnerabilities have been addressed. Additional
documentation may be required to verify non-remediated vulnerabilities are in the process of
being addressed. ☒ ☐ ☐ ☐ ☐
For initial PCI DSS compliance, it is not required that four quarters of passing scans be
completed if the assessor verifies 1) the most recent scan result was a passing scan, 2) the
entity has documented policies and procedures requiring quarterly scanning, and 3)
vulnerabilities noted in the scan results have been corrected as shown in a re-scan(s). For
subsequent years after the initial PCI DSS review, four quarters of passing scans must have
occurred.
(check one)
11.2 Examine scan reports and supporting documentation to verify that internal and external vulnerability scans are performed as
follows:
11.2.1 Perform quarterly internal vulnerability scans, and rescans as needed, until all “high-risk”
vulnerabilities (as identified in Requirement 6.1) are resolved. Scans must be performed by ☐ ☒ ☐ ☐ ☐
qualified personnel.
11.2.1.a Review the scan Identify the internal vulnerability scan
reports and verify that four reports and supporting
quarterly internal scans documentation reviewed.
occurred in the most recent Provide the name of the assessor who
12-month period. attests that four quarterly internal scans
were verified to have occurred in the
most recent 12-month period.
11.2.1.b Review the scan Identify the documented process for
reports and verify that the quarterly internal scanning to verify
scan process includes rescans the process defines performing rescans
until all “high-risk” as part of the quarterly internal scan
vulnerabilities as defined in process.
PCI DSS Requirement 6.1 are For each of the four internal quarterly No
resolved. scans indicated at 11.2.1.a, indicate
whether a rescan was required.
(yes/no)
If “yes,” describe how rescans were verified to be performed until either:
 Passing results are obtained, or Not Applicable
 All “High” vulnerabilities as defined in Not Applicable

PCI DSS Requirement 6.1 are
resolved.
(check one)
11.2.1.c Interview personnel to Identify the responsible personnel

verify that the scan was interviewed who confirm that the scan
performed by a qualified was performed by a qualified internal
internal resource(s) or resource(s) or qualified external third
qualified external third party, party.
and if applicable, Indicate whether a qualified internal No
organizational independence resource performs the scan. (yes/no)
of the tester exists (not
If “no,” mark the remainder of 11.2.1.c as “Not
required to be a QSA or ASV). Applicable.”
Describe how the personnel who Not Applicable

perform the scans demonstrated they
are qualified to perform the scans.
Describe how organizational Not Applicable
independence of the tester was
observed to exist.
11.2.2 Perform quarterly external vulnerability scans, via an Approved Scanning Vendor (ASV)
approved by the Payment Card Industry Security Standards Council (PCI SSC). Perform
rescans as needed, until passing scans are achieved.
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).
Refer to the ASV Program Guide published on the PCI SSC website for scan customer
responsibilities, scan preparation, etc.
11.2.2.a Review output from Identify the external network
the four most recent quarters vulnerability scan reports and
of external vulnerability scans supporting documentation reviewed.
(check one)
and verify that four quarterly Provide the name of the assessor who
external vulnerability scans attests that four quarterly external
occurred in the most recent vulnerability scans were verified to have
12-month period. occurred in the most recent 12-month
period.
11.2.2.b Review the results of Describe how the results of each
each quarterly scan and quarterly scan were reviewed to verify
rescan to verify that the ASV that the ASV Program Guide
Program Guide requirements requirements for a passing scan have
for a passing scan have been been met.
met (for example, no For each of the four external quarterly No
vulnerabilities rated 4.0 or scans indicated at 11.2.2.a, indicate
higher by the CVSS, no whether a rescan was necessary.
automatic failures). (yes/no)
If “yes,” describe how the results of the Not Applicable
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 Provide the name of the assessor who
reports to verify that the scans attests that the external scan reports
were completed by a PCI SSC were reviewed and verified to have been
Approved Scanning Vendor completed by a PCI SSC-Approved
(ASV). Scanning Vendor (ASV).
11.2.3 Perform internal and external scans, and rescans as needed, after any significant
☐ ☒ ☐ ☐ ☐
change. Scans must be performed by qualified personnel.
(check one)
11.2.3.a Inspect and correlate Identify the document reviewed to

change control documentation verify processes are defined for
and scan reports to verify that performing internal and external scans
system components subject to after any significant change.
any significant change were Identify the change control
scanned. documentation and scan reports
reviewed for this testing procedure.
Describe how the change control
documentation and scan reports were
inspected and correlated to verify that all
system components subject to significant
change were scanned after the change.
11.2.3.b Review scan reports For all scans reviewed in 11.2.3.a, No
and verify that the scan indicate whether a rescan was
process includes rescans until: required. (yes/no)
 For external scans, no If “yes” – for external scans, describe Not Applicable
vulnerabilities exist that are how rescans were performed until no
scored 4.0 or higher by the vulnerabilities with a CVSS score greater
CVSS. than 4.0 exist.
 For internal scans, all “high- If “yes” – for internal scans, describe Not Applicable
risk” vulnerabilities as how rescans were performed until either
defined in PCI DSS passing results were obtained or all
Requirement 6.1 are “high-risk” vulnerabilities as defined in
resolved. PCI DSS Requirement 6.1 were
resolved.
(check one)
11.2.3.c Validate that the scan Describe how it was validated that the
was performed by a qualified scan was performed by a qualified
internal resource(s) or internal resource(s) or qualified external
qualified external third party, third party.
and if applicable, Indicate whether an internal resource No
organizational independence performed the scans. (yes/no)
of the tester exists (not
If “no,” mark the remainder of 11.2.3.c as “Not
required to be a QSA or ASV). Applicable.”

perform the scans demonstrated they
are qualified to perform the scans.
observed to exist.
11.3 Penetration Testing
Note: The update to Requirement 11.3 is a best practice until June 30, 2015, after which it
☐ ☒ ☐ ☐ ☐
becomes a requirement. PCI DSS v2.0 requirements for penetration testing must be followed
until v3.1 is in place. Do not answer both v2.0 and 3.1 reporting instructions.
Indicate whether 11.3 for this ROC is being assessed against PCI DSS v2.0 or v3.1 (either is PCI DSS v3.1
acceptable until June 30, 2015.) (2.0/3.1)
If assessing against PCI DSS v2.0 for 11.3, please complete the following section in purple:
11.3 Perform external and internal penetration testing at least once a year and after any
significant infrastructure or application upgrade or modification (such as an operating system
☐ ☐ ☒ ☐ ☐
upgrade, a sub-network added to the environment, or a web server added to the environment).
These penetration tests must include the following:
(check one)
11.3.a Obtain and examine the  Identify the documented Not Applicable
results from the most recent penetration test results which
penetration test to verify that confirm:
penetration testing is i. Internal penetration tests are
performed at least annually performed annually.
and after any significant ii. External penetration tests are
changes to the environment. performed annually.
 Identify whether any significant
infrastructure or application upgrade
or modification occurred during the
past 12 months.
 Identify the documented
penetration test results confirming
that penetration tests are performed
after:
i. Significant internal infrastructure
or application upgrade.
ii. Significant external infrastructure
or application upgrade.
(check one)
11.3.b Verify that noted  Identify whether any exploitable Not Applicable
exploitable vulnerabilities were vulnerabilities were noted in the most
corrected and testing recent:
repeated. i. Internal penetration test results.
ii. External penetration test results.
 Identify the interviewed personnel
who confirm that all noted exploitable
vulnerabilities were corrected.
 Identify the documented
penetration test results confirming
that:
i. Testing was repeated.
ii. All noted exploitable
vulnerabilities were corrected.
11.3.c Verify that the test was  Identify whether internal and/or Not Applicable
performed by a qualified external resources perform the
internal resource or qualified penetration tests.
external third party, and if  Identify the interviewed personnel
applicable, organizational who perform the tests, and describe
independence of the tester how the personnel demonstrated they
exists (not required to be a are qualified to perform the tests.
QSA or ASV).  Describe how organizational
observed to exist.
(check one)
11.3.1 Network-layer penetration tests. ☐ ☐ ☒ ☐ ☐
11.3.1 Verify that the  Identify the documented results Not Applicable
penetration test includes from the most recent penetration
network-layer penetration tests confirming that:
tests. These tests should i. Internal penetration testing
include components that includes network-layer
support network functions as penetration tests.
well as operating systems. ii. External penetration testing
includes network-layer
penetration tests.
iii. The network-layer penetration
tests include:
o Components that support
network functions
o Operating systems
 Identify the responsible personnel
interviewed who confirm that:
i. Internal penetration testing
penetration tests.
ii. External penetration testing
penetration tests.
iii. The network-layer penetration
tests include:
o Components that support
network functions
o Operating systems
(check one)
11.3.2 Application-layer penetration tests. ☐ ☐ ☒ ☐ ☐
11.3.2 Verify that the  Identify the documented results Not Applicable
penetration test includes from the most recent penetration
application-layer penetration tests confirming that:
tests. The tests should i. Internal penetration testing
include, at a minimum, the includes application-layer
vulnerabilities listed in penetration tests.
Requirement 6.5. ii. External penetration testing
includes application-layer
penetration tests.
iii. The application-layer tests
include, at a minimum, the
vulnerabilities listed in PCI DSS
Requirement 6.5.
 Identify the responsible personnel
interviewed who confirm that:
i. Internal penetration testing
penetration tests.
ii. External penetration testing
penetration tests.
iii. The application-layer tests
include, at a minimum, the
vulnerabilities listed in PCI DSS
Requirement 6.5.
END OF PCI DSS 2.0, 11.3.
If assessing against PCI DSS v3.1 for 11.3, please complete the following:
(check one)
11.3 Implement a methodology for penetration testing that includes at least the following:
 Is based on industry-accepted penetration testing approaches (for example, NIST SP800-
115).
 Includes coverage for the entire CDE perimeter and critical systems.
 Includes testing from both inside and outside of 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.
Note: This update to Requirement 11.3 is a best practice until June 30, 2015, after which it
becomes a requirement. Prior to this date, PCI DSS v2.0 requirements for penetration testing
must be followed until version 3 is in place.
(check one)
11.3 Examine penetration- Identify the documented penetration-

testing methodology and testing methodology examined to
interview responsible verify a methodology is implemented that
personnel to verify a includes at least the following:
methodology is implemented  Based on industry-accepted
and includes at least the penetration testing approaches.
following:  Coverage for the entire CDE
 Is based on industry- perimeter and critical systems.
accepted penetration  Testing from both inside and
testing approaches. outside the network.
 Includes coverage for the  Testing to validate any
entire CDE perimeter and segmentation and scope reduction
critical systems. controls.
 Includes testing from both  Defines application-layer
inside and outside the penetration tests to include, at a
network. minimum, the vulnerabilities listed
 Includes testing to validate in Requirement 6.5.
any segmentation and  Defines network-layer penetration
scope reduction controls. tests to include components that
 Defines application-layer support network functions as well
penetration tests to include, as operating systems.
at a minimum, the  Review and consideration of
vulnerabilities listed in threats and vulnerabilities
Requirement 6.5. experienced in the last 12 months.
 Defines network-layer  Retention of penetration testing
penetration tests to include results and remediation activities
components that support results.
network functions as well as
operating systems.
(check one)

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.
(check one)
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.
 Coverage for the entire CDE
perimeter and critical systems.
 Testing from both inside the network,
and from outside of the network
attempting to get in.
 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.
(check one)
11.3.1 Perform external 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.1.a Examine the scope of Identify the documented external
work and results from the most penetration test results reviewed to
recent external penetration verify that external penetration testing is
test to verify that penetration performed:
testing is performed as  Per the defined methodology
follows:  At least annually
 Per the defined methodology
Describe how the scope of work was
 At least annually
reviewed to verify that external
 After any significant changes
penetration testing is performed:
to the environment
 Per the defined methodology
Identify whether any significant external
infrastructure or application upgrade or
modification occurred during the past 12
months.
Identify the documented penetration
test results reviewed to verify that
external penetration tests are performed
after significant external infrastructure or
application upgrade.
11.3.1.b Verify that the test Describe how it was validated that the
was performed by a qualified test was performed by a qualified
internal resource or qualified internal resource(s) or qualified external
external third party, and if third party.
(check one)
applicable, organizational Indicate whether an internal resource No

independence of the tester performed the test. (yes/no)
exists (not required to be a If “no,” mark the remainder of 11.3.1.b as “Not
QSA or ASV). Applicable.”

perform the penetration tests
demonstrated they are qualified to
perform the tests.
observed to exist.
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.2.a Examine the scope of Identify the documented internal
work and results from the most penetration test results reviewed to
recent internal penetration test verify that internal penetration testing is
to verify that penetration performed:
testing is performed as  Per the defined methodology
follows:  At least annually
(check one)
 Per the defined methodology Describe how the scope of work was
 At least annually reviewed to verify that internal
 After any significant changes penetration testing is performed:
to the environment  Per the defined methodology
Indicate whether any significant internal No
infrastructure or application upgrade or
modification occurred during the past 12
months. (yes/no)
Identify the documented internal
penetration test results reviewed to
verify that internal penetration tests are
performed after significant internal
infrastructure or application upgrade.
11.3.2.b Verify that the test Describe how it was validated that the
was performed by a qualified test was performed by a qualified
internal resource or qualified internal resource(s) or qualified external
external third party, and if third party.
applicable, organizational Indicate whether an internal resource No
independence of the tester performed the test. (yes/no)
exists (not required to be a
If “no,” mark the remainder of 11.3.2.b as “Not
QSA or ASV). Applicable.”
(check one)

perform the penetration tests
demonstrated they are qualified to
perform the tests
observed to exist.
11.3.3 Exploitable vulnerabilities found during penetration testing are corrected and testing is
☐ ☒ ☐ ☐ ☐
repeated to verify the corrections.
11.3.3 Examine penetration Identify the documented penetration
testing results to verify that testing results examined to verify that
noted exploitable noted exploitable vulnerabilities were
vulnerabilities were corrected corrected and that repeated testing
and that repeated testing confirmed the vulnerability was
confirmed the vulnerability was corrected.
corrected.
11.3.4 If segmentation is used to isolate the CDE from other networks, perform penetration
tests at least annually and after any changes to segmentation controls/methods to verify that
☐ ☒ ☐ ☐ ☐
the segmentation methods are operational and effective, and isolate all out-of-scope systems
from systems in the CDE.
11.3.4.a Examine Indicate whether segmentation is used No
segmentation controls and to isolate the CDE from other networks.
review penetration-testing (yes/no)
methodology to verify that If “no,” mark the remainder of 11.3.4.a and 11.3.4.b as
penetration-testing procedures “Not Applicable.”
are defined to test all If “yes,” Describe segmentation controls Not Applicable
segmentation methods to examined for this testing procedure.
(check one)
confirm they are operational Describe how the segmentation controls and penetration-testing methodology were examined to verify that penetration testing
and effective, and isolate all procedures are defined to:
out-of-scope systems from  Test all segmentation methods to Not Applicable
systems in the CDE. confirm they are operational and
effective.
 Isolate all out-of-scope systems from Not Applicable
systems in the CDE.
11.3.4.b Examine the results Identify the documented results from Not Applicable
from the most recent the most recent penetration test
penetration test to verify that: examined to verify that:
 Penetration testing to verify  Penetration testing to verify
segmentation controls is segmentation controls is performed
performed at least annually at least annually and after any
and after any changes to changes to segmentation
segmentation controls/methods.
controls/methods.  The penetration testing covers all
 The penetration testing segmentation controls/methods in
covers all segmentation use.
controls/methods in use.  the penetration testing verifies that
 The penetration testing
segmentation controls/methods are
verifies that segmentation operational and effective, and
controls/methods are isolate all out-of-scope systems
operational and effective, from systems in the CDE.
and isolate all out-of-scope
systems from systems in the
CDE.
(check one)
11.4 Use intrusion-detection systems and/or intrusion-prevention techniques to detect and/or

prevent intrusions into the network. Monitor all traffic at the perimeter of the cardholder data
environment as well as at critical points in the cardholder data environment, and alert personnel ☐ ☒ ☐ ☐ ☐
to suspected compromises.
Keep all intrusion-detection and prevention engines, baselines, and signatures up-to-date.
11.4.a Examine system Identify the network diagrams
configurations and network examined to verify that techniques are in
diagrams to verify that place to monitor all traffic:
techniques (such as intrusion-  At the perimeter of the cardholder
detection systems and/or data environment.
intrusion-prevention systems)  At critical points in the cardholder
are in place to monitor all data environment.
traffic:
Identify the techniques observed to be
 At the perimeter of the in place to monitor all traffic:
cardholder data
 At the perimeter of the cardholder
environment.
data environment.
 At critical points in the
 At critical points in the cardholder
cardholder data
data environment.
environment.
Describe how system configurations were examined to verify that techniques are in place to monitor all traffic:
 At the perimeter of the cardholder

data environment.
 At critical points in the cardholder data
environment.
(check one)
11.4.b Examine system Describe how system configurations for

configurations and interview intrusion-detection, and/or intrusion-
responsible personnel to prevention techniques were examined to
confirm intrusion-detection verify they are configured to alert
and/or intrusion-prevention personnel of suspected compromises.
techniques alert personnel of Describe how alerts to personnel are
suspected compromises. generated.
interviewed who confirm that the
generated alerts are received as
intended.
11.4.c Examine IDS/IPS Identify the vendor document(s)
configurations and vendor examined to verify defined vendor
documentation to verify instructions for intrusion-detection and/or
intrusion-detection, and/or intrusion-prevention techniques
intrusion-prevention Describe how IDS/IPS configurations were examined and compared to vendor documentation to verify intrusion-detection, and/or
techniques are configured, intrusion-prevention techniques are:
maintained, and updated per
 Configured per vendor instructions to
vendor instructions to ensure
ensure optimal protection.
optimal protection.
 Maintained per vendor instructions to
 Updated per vendor instructions to
(check one)
11.5 Deploy a change-detection mechanism (for example, file-integrity monitoring tools) to alert
personnel to unauthorized modification (including changes, additions and deletions) of critical
system files, configuration files, or content files; and configure the software to perform critical
file comparisons at least weekly.
Note: For change-detection purposes, critical files are usually those that do not regularly
☐ ☒ ☐ ☐ ☐
change, but the modification of which could indicate a system compromise or risk of
compromise. Change-detection mechanisms such as file-integrity monitoring products usually
come pre-configured with critical files for the related operating system. Other critical files, such
as those for custom applications, must be evaluated and defined by the entity (that is, the
merchant or service provider).
11.5.a Verify the use of a Describe the change-detection
change-detection mechanism mechanism deployed.
within the cardholder data Identify the results from monitored files
environment by observing reviewed.
system settings and monitored
Describe how change-detection mechanism settings and results from monitored files were observed to monitor changes to:
files, as well as reviewing
results from monitoring  Critical system files
activities.
Examples of files that should be
monitored:
 Critical configuration files
(check one)
 System executables  Critical content files
 Application executables
 Configuration and
parameter files
 Centrally stored, historical
or archived, log and audit
files
 Additional critical files
determined by entity (i.e.,
through risk assessment or
other means)
11.5.b Verify the mechanism Describe how it was verified that the change-detection mechanism is configured to:
is configured to alert personnel  Alert personnel to unauthorized
to unauthorized modification modification (including changes,
(including changes, additions additions and deletions) of critical
and deletions) of critical files, files.
and to perform critical file
 Perform critical file comparisons at
comparisons at least weekly.
least weekly.
11.5.1 Implement a process to respond to any alerts generated by the change-detection
☐ ☒ ☐ ☐ ☐
solution.
11.5.1 Interview personnel to Identify the personnel interviewed for
verify that all alerts are this testing procedure.
investigated and resolved. For the interview, summarize details of
the interview that verify that all alerts
are investigated and resolved.
(check one)
11.6 Ensure that security policies and operational procedures for security monitoring and
☐ ☒ ☐ ☐ ☐
testing are documented, in use, and known to all affected parties.
verify that security policies and operational procedures for security
operational procedures for monitoring and testing are documented.
security monitoring and testing Identify responsible personnel
are: interviewed who confirm that the above
 Documented, documented security policies and
 In use, and operational procedures for security
 Known to all affected monitoring and testing are:
parties.  In use
Maintain an Information Security Policy
Requirement 12: Maintain a policy that addresses information security for all personnel
(check one)
12.1 Establish, publish, maintain, and disseminate a security policy. ☐ ☐ ☐ ☒ ☐
12.1 Examine the information Identify the documented information nt resp for req 12
security policy and verify that security policy examined.
the policy is published and Describe how the information security policy was examined to verify that it is published and disseminated to:
disseminated to all relevant
 All relevant personnel. Not Tested
personnel (including vendors
and business partners).  All relevant vendors and business Not Tested
partners.
12.1.1 Review the security policy at least annually and update the policy when business
☐ ☐ ☐ ☒ ☐
objectives or the risk environment change.
12.1.1 Verify that the Identify the document reviewed to nt resp for req 12
information security policy is verify that the information security policy
reviewed at least annually and is reviewed at least annually and
updated as needed to reflect updated as needed to reflect changes to
changes to business business objectives or the risk
objectives or the risk environment.
environment. Describe how the information security policy was verified to be:
 Reviewed at least annually. Not Tested
 Updated as needed to reflect changes Not Tested

to business objectives or the risk
environment.
(check one)
12.2 Implement a risk assessment process, that:

 Is performed at least annually and upon significant changes to the environment (for
example, acquisition, merger, relocation, etc.),
 Identifies critical assets, threats, and vulnerabilities, and ☐ ☐ ☐ ☒ ☐
 Results in a formal, documented analysis of risk.
Examples of risk assessment methodologies include but are not limited to OCTAVE, ISO
27005 and NIST SP 800-30.
12.2.a Verify that an annual Describe how it was verified that an annual risk-assessment process is documented that:
risk-assessment process is  Identifies critical assets, threats and nt resp for req 12
documented that: vulnerabilities.
 Identifies critical assets,  Results in formal, documented Not Tested
threats, and vulnerabilities analysis of risk.
 Results in a formal,
documented analysis of
risk.
12.2.b Review risk- Identify the risk assessment result Not Tested
assessment documentation to documentation reviewed to verify that:
verify that the risk-assessment  The risk assessment process is
process is performed at least performed at least annually.
annually and upon significant  The risk assessment is performed
changes to the environment. upon significant changes to the
environment.
 The documented risk assessment
process was followed.
(check one)
12.3 Develop usage policies for critical technologies and define proper use of these
technologies.
Note: Examples of critical technologies include, but are not limited to, remote access and
☐ ☐ ☐ ☒ ☐
wireless technologies, laptops, tablets, removable electronic media, e-mail usage and Internet
usage.
Ensure these usage policies require the following:
12.3 Examine the usage Identify critical technologies in use. nt resp for req 12
policies for critical
technologies and interview
the following policies are
implemented and followed:
(check one)
Identify the usage policies for all Not Tested

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
(check one)
Identify the responsible personnel Not Tested

interviewed who confirm usage policies
for all identified critical technologies are
implemented and followed (for 12.3.1–
12.3.10):
 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
(check one)
12.3.1 Explicit approval by authorized parties. ☐ ☐ ☐ ☒ ☐
12.3.1 Verify that the usage Provide the name of the assessor who nt resp for req 12
policies include processes for attests that the usage policies were
explicit approval from verified to include processes for explicit
authorized parties to use the approval from authorized parties to use
technologies. the technologies.
12.3.2 Authentication for use of the technology. ☐ ☐ ☐ ☒ ☐
policies include processes for attests that the usage policies were
all technology use to be verified to include processes s for all
authenticated with user ID and technology used to be authenticated with
password or other user ID and password or other
authentication item (for authentication item.
example, token).
12.3.3 A list of all such devices and personnel with access. ☐ ☐ ☐ ☒ ☐
policies define a list of all attests that the usage policies were
devices and personnel verified to include processes define a list
authorized to use the devices. of all devices and personnel authorized
to use the devices.
12.3.4 A method to accurately and readily determine owner, contact information, and purpose
☐ ☐ ☐ ☒ ☐
(for example, labeling, coding, and/or inventorying of devices).
(check one)
policies define a method to attests that the usage policies were
accurately and readily verified to define a method to accurately
determine owner, contact and readily determine:
information, and purpose (for  Owner
example, labeling, coding,  Contact Information
and/or inventorying of
 Purpose
devices).
12.3.5 Acceptable uses of the technology. ☐ ☐ ☐ ☒ ☐
policies define acceptable attests that the usage policies were
uses for the technology. verified to define acceptable uses for the
technology.
12.3.6 Acceptable network locations for the technologies. ☐ ☐ ☐ ☒ ☐
policies define acceptable attests that the usage policies were
network locations for the verified to define acceptable network
technology. locations for the technology.
12.3.7 List of company-approved products. ☐ ☐ ☐ ☒ ☐
policies include a list of attests that the usage policies were
company-approved products. verified to include a list of company-
approved products.
12.3.8 Automatic disconnect of sessions for remote-access technologies after a specific period
☐ ☐ ☐ ☒ ☐
of inactivity.
(check one)
12.3.8.a Verify that the usage Provide the name of the assessor who nt resp for req 12
policies require automatic attests that the usage policies were
disconnect of sessions for verified to require automatic disconnect
remote-access technologies of sessions for remote-access
after a specific period of technologies after a specific period of
inactivity. inactivity.
12.3.8.b Examine Describe how configurations for remote Not Tested
configurations for remote access technologies were examined to
access technologies to verify verify that remote access sessions will
that remote access sessions be automatically disconnected after a
will be automatically specific period of inactivity.
disconnected after a specific Identify any remote access technologies Not Tested
period of inactivity. in use.
Identify the period of inactivity specified. Not Tested
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.
policies require activation of attests that the usage policies were
remote-access technologies verified to require activation of remote-
used by vendors and business access technologies used by vendors
partners only when needed by and business partners only when
vendors and business needed by vendors and business
partners, with immediate partners, with immediate deactivation
deactivation after use. after use.
(check one)
12.3.10 For personnel accessing cardholder data via remote-access technologies, prohibit the
copying, moving, and storage of cardholder data onto local hard drives and removable
electronic media, unless explicitly authorized for a defined business need. Where there is an ☐ ☐ ☐ ☒ ☐
authorized business need, the usage policies must require the data be protected in accordance
with all applicable PCI DSS Requirements.
12.3.10.a Verify that the usage Provide the name of the assessor who nt resp for req 12
policies prohibit copying, attests that the usage policies were
moving, or storing of verified to prohibit copying, moving or
cardholder data onto local storing of cardholder data onto local hard
hard drives and removable drives and removable electronic media
electronic media when when accessing such data via remote-
accessing such data via access technologies.
remote-access technologies.
12.3.10.b For personnel with Provide the name of the assessor who Not Tested
proper authorization, verify attests that the usage policies were
that usage policies require the verified to require, for personnel with
protection of cardholder data proper authorization, the protection of
in accordance with PCI DSS cardholder data in accordance with PCI
Requirements. DSS Requirements.
12.4 Ensure that the security policy and procedures clearly define information security
☐ ☐ ☐ ☒ ☐
responsibilities for all personnel.
12.4.a Verify that information Identify the information security nt resp for req 12
security policy and procedures policy and procedures reviewed to
clearly define information verify that they clearly define information
security responsibilities for all security responsibilities for all personnel.
personnel.
(check one)
12.4.b Interview a sample of Identify the responsible personnel Not Tested

responsible personnel to verify interviewed for this testing procedure
they understand the security who confirm they understand the
policies. security policy.
Provide the name of the assessor who Not Tested
attests that the interviews of responsible
personnel conducted verified that they
understand the security policies.
12.5 Assign to an individual or team the following information security management
☐ ☐ ☐ ☒ ☐
responsibilities:
(check one)
12.5 Examine information Identify the information security nt resp for req 12
security policies and policies reviewed to verify the specific
procedures to verify: and formal assignment of the following
 The formal assignment of (including 12.5.1-12.5.5):
information security to a Chief
 Information security to a Chief
Security Officer or other security-
knowledgeable member of Security Officer or other security-
management. knowledgeable member of
 The following information security management.
responsibilities are specifically and
formally assigned:  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.
12.5.1 Establish, document, and distribute security policies and procedures. ☐ ☐ ☐ ☒ ☐
(check one)
12.5.1 Verify that responsibility Provide the name of the assessor who nt resp for req 12
for establishing, documenting attests that responsibilities were verified
and distributing security to be formally assigned for:
policies and procedures is  Establishing security policies and
formally assigned. procedures.
 Documenting security policies and
procedures.
 Distributing security policies and
procedures.
12.5.2 Monitor and analyze security alerts and information, and distribute to appropriate
☐ ☐ ☐ ☒ ☐
personnel.
for monitoring and analyzing attests that responsibilities were verified
security alerts and distributing to be formally assigned for:
information to appropriate  Monitoring and analyzing security
information security and alerts.
business unit management  Distributing information to
personnel is formally appropriate information security
assigned. and business unit management
personnel.
12.5.3 Establish, document, and distribute security incident response and escalation
☐ ☐ ☐ ☒ ☐
procedures to ensure timely and effective handling of all situations.
(check one)
for establishing, documenting, attests that responsibilities were verified
and distributing security to be formally assigned for:
incident response and  Establishing security incident
escalation procedures is response and escalation
formally assigned. procedures.
 Documenting security incident
procedures.
 Distributing security incident
procedures.
12.5.4 Administer user accounts, including additions, deletions, and modifications. ☐ ☐ ☐ ☒ ☐
for administering (adding, attests that responsibilities were verified
deleting, and modifying) user to be formally assigned for administering
account and authentication user account and authentication
management is formally management.
assigned.
12.5.5 Monitor and control all access to data. ☐ ☐ ☐ ☒ ☐
for monitoring and controlling attests that responsibilities were verified
all access to data is formally to be formally assigned for:
assigned.  Monitoring all access to data
 Controlling all access to data
(check one)
12.6 Implement a formal security awareness program to make all personnel aware of the
☐ ☐ ☐ ☒ ☐
importance of cardholder data security.
12.6.a Review the security Identify the documented security nt resp for req 12
awareness program to verify it awareness program reviewed to verify
provides awareness to all it provides awareness to all personnel
personnel about the about the importance of cardholder data
importance of cardholder data security.
security.
12.6.b Examine security Identify the documented security Not Tested
awareness program awareness program procedures and
procedures and additional documentation examined to
documentation and perform verify that:
the following:  The security awareness program
provides multiple methods of
communicating awareness and
educating personnel.
 Personnel attend security
awareness training:
- Upon hire, and
- At least annually
 Personnel acknowledge, in writing

or electronically and at least
annually, that they have read and
understand the information security
policy.
(check one)
12.6.1 Educate personnel upon hire and at least annually.

Note: Methods can vary depending on the role of the personnel and their level of access to ☐ ☐ ☐ ☒ ☐
the cardholder data.
12.6.1.a Verify that the Describe how the security awareness nt resp for req 12
security awareness program program provides multiple methods of
provides multiple methods of communicating awareness and
communicating awareness educating personnel.
and educating personnel (for
example, posters, letters,
memos, web-based training,
meetings, and promotions).
12.6.1.b Verify that personnel Describe how it was observed that all personnel attend security awareness training:
attend security awareness  Upon hire Not Tested
training upon hire and at least
 At least annually Not Tested
annually.
12.6.1.c Interview a sample of Identify the sample of personnel Not Tested
personnel to verify they have interviewed who confirm they have
completed awareness training completed security awareness training.
and are aware of the For the interview, summarize details of Not Tested
importance of cardholder data the interview that verify their awareness
security. of the importance of cardholder data
security.
12.6.2 Require personnel to acknowledge at least annually that they have read and understood
☐ ☐ ☐ ☒ ☐
the security policy and procedures.
Describe how it was verified that, per the security awareness program, all personnel:
(check one)
12.6.2 Verify that the security  Acknowledge that they have read and nt resp for req 12
awareness program requires understand the information security
personnel to acknowledge, in policy (including whether this is in
writing or electronically, at writing or electronic).
least annually that they have  Provide an acknowledgement at least Not Tested
read and understand the annually.
information security policy.
12.7 Screen potential personnel prior to hire to minimize the risk of attacks from internal
sources. (Examples of background checks include previous employment history, criminal
record, credit history, and reference checks.)
☐ ☐ ☐ ☒ ☐
Note: For those potential personnel to be hired for certain positions such as store cashiers who
only have access to one card number at a time when facilitating a transaction, this requirement
is a recommendation only.
12.7 Inquire with Human Identify the documented policy nt resp for req 12
Resource department reviewed to verify requirement for
management and verify that background checks to be conducted:
background checks are  On potential personnel who will
conducted (within the have access to cardholder data or
constraints of local laws) prior the cardholder data environment.
to hire on potential personnel
 Prior to hiring the personnel.
who will have access to
cardholder data or the Identify the Human Resources Not Tested
cardholder data environment. 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.
(check one)
Describe how it was verified that background checks are conducted (within the constraints of local laws):
 On potential personnel who will have Not Tested

access to cardholder data or the
 Prior to hiring the personnel. Not Tested
12.8 Maintain and implement policies and procedures to manage service providers with whom
☐ ☐ ☐ ☒ ☐
cardholder data is shared, or that could affect the security of cardholder data, as follows:
(check one)
12.8 Through observation, Identify the documented policies and nt resp for req 12
review of policies and procedures to manage service
procedures, and review of providers with whom cardholder data
supporting documentation, is shared, or that could affect the
verify that processes are security of cardholder data, reviewed
implemented to manage to verify policy defines the following from
service providers with whom 12.8.1–12.8.5:
cardholder data is shared, or  Maintain a list of service providers.
that could affect the security of  Maintain a written agreement that
cardholder data (for example, includes an acknowledgement that
backup tape storage facilities, the service providers will maintain
managed service providers all applicable PCI DSS
such as web-hosting requirements to the extent the
companies or security service service provider handles, has
providers, those that receive access to, or otherwise stores,
data for fraud modeling processes, or transmits the
purposes, etc.), as follows: 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 annually.
 Maintain information about which
(check one)
12.8.1 Maintain a list of service providers. ☐ ☐ ☐ ☒ ☐
12.8.1 Verify that a list of Describe how the documented list of nt resp for req 12
service providers is service providers was observed to be
maintained. maintained (kept up-to-date).
12.8.2 Maintain a written agreement that includes an acknowledgement that the service
providers are responsible for the security of cardholder data the service providers possess 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 CDE.
☐ ☐ ☐ ☒ ☐
Note: The exact wording of an acknowledgement will depend on the agreement between the
two parties, the details of the service being provided, and the responsibilities assigned to each
party. The acknowledgement does not have to include the exact wording provided in this
requirement.
12.8.2 Observe written Describe how written agreements for nt resp for req 12
agreements and confirm they each service provider were observed to
include an acknowledgement confirm they include an
by service providers that they acknowledgement by service providers
are responsible for the security that they will maintain all applicable PCI
of cardholder data the service DSS requirements to the extent the
providers possess or service provider handles, has access to,
otherwise store, process or or otherwise stores, processes, or
transmit on behalf of the transmits the customer’s cardholder data
customer, or to the extent that or sensitive authentication data, or
they could impact the security manages the customer's cardholder data
of the customer’s cardholder environment on behalf of a customer.
data environment.
12.8.3 Ensure there is an established process for engaging service providers including proper
☐ ☐ ☐ ☒ ☐
due diligence prior to engagement.
(check one)
12.8.3 Verify that policies and Describe how it was verified that the nt resp for req 12
procedures are documented procedures for proper due diligence prior
and implemented including to engaging a service provider are
proper due diligence prior to implemented, as documented in the
engaging any service provider. policies and procedures at 12.8.
12.8.4 Maintain a program to monitor service providers’ PCI DSS compliance status at least
☐ ☐ ☐ ☒ ☐
annually.
12.8.4 Verify that the entity Describe how it was verified that the nt resp for req 12
maintains a program to entity maintains a program to monitor its
monitor its service providers’ service providers’ PCI DSS compliance
PCI DSS compliance status at status at least annually.
least annually.
12.8.5 Maintain information about which PCI DSS requirements are managed by each service
☐ ☐ ☐ ☒ ☐
provider, and which are managed by the entity.
12.8.5 Verify the entity Describe how it was observed that the nt resp for req 12
maintains information about entity maintains information about which
which PCI DSS requirements PCI DSS requirements are managed by
are managed by each service each service provider, and which are
provider, and which are managed by the entity.
managed by the entity.
(check one)
12.9 Additional requirement for service providers only: Service providers acknowledge in
writing to customers that they are responsible for the security of cardholder data the service
provider possesses or otherwise stores, processes, or transmits on behalf of the customer, or
to the extent that they could impact the security of the customer’s cardholder data environment.
Note: This requirement is a best practice until June 30, 2015, after which it becomes a
☐ ☐ ☐ ☒ ☐
requirement.
Note: The exact wording of an acknowledgement will depend on the agreement between the
two parties, the details of the service being provided, and the responsibilities assigned to each
party. The acknowledgement does not have to include the exact wording provided in this
requirement.
(check one)
12.9 Additional testing Indicate whether the assessed entity is Yes

procedure for service a service provider. (yes/no)
provider assessments only: If “no,” mark the remainder of 12.9 as “Not Applicable.”
Review service provider’s
If “yes”:
policies and procedures and
observe templates used for Indicate whether this ROC is being No
written agreement to confirm completed prior to June 30, 2015.
the service provider (yes/no)
acknowledges in writing to 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
customers that the service “Not Applicable.”
provider will maintain all If “no” OR if the assessed entity has this in place ahead of the requirement’s effective date:
applicable PCI DSS
requirements to the extent the Identify the service provider’s policies nt resp for req 12
service provider possesses or and procedures reviewed to verify that

otherwise stores, processes, the service provider acknowledges in
or transmits cardholder data writing to customers that the service
on behalf of the customer, or provider will maintain all applicable PCI
to the extent that they could DSS requirements to the extent the
impact the security of the service provider possesses or otherwise
customer’s cardholder data stores, processes, or transmits
environment. cardholder data on behalf of the
customer, or to the extent that they could
impact the security of the customer’s
(check one)
Describe how templates used for Not Tested

written agreement 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 possesses or
otherwise stores, processes, or transmits
cardholder data on behalf of the
customer, or to the extent that they could
impact the security of the customer’s
12.10 Implement an incident response plan. Be prepared to respond immediately to a system
☐ ☐ ☐ ☒ ☐
breach.
(check one)
12.10 Examine the incident Identify the documented incident nt resp for req 12
response plan and related response plan and related procedures
procedures to verify entity is examined to verify the entity is prepared
prepared to respond to respond immediately to a system
immediately to a system breach, with defined processes as
breach by performing the follows from 12.10.1–12.10.6:
following:  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/7 incident monitoring
- 24/7 incident response
 Provide appropriate training to staff

with security breach response
responsibilities.
 Include alerts from security
monitoring systems, including but
not limited to intrusion-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.
(check one)
12.10.1 Create the incident response plan to be implemented in the event of system breach.
Ensure the plan addresses the following, at a minimum:
 Roles, responsibilities, and communication and contact strategies in the event of a
compromise including notification of the payment brands, at a minimum.
 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.
(check one)
12.10.1.a Verify that the Provide the name of the assessor who nt resp for req 12
incident response plan attests that the incident response plan
includes: was verified to include:
 Roles, responsibilities, and  Roles and responsibilities.
communication strategies in  Communication strategies.
the event of a compromise
 Requirement for notification of the
including notification of the
payment brands.
payment brands, at a
minimum.  Specific incident response
procedures.
 Specific incident response
procedures.  Business recovery and continuity
 Business recovery and procedures.
continuity procedures  Data back-up processes.
 Data back-up processes  Analysis of legal requirements for
 Analysis of legal reporting compromises.
requirements for reporting  Coverage for all critical system
compromises (for example, components.
California Bill 1386, which  Responses for all critical system
requires notification of components.
affected consumers in the
 Reference or inclusion of incident
event of an actual or
response procedures from the
suspected compromise for
payment brands.
any business with California
residents in their database).
 Coverage and responses for
all critical system
components.
 Reference or inclusion of
incident response
(check one)
12.10.1.b Interview personnel Identify the sample of personnel Not Tested

and review documentation interviewed who confirm that the
from a sample of previously documented incident response plan and
reported incidents or alerts to procedures are followed.
verify that the documented Identify the sample of previously Not Tested
incident response plan and reported incidents or alerts reviewed for
procedures were followed. this testing procedure.
For each item in the sample, describe Not Tested
how documentation was reviewed to
confirm that the documented incident
response plan and procedures are
followed.
12.10.2 Test the plan at least annually. ☐ ☐ ☐ ☒ ☐
12.10.2 Verify that the plan is Describe how it was observed that the nt resp for req 12
tested at least annually. incident response plan is tested at least
annually.
12.10.3 Designate specific personnel to be available on a 24/7 basis to respond to alerts. ☐ ☐ ☐ ☒ ☐
(check one)
12.10.3 Verify through Identify the document requiring 24/7 nt resp for req 12
observation, review of policies, incident response and monitoring
and interviews of responsible coverage for:
personnel that designated  Any evidence of unauthorized
personnel are available for activity.
24/7 incident response and  Detection of unauthorized wireless
monitoring coverage for any access points.
evidence of unauthorized
 Critical IDS alerts.
activity, detection of
unauthorized wireless access  Reports of unauthorized critical
points, critical IDS alerts, system or content file changes.
and/or reports of unauthorized Identify the sample of responsible Not Tested
critical system or content file personnel interviewed who confirm 24/7
changes. 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.
Describe how it was observed that designated personnel are available for 24/7 incident response and monitoring coverage for:
 Any evidence of unauthorized activity. Not Tested
 Detection of unauthorized wireless Not Tested

access points.
 Critical IDS alerts. Not Tested
(check one)
 Reports of unauthorized critical Not Tested

system or content file changes.
12.10.4 Provide appropriate training to staff with security breach response responsibilities. ☐ ☐ ☐ ☒ ☐
12.10.4 Verify through Identify the sample of responsible nt resp for req 12
observation, review of policies, personnel interviewed who confirm that
and interviews of responsible staff with responsibilities for security
personnel that staff with breach response are periodically trained.
responsibilities for security Identify the documented policy Not Tested
breach response are reviewed that defines that staff with
periodically trained. responsibilities for security breach
response are periodically trained.
Describe how it was observed that staff Not Tested
with responsibilities for security breach
response are periodically trained.
12.10.5 Include alerts from security monitoring systems, including but not limited to intrusion-
☐ ☐ ☐ ☒ ☐
detection, intrusion-prevention, firewalls, and file-integrity monitoring systems.
12.10.5 Verify through Describe how processes were reviewed nt resp for req 12
observation and review of to verify that monitoring alerts from
processes that monitoring and security monitoring systems are covered
responding to alerts from in the Incident Response Plan.
security monitoring systems Describe how processes were reviewed Not Tested
are covered in the Incident to verify that responding to alerts from
Response Plan. security monitoring systems are covered
in the Incident Response Plan.
12.10.6 Develop a process to modify and evolve the incident response plan according to
☐ ☐ ☐ ☒ ☐
lessons learned and to incorporate industry developments.
(check one)
12.10.6 Verify through Identify the documented policy nt resp for req 12
observation, review of policies, reviewed to verify that processes are
and interviews of responsible defined to modify and evolve the incident
personnel that there is a response plan:
process to modify and evolve  According to lessons learned.
the incident response plan  To incorporate industry
according to lessons learned developments.
and to incorporate industry
Identify the sample of responsible Not Tested
developments.
personnel interviewed who confirm that
processes are implemented to modify
and evolve the incident response plan:
 According to lessons learned.
 To incorporate industry
developments.
Describe how it was observed that processes are implemented to modify and evolve the incident response plan:
 According to lessons learned. Not Tested
 To incorporate industry developments. Not Tested
Appendix A: Additional PCI DSS Requirements for Shared Hosting Providers
Note: If the entity is not a shared hosting provider (and the answer at 2.6 was “no,” indicate the below as “Not Applicable.” Otherwise, complete the
below.
(check one)

Indicate whether the assessed entity is a shared hosting provider (indicated at Requirement 2.6). (yes/no) Yes
If “no,” mark the below as “Not Applicable” (no further explanation required)
A.1 Protect each entity’s (that is, merchant, service provider, or other entity) hosted environment and data, per A.1.1 through A.1.4:
A hosting provider must fulfill these requirements as well as all other relevant sections of the PCI DSS.
Note: Even though a hosting provider may meet these requirements, the compliance of the entity that uses the hosting provider is not guaranteed. Each entity must comply with
the PCI DSS and validate compliance as applicable.
A.1 Specifically for a PCI DSS

assessment of a shared
hosting provider, to verify that
shared hosting providers
protect entities’ (merchants
and service providers) hosted
environment and data, select a
sample of servers (Microsoft
Windows and Unix/Linux)
across a representative
sample of hosted merchants
and service providers, and
perform A.1.1 through A.1.4
below:
PCI DSS Template for Report on Compliance, Appendix A: Additional Requirements for Shared Hosting Providers April 2015
(check one)

A.1.1 Ensure that each entity only runs processes that have access to that entity’s cardholder
☒ ☐ ☐ ☐ ☐
data environment.
A.1.1 If a shared hosting Indicate whether the hosting provider Yes
provider allows entities (for allows hosted entities to run their own
example, merchants or service applications. (yes/no)
providers) to run their own If “no”:
applications, verify these Identify the document reviewed to Not Applicable
application processes run verify processes are defined to require
using the unique ID of the that entities must not run their own
entity. For example: applications.
 No entity on the system can
Describe how it was observed that Not Applicable
use a shared web server hosted entities are not able to run their
user ID. own applications.
 All CGI scripts used by an
If “yes”:
entity must be created and
run as the entity’s unique Identify the document requiring that
user ID. application processes use a unique ID
for each entity.
Identify the sample of servers
observed.
Identify the sample of hosted
merchants and service providers (hosted
entities) observed.
how the observed system configurations
require that all hosted entities’
application processes are run using the
unique ID of that entity.
(check one)

Describe how the hosted entities’ application processes were observed to be running using unique IDs for each entity, including:
 Entities on the system cannot use a

shared web server user ID.
 All CGI scripts used by an entity are
created and run as the entity’s unique
user ID.
A.1.2 Restrict each entity’s access and privileges to its own cardholder data environment only. ☒ ☐ ☐ ☐ ☐
A.1.2.a Verify the user ID of Identify the document examined to

any application process is not verify processes require that user IDs for
a privileged user (root/admin). hosted entities’ application processes
are not privileged users.
Using the sample of servers and hosted merchants and service providers from A.1.1, for each item perform the following:
Describe the observed system

configurations examined to verify that
user IDs for hosted entities’ application
processes are not privileged users.
Describe how running application
processes IDs were observed to verify
that the running application processes
IDs are not privileged users.
(check one)

A.1.2.b Verify each entity Identify the document examined to

(merchant, service provider) verify permissions for hosted entities are
has read, write, or execute defined as follows:
permissions only for files and  Read permissions are only
directories it owns or for assigned for the files and
necessary system files directories the hosted entity owns,
(restricted via file system or for necessary systems files.
permissions, access control  Write permissions are only
lists, chroot, jailshell, etc.) assigned for the files and
Important: An entity’s files directories the hosted entity owns,
may not be shared by group. or for necessary systems files.
 Access permissions are only
assigned for the files and
directories the hosted entity owns,
or for necessary systems files.
 Assigned permissions for hosted
entities must be restricted.
 An entity’s files must not be shared
by group.
(check one)

Using the sample of servers and hosted merchants and service providers from A.1.1, for each item
describe the system configuration setting observed to verify permissions are assigned as follows:
 Read permissions are only
 Write permissions are only
 Access permissions are only
 Assigned permissions for hosted
entities must be restricted.
 An entity’s files must not be shared
by group.
For each item in the sample, perform the following:
Describe permission observed to verify
permissions are restricted.
Describe how the entity’s files were
observed to verify they are not
shared by group.
(check one)

A.1.2.c Verify that an entity’s Identify the document examined to

users do not have write verify processes require a hosted entity’s
access to shared system users do not write access to shared
binaries. system binaries.
Using the sample of servers and hosted
merchants and service providers from
A.1.1, for each item in the summary
describe the observed system
configurations observed to verify that an
entity’s users do not have write access
to shared system binaries.
A.1.2.d Verify that viewing of Identify the document examined to
log entries is restricted to the verify processes require that viewing of
owning entity. log entries is restricted to the owning
entity.
(check one)

Using the sample of servers and hosted

merchants and service providers from
A.1.1, for each item in the summary
describe the observed system
configurations observed to verify that
viewing of log entries is restricted to the
owning entity.
A.1.2.e To ensure each entity Identify the document examined to
cannot monopolize server verify processes require restricts for the
resources to exploit use of the following to ensure each entity
vulnerabilities (for example, cannot monopolize server resources to
error, race, and restart exploit vulnerabilities:
conditions resulting in, for  Disk space
example, buffer overflows),  Bandwidth
verify restrictions are in place
 Memory
for the use of these system
resources:  CPU
 Disk space Using the sample of servers and hosted merchants and service providers from A.1.1, perform the following:
 Bandwidth Describe the system configuration setting observed to verify restriction are implemented for the use
 Memory of:
 CPU  Disk space
 Bandwidth
 Memory
 CPU
(check one)

A.1.3 Ensure logging and audit trails are enabled and unique to each entity’s cardholder data
☐ ☒ ☐ ☐ ☐
environment and consistent with PCI DSS Requirement 10.
A.1.3 Verify the shared Identify the document examined to
hosting provider has enabled verify processes require that logging is
logging as follows, for each enabled for each hosting environment,
merchant and service provider with the following required for each
environment: hosted entity environment:
 Logs are enabled for  Logs are enabled for common
common third-party third-party applications.
applications.  Logs are active by default.
 Logs are active by  Logs are available for review by the
default. owning entity.
 Logs are available for
 Log locations are clearly
review by the owning entity.
communicated to the owning entity.
(check one)

 Log locations are Using the sample of servers and hosted merchants and service providers from A.1.1, describe how processes were observed to verify
clearly communicated to the the following:
owning entity.  Logging is enabled for each hosted
entity.
 Logs are enabled for common third-
party applications.
 Logs are active by default.
 Logs are available for review by the
owning entity.
 Log locations are clearly
communicated to the owning entity.
 Logging and audit trails are consistent
with PCI DSS Requirement 10.
A.1.4 Enable processes to provide for timely forensic investigation in the event of a
☒ ☐ ☐ ☐ ☐
compromise to any hosted merchant or service provider.
A.1.4 Verify the shared Identify the document examined to
hosting provider has written verify processes define timely forensics
policies that provide for a investigation in the event of a
timely forensics investigation compromise to any hosted entity.
of related servers in the event Identify the responsible personnel
of a compromise. interviewed who confirm that processes
are implemented in accordance with the
documented policies.
(check one)

Describe how processes were observed

to verify that processes are implemented
to provide for timely forensics
investigation in the event of a
compromise to any hosted entity.
Appendix B: Compensating Controls
Compensating controls may be considered for most PCI DSS requirements 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, or compensating, controls.
Compensating controls must satisfy the following criteria:
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, such that the compensating control sufficiently offsets the risk that the
original PCI DSS requirement was designed to defend against. (See Navigating PCI DSS for the intent of each PCI DSS requirement.)
3. Be “above and beyond” other PCI DSS requirements. (Simply being in compliance with other PCI DSS requirements is not a compensating control.)
When evaluating “above and beyond” for compensating controls, consider the following:
Note: The items at a) through c) below are intended as examples only. All compensating controls must be reviewed and validated for sufficiency by
the assessor who conducts the PCI DSS review. The effectiveness of a compensating control is dependent on the specifics of the environment in
which the control is implemented, the surrounding security controls, and the configuration of the control. Companies should be aware that a
particular compensating control will not be effective in all environments.
a) Existing PCI DSS requirements CANNOT be considered as compensating controls if they are already required
for the item under review. For example, passwords for non-console administrative access must be sent encrypted to mitigate the risk of
intercepting clear-text administrative passwords. An entity cannot use other PCI DSS password requirements (intruder lockout, complex
passwords, etc.) to compensate for lack of encrypted passwords, since those other password requirements do not mitigate the risk of
interception of clear-text passwords. Also, the other password controls are already PCI DSS requirements for the item under review (passwords).
b) Existing PCI DSS requirements MAY be considered as compensating controls if they are required for another area, but are not required for the
item under review. For example, two-factor authentication is a PCI DSS requirement for remote access. Two-factor authentication from within the
internal network can also be considered as a compensating control for non-console administrative access when transmission of encrypted
passwords cannot be supported. Two-factor authentication may be an acceptable compensating control if: (1) it meets the intent of the original
requirement by addressing the risk of intercepting clear-text administrative passwords; and (2) it is set up properly and in a secure environment.
c) Existing PCI DSS requirements may be combined with new controls to become a compensating control. For example, if a company is unable to
render cardholder data unreadable per Requirement 3.4 (for example, by encryption), a compensating control could consist of a device or
combination of devices, applications, and controls that address all of the following: (1) internal network segmentation; (2) IP address or MAC
address filtering; and (3) two-factor authentication from within the internal network.
4. Be commensurate with the additional risk imposed by not adhering to the PCI DSS requirement.
The assessor is required to thoroughly evaluate compensating controls during each annual PCI DSS assessment to validate that each compensating
control adequately addresses the risk the original PCI DSS requirement was designed to address, per items 1-4 above. To maintain compliance,
processes and controls must be in place to ensure compensating controls remain effective after the assessment is complete.
PCI DSS Template for Report on Compliance, Appendix B: Compensating Controls April 2015
Appendix C: Compensating Controls Worksheet
Use this worksheet to define compensating controls for any requirement where compensating controls are used to meet a PCI DSS requirement. Note
that compensating controls should also be documented in the Report on Compliance in the corresponding PCI DSS requirement section.
Note: Only companies that have undertaken a risk analysis and have legitimate technological or documented business constraints can consider the use
of compensating controls to achieve compliance.
Requirement Number and Definition: 5.1 Deploy Anti-Virus Software
Information Required Explanation

1. Constraints List constraints precluding compliance with 5.1 ccw
the original requirement.
2. Objective Define the objective of the original control; 5.1 ccw
identify the objective met by the
compensating control.
3. Identified Risk Identify any additional risk posed by the lack 5.1 ccw
of the original control.
4. Definition of Define the compensating controls and 5.1 ccw
Compensating explain how they address the objectives of
Controls the original control and the increased risk, if
any.
5. Validation of Define how the compensating controls were 5.1 ccw
Compensating validated and tested.
Controls
6. Maintenance Define process and controls in place to 5.1 ccw
maintain compensating controls.
Requirement Number and Definition: 5.1.1 Deploy Anti-Virus Software

7. Constraints List constraints precluding compliance with 5.1.1 const
8. Objective Define the objective of the original control; 5.1.1 ccw
9. Identified Risk Identify any additional risk posed by the lack 5.1.1 ccw
10. Definition of Define the compensating controls and 5.1.1 ccw
PCI DSS Template for Report on Compliance, Appendix C: Compensating Controls Worksheet April 2015
Copyright 2015 PCI Security Standards Council LLC Page 294
any.
11. Validation of Define how the compensating controls were 5.1.1 ccw
Controls
12. Maintenance Define process and controls in place to 5.1.1 ccw
Requirement Number and Definition: 5.1.2 Perform Periodic Evaluations

13. Constraints List constraints precluding compliance with 5.1.2 ccw
any.
Controls
Requirement Number and Definition: 5.2 Ensure All Anti-Virus Mechanisms Maintained
Information Required
Explanation
19. Constraints
List constraints precluding compliance with the original requirement.
5.2 const
20. Objective
Define the objective of the original control; identify the objective met by the compensating control.
5.2
obj
21. Identified Risk
Identify any additional risk posed by the lack of the original control.
5.2
risk
22. Definition of Compensating Controls
Define the compensating controls and explain how they address the objectives of the original control and the increased risk, if any.
def
5.2
23. Validation of Compensating Controls
Define how the compensating controls were validated and tested.
5.2 valid
24. Maintenance
Define process and controls in place to maintain compensating controls.
5.2 maint
Requirement Number and Definition: 5.3 Ensure Anti-Vrius Mechanisms Actively Running and Cannot be Disabled

25. Constraints List constraints precluding compliance with 5.3 const
26. Objective Define the objective of the original control; 5.3 obj
27. Identified Risk Identify any additional risk posed by the lack 5.3 risk
28. Definition of Define the compensating controls and 5.3 def
any.
29. Validation of Define how the compensating controls were 5.3 valid
Controls
30. Maintenance Define process and controls in place to 5.3 maint
Requirement Number and Definition: 5.4 Ensure Security Policies Documented, In Use and Known

31. Constraints List constraints precluding compliance with 5.4 cons ccw
32. Objective Define the objective of the original control; 5.4 obj
33. Identified Risk Identify any additional risk posed by the lack 5.4 risk
34. Definition of Define the compensating controls and 5.4 def
any.
35. Validation of Define how the compensating controls were 5.4 valid
Controls
36. Maintenance Define process and controls in place to 5.4 maint
Requirement Number and Definition: 7.1.2 Restrict Acces to Least Privileges Necessary

any.
Controls
Requirement Number and Definition: 7.2.3 Default "Deny-All" Setting

any.
Controls
Requirement Number and Definition: 11.1 Implement Processes to Test for Presence of Wireless Access Points

any.
Controls
Requirement Number and Definition: 11.1.1 Maintain Inventory of Authorized Wireless Access Points

any.
Controls
Requirement Number and Definition: 11.1.2 Implement IR Procedures

any.
Controls
Requirement Number and Definition: 11.2.1 Perform Quarterly Internal Vulnerability Scans

any.
Controls
Requirement Number and Definition: 11.2.2 Perform Quarterly External Vulnerability Scans

any.
Controls
Requirement Number and Definition: 11.2.3 Perform Internal and External Scans After Significant Changes

any.
Controls
Requirement Number and Definition: 11.3 Penetration Testing - 3.1

any.
Controls
Requirement Number and Definition: 11.3.1 Annual External Pen Testing

any.
Controls
Requirement Number and Definition: 11.3.2 Annual Internal Pen Test

any.
Controls
Requirement Number and Definition: 11.3.3 Exploitable Vulnerabilities

any.
Controls
Requirement Number and Definition: 11.3.4 Operational and Effective Segmentation

any.
Controls
Requirement Number and Definition: 11.4 Detect/Prevent Intrusions

any.
Controls
Requirement Number and Definition: 11.5 Deploy a Change Detection Mechanism

122. Objective Define the objective of the original control; cv 11.5 ccw
any.
Controls
Requirement Number and Definition: 11.5.1 Implement a Process to Respond to Alerts

any.
Controls
Requirement Number and Definition: 11.6 Ensure Security P and Ps are Documented, etc.

any.
Controls
Requirement Number and Definition: A.1.3 Ensure Logging and Audit Trails are Enabled

139. Constraints List constraints precluding compliance with a.1.3 constraint
140. Objective Define the objective of the original control; a.1.3 objective
141. Identified Risk Identify any additional risk posed by the lack a.1.3 risk
142. Definition of Define the compensating controls and a.1.3 definition
any.
143. Validation of Define how the compensating controls were a.1.3 validaiton
Controls
144. Maintenance Define process and controls in place to a.1.3 maint
Compensating Controls Worksheet – Completed Example
Use this worksheet to define compensating controls for any requirement noted as being “in place” via compensating controls.
Requirement Number: 8.1.1 – Are all users identified with a unique user ID before allowing them to access system components or cardholder data?

1. Constraints List constraints precluding Company XYZ employs stand-alone Unix Servers without LDAP. As such, they each require a
compliance with the original “root” login. It is not possible for Company XYZ to manage the “root” login nor is it feasible to
requirement. log all “root” activity by each user.
2. Objective Define the objective of the The objective of requiring unique logins is twofold. First, it is not considered acceptable from a
original control; identify the security perspective to share login credentials. Secondly, having shared logins makes it
objective met by the impossible to state definitively that a person is responsible for a particular action.
3. Identified Risk Identify any additional risk Additional risk is introduced to the access control system by not ensuring all users have a
posed by the lack of the original unique ID and are able to be tracked.
control.
4. Definition of Define the compensating Company XYZ is going to require all users to log into the servers using their regular user
Compensating controls and explain how they accounts, and then use the “sudo” command to run any administrative commands. This allows
Controls address the objectives of the use of the “root” account privileges to run pre-defined commands that are recorded by sudo in
original control and the the security log. In this way, each user’s actions can be traced to an individual user account,
increased risk, if any. without the “root” password being shared with the users.
5. Validation of Define how the compensating Company XYZ demonstrates to assessor that the sudo command is configured properly using
Compensating controls were validated and a “sudoers” file, that only pre-defined commands can be run by specified users, and that all
Controls tested. activities performed by those individuals using sudo are logged to identify the individual
performing actions using “root” privileges.
6. Maintenance Define process and controls in Company XYZ documents processes and procedures to ensure sudo configurations are not
place to maintain compensating changed, altered, or removed to allow individual users to execute root commands without being
controls. individually identified, tracked and logged.
Appendix D: Segmentation and Sampling of Business Facilities/System Components
PCI DSS Template for Report on Compliance, Appendix D: Segmentation and Sampling of Business Facilities/System Components April 2015

Complete Roc

Uploaded by

Copyright:

Available Formats

Complete Roc

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Complete Roc

Uploaded by

Copyright:

Available Formats

Payment Card Industry Data Security Standard v3.

Presented to: My Parent for CM, LLC.

Date: November 06, 2015

Prepared by: Jodi QSA 1.1

Copyright © 2015 Trustwave. All Rights Reserved.

Payment Card Industry (PCI)

ROC Summary of Assessor Findings

RESPONSE WHEN TO USE THIS RESPONSE: USING THE SAMPLE BELOW:

What is the difference between “Not Applicable” and “Not Tested?”

1.1 Sample sub-requirement ☐ ☐ ☐ ☐ ☐

1.1.a Sample testing procedure Reporting Instruction <Report Findings Here>

1.1.b Sample testing procedure Reporting Instruction <Report Findings Here>

ROC Reporting Details

Dependence on another service provider’s compliance:

1. Contact Information and Report Date

1.2 Date and timeframe of assessment

1.3 PCI DSS version

1.4 Additional services provided by QSA company

2.2 High-level network diagram(s)

3.2 Cardholder Data Environment (CDE) overview

 People – such as technical support, management, administrators, operations

3.3 Network segmentation

Describe any networks confirmed to be out of scope:

3.5 Connected entities for processing

Description of any discussions/issues between the

processor entity processor

List all countries where the entity conducts business.

Facilities in this country reviewed:

3.7 Wireless summary

For each wireless technology in scope, identify the following (yes/no):

Wireless technology not in scope for this assessment:

Identified wireless technology

4.2 Description of cardholder data flows

How access to data stores is logged

4.4 Critical hardware in use in the cardholder data environment

Type of Device Vendor (make/model) Role/Functionality

4.5 Critical software in use in the cardholder data environment

 If sampling is not used:

Listing of all components (devices, Total Total

The purpose for sharing the

Not Applicable Not Applicable Not Applicable Not Applicable

4.9 Third-party payment applications/solutions

Reference Document Name Document date

4.11 Individuals interviewed

Is this person Summary of Topics Covered / Areas or

4.12 Managed service providers

5.1 Deploy anti-virus software on all systems commonly affected by

11.2.1 Perform quarterly internal vulnerability scans, and rescans as

4.14 Disclosure summary for “Not Tested” responses

List of all requirements/testing procedures with this result

marking all of req 3 as NT. This is the mark all resp

marking all of req 3 as NT. This is the mark all resp

marking all of req 3 as NT. This is the mark all resp

marking all of req 3 as NT. This is the mark all resp

marking all of req 3 as NT. This is the mark all resp

marking all of req 3 as NT. This is the mark all resp

marking all of req 3 as NT. This is the mark all resp

marking all of req 3 as NT. This is the mark all resp

marking all of req 3 as NT. This is the mark all resp