NIST Requirements

Function Category
Asset Management (ID.AM): The data, personnel, devices, systems,

and facilities that enable the organization to achieve business purposes
are identified and managed consistent with their relative importance to
business objectives and the organization’s risk strategy.
Business Environment (ID.BE): The organization’s mission,

objectives, stakeholders, and activities are understood and prioritized;
this information is used to inform cybersecurity roles, responsibilities,
and risk management decisions.
IDENTIFY (ID)
Governance (ID.GV): The policies, procedures, and processes to
manage and monitor the organization’s regulatory, legal, risk,
environmental, and operational requirements are understood and inform
the management of cybersecurity risk.
Risk Assessment (ID.RA): The organization understands the

cybersecurity risk to organizational operations (including mission,
functions, image, or reputation), organizational assets, and individuals.
Risk Management Strategy (ID.RM): The organization’s priorities,
constraints, risk tolerances, and assumptions are established and used to
support operational risk decisions.
Access Control (PR.AC): Access to assets and associated facilities is

limited to authorized users, processes, or devices, and to authorized
activities and transactions.
Awareness and Training (PR.AT): The organization’s personnel and

partners are provided cybersecurity awareness education and are
adequately trained to perform their information security-related duties
and responsibilities consistent with related policies, procedures, and
agreements.
Data Security (PR.DS): Information and records (data) are managed

consistent with the organization’s risk strategy to protect the
confidentiality, integrity, and availability of information.
PROTECT (PR)
Information Protection Processes and Procedures (PR.IP): Security

policies (that address purpose, scope, roles, responsibilities, management
commitment, and coordination among organizational entities), processes,
and procedures are maintained and used to manage protection of
information systems and assets.
Maintenance (PR.MA): Maintenance and repairs of industrial control

and information system components is performed consistent with
policies and procedures.
Protective Technology (PR.PT): Technical security solutions are

managed to ensure the security and resilience of systems and assets,
consistent with related policies, procedures, and agreements.
Anomalies and Events (DE.AE): Anomalous activity is detected in a

timely manner and the potential impact of events is understood.
Security Continuous Monitoring (DE.CM): The information system

and assets are monitored at discrete intervals to identify cybersecurity
DETECT (DE) events and verify the effectiveness of protective measures.
Security Continuous Monitoring (DE.CM): The information system
DETECT (DE) events and verify the effectiveness of protective measures.
Detection Processes (DE.DP): Detection processes and procedures are

maintained and tested to ensure timely and adequate awareness of
anomalous events.
Response Planning (RS.RP): Response processes and procedures are

executed and maintained, to ensure timely response to detected
cybersecurity events.
Communications (RS.CO): Response activities are coordinated with

internal and external stakeholders, as appropriate, to include external
support from law enforcement agencies.
RESPOND (RS)
Analysis (RS.AN): Analysis is conducted to ensure adequate response
and support recovery activities.
Mitigation (RS.MI): Activities are performed to prevent expansion of

an event, mitigate its effects, and eradicate the incident.
Improvements (RS.IM): Organizational response activities are

improved by incorporating lessons learned from current and previous
detection/response activities.
Recovery Planning (RC.RP): Recovery processes and procedures are

executed and maintained to ensure timely restoration of systems or assets
affected by cybersecurity events.
Improvements (RC.IM): Recovery planning and processes are

RECOVER (RC) improved by incorporating lessons learned into future activities.
Communications (RC.CO): Restoration activities are coordinated with

internal and external parties, such as coordinating centers, Internet
Service Providers, owners of attacking systems, victims, other CSIRTs,
and vendors.
RECOVER (RC)

and vendors.
Governance and
Compliance
Baseline
Atos PPS
Subcategory
ID.AM-1: Physical devices and systems within the organization are inventoried
ID.AM-2: Software platforms and applications within the organization are

inventoried
ID.AM-3: Organizational communication and data flows are mapped
ID.AM-4: External information systems are catalogued
ID.AM-5: Resources (e.g., hardware, devices, data, and software) are prioritized
based on their classification, criticality, and business value
ID.AM-6: Cybersecurity roles and responsibilities for the entire workforce and third-
party stakeholders (e.g., suppliers, customers, partners) are established
ID.BE-1: The organization’s role in the supply chain is identified and communicated
ID.BE-2: The organization’s place in critical infrastructure and its industry sector is
identified and communicated
ID.BE-3: Priorities for organizational mission, objectives, and activities are

established and communicated
ID.BE-4: Dependencies and critical functions for delivery of critical services are
established
ID.BE-5: Resilience requirements to support delivery of critical services are
established
ID.GV-1: Organizational information security policy is established
ID.GV-2: Information security roles & responsibilities are coordinated and aligned
with internal roles and external partners
ID.GV-3: Legal and regulatory requirements regarding cybersecurity, including

privacy and civil liberties obligations, are understood and managed
ID.GV-4: Governance and risk management processes address cybersecurity risks
ID.RA-1: Asset vulnerabilities are identified and documented
ID.RA-2: Threat and vulnerability information is received from information sharing

forums and sources
ID.RA-3: Threats, both internal and external, are identified and documented
ID.RA-4: Potential business impacts and likelihoods are identified
ID.RA-5: Threats, vulnerabilities, likelihoods, and impacts are used to determine risk
ID.RA-6: Risk responses are identified and prioritized

ID.RM-1: Risk management processes are established, managed, and agreed to by
organizational stakeholders
ID.RM-2: Organizational risk tolerance is determined and clearly expressed

ID.RM-3: The organization’s determination of risk tolerance is informed by its role in
critical infrastructure and sector specific risk analysis
PR.AC-1: Identities and credentials are managed for authorized devices and users
PR.AC-2: Physical access to assets is managed and protected

PR.AC-3: Remote access is managed
PR.AC-4: Access permissions are managed, incorporating the principles of least
privilege and separation of duties
PR.AC-5: Network integrity is protected, incorporating network segregation where

appropriate
PR.AT-1: All users are informed and trained
PR.AT-2: Privileged users understand roles & responsibilities

PR.AT-3: Third-party stakeholders (e.g., suppliers, customers, partners) understand
roles & responsibilities
PR.AT-4: Senior executives understand roles & responsibilities
PR.AT-5: Physical and information security personnel understand roles &

responsibilities
PR.DS-1: Data-at-rest is protected
PR.DS-2: Data-in-transit is protected
PR.DS-3: Assets are formally managed throughout removal, transfers, and disposition
PR.DS-4: Adequate capacity to ensure availability is maintained

PR.DS-5: Protections against data leaks are implemented
PR.DS-6: Integrity checking mechanisms are used to verify software, firmware, and
information integrity
PR.DS-7: The development and testing environment(s) are separate from the ,
production environment
PR.IP-1: A baseline configuration of information technology/industrial control
systems is created and maintained
PR.IP-2: A System Development Life Cycle to manage systems is implemented
PR.IP-3: Configuration change control processes are in place

PR.IP-4: Backups of information are conducted, maintained, and tested periodically
PR.IP-5: Policy and regulations regarding the physical operating environment for
organizational assets are met
PR.IP-6: Data is destroyed according to policy
PR.IP-7: Protection processes are continuously improved
PR.IP-8: Effectiveness of protection technologies is shared with appropriate parties
PR.IP-9: Response plans (Incident Response and Business Continuity) and recovery
plans (Incident Recovery and Disaster Recovery) are in place and managed
PR.IP-11: Cybersecurity is included in human resources practices (e.g.,

deprovisioning, personnel screening)
PR.IP-12: A vulnerability management plan is developed and implemented
PR.MA-1: Maintenance and repair of organizational assets is performed and logged
in a timely manner, with approved and controlled tools
PR.MA-2: Remote maintenance of organizational assets is approved, logged, and
performed in a manner that prevents unauthorized access
PR.PT-1: Audit/log records are determined, documented, implemented, and reviewed
in accordance with policy
PR.PT-2: Removable media is protected and its use restricted according to policy
PR.PT-3: Access to systems and assets is controlled, incorporating the principle of
least functionality
PR.PT-4: Communications and control networks are protected
DE.AE-1: A baseline of network operations and expected data flows for users and
systems is established and managed
DE.AE-2: Detected events are analyzed to understand attack targets and methods
DE.AE-3: Event data are aggregated and correlated from multiple sources and sensors
DE.AE-4: Impact of events is determined

DE.AE-5: Incident alert thresholds are established
DE.CM-1: The network is monitored to detect potential cybersecurity events
DE.CM-2: The physical environment is monitored to detect potential cybersecurity

events
DE.CM-3: Personnel activity is monitored to detect potential cybersecurity events
DE.CM-4: Malicious code is detected

DE.CM-5: Unauthorized mobile code is detected
DE.CM-6: External service provider activity is monitored to detect potential
cybersecurity events
DE.CM-7: Monitoring for unauthorized personnel, connections, devices, and
software is performed
DE.CM-8: Vulnerability scans are performed

DE.DP-1: Roles and responsibilities for detection are well defined to ensure
accountability
DE.DP-2: Detection activities comply with all applicable requirements

DE.DP-3: Detection processes are tested
DE.DP-4: Event detection information is communicated to appropriate parties

DE.DP-5: Detection processes are continuously improved
RS.RP-1: Response plan is executed during or after an event

RS.CO-1: Personnel know their roles and order of operations when a response is
needed
RS.CO-2: Events are reported consistent with established criteria

RS.CO-3: Information is shared consistent with response plans
RS.CO-4: Coordination with stakeholders occurs consistent with response plans

RS.CO-5: Voluntary information sharing occurs with external stakeholders to achieve
broader cybersecurity situational awareness
RS.AN-1: Notifications from detection systems are investigated
RS.AN-2: The impact of the incident is understood

RS.AN-3: Forensics are performed
RS.AN-4: Incidents are categorized consistent with response plans
RS.MI-1: Incidents are contained
RS.MI-2: Incidents are mitigated
RS.MI-3: Newly identified vulnerabilities are mitigated or documented as accepted
risks
RS.IM-1: Response plans incorporate lessons learned
RS.IM-2: Response strategies are updated
RC.RP-1: Recovery plan is executed during or after an event
RC.IM-1: Recovery plans incorporate lessons learned

RC.IM-2: Recovery strategies are updated
RC.CO-1: Public relations are managed

RC.CO-2: Reputation after an event is repaired
RC.CO-3: Recovery activities are communicated to internal stakeholders and
executive and management teams
NIST 800-53 Rev 4 ISO/IEC 27001:2013 HIPAA
CM-8 A.8.1.1, A.8.1.2 CM-8
CM-8 A.8.1.1, A.8.1.3 CM-8
AC-4, CA-3, CA-9, PL-8 A.13.2.1 AC-4, CA-3, CA-9, PL-8

AC-20, SA-9 A.11.2.6 AC-20, SA-9
CP-2, RA-2 SA-14 A.8.2.1 CP-2, RA-2 SA-14
CP-2, PS-7, PM-11 A.6.1.1 CP-2, PS-7, PM-11
CP-2, SA-12 A.15.1.3, A.15.2.1, A.15.2.2 CP-2, SA-12
PM-8 Gap PM-8
PM-11, SA-14 Gap PM-11, SA-14
CP-8, PE-9, PE-11, PM-8, SA-14 A.11.2.2, A.11.2.3, A.12.1.3 CP-8, PE-9, PE-11, PM-8, SA-
14
CP-2, CP-11, SA-14 A.11.1.4, A.17.1.1, A.17.1.2, A.17.2.1 CP-2, CP-11, SA-14
Controls from each family A.5.1.1 Controls from each family

PM-1, PS-7 A.6.1.1, A.7.2.1 PM-1, PS-7
Controls from each family A.18.1 Controls from each family
PM-9, PM-11 Gap PM-9, PM-11
CA-2, CA-7, CA-8, RA-3, RA-5, SA-5, A.12.6.1, A.18.2.3 CA-2, CA-7, CA-8, RA-3, RA-
SA-11, SI-2, SI-4, SI-5 5, SA-5, SA-11, SI-2, SI-4, SI-
5
PM-15, PM-16, SI-5 A.6.1.4 PM-15, PM-16, SI-5
RA-3, SI-5, PM-12, PM-16 Gap RA-3, SI-5, PM-12, PM-16

RA-2, RA-3, PM-9, PM-11, SA-14 Gap RA-2, RA-3, PM-9, PM-11,
SA-14
RA-2, RA-3, PM-16 A.12.6.1 RA-2, RA-3, PM-16
PM-4, PM-9 Gap PM-4, PM-9

PM-9 Gap PM-9
PM-9 Gap PM-9

PM-8, PM-9, PM-11, SA-14 Gap PM-8, PM-9, PM-11, SA-14
AC-2, IA Family A.9.2.1, A.9.2.2, A.9.2.4, A.9.3.1, AC-2, IA Family

A.9.4.2, A.9.4.3
PE-2, PE-3, PE-4, PE-5, PE-6, PE-3 A.11.1.1, A.11.1.2, A.11.1.4, A.11.1.6, PE-2, PE-3, PE-4, PE-5, PE-6,
A.11.2.3 PE-3
AC-17, AC-19, AC-20 A.6.2.2, A.13.1.1, A.13.2.1 AC-17, AC-19, AC-20
AC-2, AC-3, AC-5, AC-6, AC-16 A.6.1.2, A.9.1.2, A.9.2.3, A.9.4.1, AC-2, AC-3, AC-5, AC-6, AC-
A.9.4.4 16
AC-4, SC-7 .13.1.1, A.13.1.3, A.13.2.1 AC-4, SC-7
AT-2, PM-13 A.7.2.2 AT-2, PM-13
AT-3, PM-13 A.6.1.1, A.7.2.2 AT-3, PM-13

PS-7, SA-9 A.6.1.1, A.7.2.2 PS-7, SA-9
AT-3, PM-13 A.6.1.1, A.7.2.2 AT-3, PM-13
AT-3, PM-13 A.6.1.1, A.7.2.2 AT-3, PM-13
SC-28 A.8.2.3 SC-28

SC-8 A.8.2.3, A.13.1.1, A.13.2.1, A.13.2.3, SC-8
A.14.1.2, A.14.1.3
CM-8, MP-6PE-16 A.8.2.3, A.8.3.1, A.8.3.2, A.8.3.3, CM-8, MP-6PE-16
A.11.2.7
AU-4, CP-2, SC-5 A.12.3.1 AU-4, CP-2, SC-5
AC-4, AC-5, AC-6, PE-19, PS-3, PS-6, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, AC-4, AC-5, AC-6, PE-19, PS-
3, PS-6, SC-7, SC-8, SC-13,
SC-7, SC-8, SC-13, SC-31, SI-4 A.8.2.2, A.8.2.3, A.9.1.1, SC-31, SI-4
SI-7 A.12.2.1, A.12.5.1, SI-7
CM-2 A.12.1.4 CM-2
CM-2, CM-3, CM-4, CM-5, CM-6, CM- A.12.1.2, A.12.5.1, CM-2, CM-3, CM-4, CM-5,
7, CM-9, SA-10 CM-6, CM-7, CM-9, SA-10
SA-3, SA-4, SA-8, SA-10, SA-11, SA-12, A.6.1.5, A.14.1.1, A.14.2.1, A.14.2.5 SA-3, SA-4, SA-8, SA-10, SA-
SA-15, SA-17, PL-8 11, SA-12, SA-15, SA-17, PL-
8
CM-3, CM-4, SA-10 A.12.1.2, A.12.5.1, A.12.6.2, A.14.2.2, CM-3, CM-4, SA-10
A.14.2.3, A.14.2.4
CP-4, CP-6, CP-9 A.12.3.1, A.17.1.2A.17.1.3, A.18.1.3 CP-4, CP-6, CP-9
PE-10, PE-12, PE-13, PE-14, PE-15, A.11.1.4, A.11.2.1, A.11.2.2, A.11.2.3 PE-10, PE-12, PE-13, PE-14,
PE-18 PE-15, PE-18
MP-6 A.8.2.3, A.8.3.1, A.8.3.2, A.11.2.7 MP-6
A-2, CA-7, CP-2, IR-8, PL-2, PM-6 Gap A-2, CA-7, CP-2, IR-8, PL-2,
PM-6
AC-21, CA-7, SI-4 A.16.1.6 AC-21, CA-7, SI-4
CP-2, IR-8 A.16.1.1, A.17.1.1, A.17.1.2 CP-2, IR-8
CP-4, IR-3, PM-14 A.17.1.3 CP-4, IR-3, PM-14
PS Family A.7.1.1, A.7.3.1, A.8.1.4 PS Family
RA-3, RA-5, SI-2 A.12.6.1, A.18.2.2 RA-3, RA-5, SI-2

MA-2, MA-3, MA-5 A.11.1.2, A.11.2.4, A.11.2.5 MA-2, MA-3, MA-5
MA-4 A.11.2.4, A.15.1.1, A.15.2.1 MA-4
AU Family A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, AU Family

A.12.7.1
MP-2, MP-4, PM-5, PM-7 A.8.2.2, A.8.2.3, A.8.3.1, A.8.3.3, MP-2, MP-4, PM-5, PM-7
A.11.2.9
AC-3, CM-7 A.9.1.2 AC-3, CM-7
AC-4, AC-17, AC-18, CP-8, SC-7 A.13.1.1, A.13.2.1 AC-4, AC-17, AC-18, CP-8,
SC-7
AC-4, CA-3, CM-2, SI-4 Gap AC-4, CA-3, CM-2, SI-4
AU-6, CA-7, IR-4, SI-4 A.16.1.1, A.16.1.4 AU-6, CA-7, IR-4, SI-4
AU-6, CA-7, IR-4, IR-5, IR-8, SI-4 Gap AU-6, CA-7, IR-4, IR-5, IR-8,
SI-4
CP-2, IR-4, RA-3, SI -4 Gap CP-2, IR-4, RA-3, SI -4

IR-4, IR-5, IR-8 Gap IR-4, IR-5, IR-8
AC-2, AU-12, CA-7, CM-3, SC-5, SC-7, Gap AC-2, AU-12, CA-7, CM-3,
SI-4 SC-5, SC-7, SI-4
CA-7, PE-3, PE-6, PE-20 Gap CA-7, PE-3, PE-6, PE-20
AC-2, AU-12, AU-13, CA-7, CM-10, A.12.4.1 AC-2, AU-12, AU-13, CA-7,
CM-11 CM-10, CM-11
SI-3 A.12.2.1 SI-3
SC-18, SI-4. SC-44 A.12.5.1 SC-18, SI-4. SC-44
CA-7, PS-7, SA-4, SA-9, SI-4 A.14.2.7, A.15.2.1 CA-7, PS-7, SA-4, SA-9, SI-4
AU-12, CA-7, CM-3, CM-8, PE-3, PE-6, Gap AU-12, CA-7, CM-3, CM-8,
PE-20, SI-4 PE-3, PE-6, PE-20, SI-4
RA-5 A.12.6.1 RA-5

CA-2, CA-7, PM-14 A.6.1.1 CA-2, CA-7, PM-14
CA-2, CA-7, PM-14, SI-4 A.18.1.4 CA-2, CA-7, PM-14, SI-4

CA-2, CA-7, PE-3, PM-14, SI-3, SI-4 A.14.2.8 CA-2, CA-7, PE-3, PM-14, SI-
3, SI-4
AU-6, CA-2, CA-7, RA-5, SI-4 A.16.1.2 AU-6, CA-2, CA-7, RA-5, SI-4
CA-2, CA-7, PL-2, RA-5, SI-4, PM-14 A.16.1.6 CA-2, CA-7, PL-2, RA-5, SI-4,
PM-14
CP-2, CP-10, IR-4, IR-8 A.16.1.5 CP-2, CP-10, IR-4, IR-8

CP-2, CP-3, IR-3, IR-8 A.6.1.1, A.16.1.1 CP-2, CP-3, IR-3, IR-8
AU-6, IR-6, IR-8 A.6.1.3, A.16.1.2 AU-6, IR-6, IR-8

CA-2, CA-7, CP-2, IR-4, IR-8, PE-6, RA- A.16.1.2 CA-2, CA-7, CP-2, IR-4, IR-8,
5, SI-4 PE-6, RA-5, SI-4
CP-2, IR-4, IR-8 Gap CP-2, IR-4, IR-8

PM-15, SI-6 Gap PM-15, SI-6
AU-6, CA-7, IR-4, IR-5, PE-6, SI-4 A.12.4.1, A.12.4.3, A.16.1.5 AU-6, CA-7, IR-4, IR-5, PE-6,
SI-4
CP-2, IR-4 A.16.1.6 CP-2, IR-4

U-7, IR-4 A.16.1.7 U-7, IR-4
CP-2, IR-4, IR-5, IR-8 A.16.1.4 CP-2, IR-4, IR-5, IR-8
CP-2, IR-4, IR-8 A.16.1.5 CP-2, IR-4, IR-8
IR-4 A.12.2.1, A.16.1.5 IR-4
CA-7, RA-3, RA-5 A.12.6.1 CA-7, RA-3, RA-5
CP-2, IR-4, IR-8 A.16.1.6 CP-2, IR-4, IR-8

CP-10, IR-4, IR-8 A.16.1.5 CP-10, IR-4, IR-8

Gap Gap Gap

Gap Gap Gap
CP-2, IR-4 Gap CP-2, IR-4
Testing Control Evidence of Con
SSAE 16/SOC 2 Procedures Guidance
Control Exists:
Yes or No
Evidence of Control
Control is Executed Correctly: Control Output:
Comments Artifact Comment
Function Category


IDENTIFY (ID)





agreements.

PROTECT (PR)



DETECT (DE) Security Continuous Monitoring (DE.CM): The information system

events and verify the effectiveness of protective measures.

anomalous events.


RESPOND (RS)
RESPOND (RS)





and vendors.
Subcategory

inventoried

established
established


forums and sources



appropriate


responsibilities



least functionality

events



accountability

needed

risks


Atos
PPS Controls
,
Testing Guidance
Procedures
Control Exists:
Yes or No
Evidence of Control
# PCI DSS 3.1 Controls
Build and Maintain a Secure Network and Systems
Requirement 1: Install and maintain a firewall configuration to protect cardholder data
Firewalls are devices that control computer traffic allowed between an entity’s networks (internal) and untrusted networks (exter
traffic into and out of more sensitive areas within an entity’s internal trusted networks. The cardholder data environment is an ex
sensitive area within an entity’s trusted network.
1.1 Establish and implement firewall and router configuration

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

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

between the cardholder data environment and other networks,
including any wireless networks
3
1.1.3 Current diagram that shows all cardholder data flows

across systems and networks
4
1.1.4 Requirements for a firewall at each Internet connection and
between any demilitarized zone (DMZ) and the internal network
zone
1.1.5 Description of groups, roles, and responsibilities for

management of network 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.7 Requirement to review firewall and router rule sets at least

every six months
8
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
9 the networks belonging to the entity under review, and/or which
is out of the entity's ability to control or manage.
1.2.1 Restrict inbound and outbound traffic to that which is

necessary for the cardholder data environment, and specifically
deny all other traffic.
10
1.2.2 Secure and synchronize router configuration files.
11
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.
12
1.3 Prohibit direct public access between the Internet and any
system component in the cardholder data environment.
13
1.3.1 Implement a DMZ to limit inbound traffic to only system
components that provide authorized publicly accessible services,
protocols, and ports.
14
1.3.2 Limit inbound Internet traffic to IP addresses within the

DMZ.
15
1.3.3 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.)
16
1.3.4 Do not allow unauthorized outbound traffic from the

17 cardholder data environment to the Internet.
1.3.5 Permit only "established" connections into the network.
18
1.3.6 Place system components that store cardholder data (such

19 as a database) in an internal network zone, segregated from the
DMZ and other untrusted networks.
1.3.7 Do not disclose private IP addresses and routing
20 information to unauthorized parties.
Note: Methods to obscure IP addressing may include, but are
1.4 Install personal
not limited to: firewall software or equivalent functionality on
21 any portable computing devices (including company and/or
Network Address Translation (NAT)
employee-owned)
•1.5 Placing servers that connect
containing to the internet
cardholder when outside
data behind proxy the
network Ensure(for that security
example, policies
laptops andby
used operational
employees), procedures
and which for
22 servers/firewalls,
managing firewalls are documented, in use, and known to all
are also used
•affected
Removal or to access
filtering of the
routeCDE. Firewall (or for
advertisements equivalent)
private
parties.
configurations include:
networks that employ registered addressing,
Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters
•• Internal
Specificuse configuration
of RFC1918 settings
addressarespace
definedinstead of registered
•addresses.
Personal firewall (or equivalent functionality) is actively
running. (external and internal to an entity) often use vendor default passwords and other vendor default settings to
Malicious individuals
• Personal firewall (or equivalent functionality) is not alterable by
users of mobile and/or employee-owned devices.
2.1 Always change vendor-supplied defaults and remove or
23 disable unnecessary default accounts before installing a system
on the network.
2.1.1 For wireless
This applies to ALLenvironments connected
default passwords, to thebut
including cardholder
not limited
24 data
to those used by operating systems, software that providesALL
environment or transmitting cardholder data, change
wireless
security vendor defaults
services, applicationat installation,
and system including butpoint-of-sale
not limited
2.2default
to Develop configuration
wireless encryption standards
keys, for allaccounts,
passwords,systemandcomponents.
SNMP
25 (POS)
Assure terminals,
these standards address all known security (SNMP)
that strings. Simple Network Management Protocol
community
community strings, etc.).
vulnerabilities and are consistent with industry-accepted system
hardening standards.
Sources of industry-accepted system hardening standards may
include, but are not limited to:
• Ce•nter for Internet Security (CIS)
• International Organization for Standardization (ISO)
2.2.1 Implement only one primary function per server to prevent
26 functions that require different security levels from co-existing on
the same server. (For example, web servers, database servers,
2.2.2 Enable
and DNS onlybe
should necessary services,
implemented protocols,
on separate daemons, etc.,
servers.)
27 as required for the function of the system.
Note: Where virtualization technologies are in use, implement
only
2.2.3one primary function
Implement additionalper virtual features
security system component.
for any required
28 services,
protocols, or daemons that are considered to be insecure.
2.2.4
Note:Configure system security
Wheree SSL/early TLS is parameters to prevent misuse.
used, the requirements in
29
Appendix A2 must be completed.
2.2.5 Remove all unnecessary functionality, such as scripts,
30 drivers, features, subsystems, file systems, and unnecessary
web servers.
2.3 Encrypt all non-console administrative access using strong
31 cryptography. Note: Where SSL/early TLS is used, the
requirements in Appendix A2 must be completed.
2.4 Maintain an inventory of system components that are in
32 scope for PCI DSS.
2.5 Ensure that security policies and ooperational procedures for
33 managing vendor defaults and other security paramenters are
documented, in use, and known to all affected parties.
2.6 Shared hosting providers must protect each entity’s hosted
34 environment and cardholder data. These providers must meet
specific requirements as detailed in Appendix A1: Additional PCI
Protect Cardholder Data
DSS Requirements for Shared Hosting Providers.
Requirement 3: Protect stored cardholder data
Protection methods such as encryption, truncation, masking, and hashing are critical components of cardholder data protection
opportunities. For example, methods for minimizing risk include not storing cardholder data unless absolutely necessary, trunca
Please refer to the PCI DSS and PA-DSS Glossary of Terms, Abbreviations, and Acronyms for definitions of “strong cryptograph
3.1 Keep cardholder data storage to a minimum by implementing
35 data retention and disposal policies, procedures and processes
that include at least the following for all cardholder data (CHD)
3.2
storage: Do not store sensitive authentication data after authorization
36 (even if encrypted). If sensitive
• Limiting data storage amountauthentication
and retention data time is to received,
that which
render
is required all data
for unrecoverable
legal, regulatory, upon
and completion
business of the
requirements
3.2.1 Do not store
authorization process.the full It iscontents
permissible of anyfor track
issuers (from
andthe
37 •magnetic Specificstripe retention
located requirements
on the back forofcardholder
a card, data
equivalent data
companies
•contained Processes that support
forchip,
secure issuing services
deletion of after to store
data authorization.
when no longer sensitive needed
authentication on a datathe or
if: card elsewhere) This data
•is alternatively
3.2.2 A quarterly
Do not store process
called fullfortrack,
identifying
verification
track, and code
track securely
1,ortrack
value deleting
2, stored
(three-digit
and
38 •or There
cardholderfour-digitis adata
business
number justification
that printed
exceeds theand
ondefined frontretention.
or back of a payment
magnetic-stripe
•card Theused data to is verifydata.
stored securely.
card-not-present transactions) after
Sensitive
3.2.3
authorization.Do not authentication
store the personal data includes the data
identification as cited
number in the
(PIN) or the
39 Note:
following
encrypted In the normal
blockcourse
Requirements
PIN after 3.2.1of through
business,
authorization. the following data
3.2.3:
elements from the magnetic stripe may need to be retained:
 The
3.3 Mask cardholder’s
PAN whenname displayed (the first six and last four digits
40  Primary
are the maximum accountnumber numberof(PAN) digits to be displayed), such that

only Expiration
personnel date
with a legitimate business need can see more
3.4
 Service
than Render
the first PAN
code Tounreadable
six/last minimize
four digits anywhere
risk,
of store
the PAN. it is stored
only these data (including on
elements
41 portable digital media, backup media, and in logs) by using any
as needed
Note: This for business.does not supersede stricter requirements
requirement
of
in the following
place for approaches:
displays of cardholder data—for example, legal or
3.4.1
• One-wayIf diskhashes
encryption based is used (rather
on strong than file-
cryptography, or (hash
column-level
must be
42 payment
database card brand
encryption), requirements for point-of-sale
logical access must be managed (POS)
of the
receipts. entire PAN)
•separately
3.5 Truncation
Document
and independently
(hashing
and cannot be
implement
of used
nativetooperating
procedures replace
to protect
system
the truncated
keys usedbyto
43 authentication
segment of PAN) and access control mechanisms (for example,
secure
not using stored cardholder
local anduserpads account data against
databases disclosure
or and
generalstored) misuse:
network login
•Note:Index tokens
This requirement (pads
applies must
to keysbe used
securely to encrypt stored
credentials).
•cardholder
Strong
3.5.1 Decryption
cryptography
Additional keys
withapplies
requirement must
associated
forto not be associated
key-management
service providers with
only:user
44 accounts. data, and also key-encrypting
Note: This keys
requirement used to
processes
Maintain
protect a and procedures.
documented
data-encrypting description
keys— ofkey-encrypting
suchDSS the cryptiongrfaphic keyskey-
must
applies
Note: It to
is additioin
aasrelatively to all other
trivial PCI
effort encryption
for a malicious and
architecture
be at
management least that
strongincludes:
requirements.as the data-encrypting key. individual to
•reconstruct
Details of all original PAN data
algorithms, if they and
protocols, havekeys access used to for
both
thethe
truncated and
protection hashed version
of cardholder of a PAN.key
data, including Where strengthhashed andandexpiry
truncated versions of the same PAN are present in an entity’s
date
•environment,
Description of additional
the key usage controls formust
eachbe keyin place to ensure that
the hashed of
• Inventory andany truncated
HSMs and versions cannotused
other SCDs be correlated
for key to
reconstruct the original PAN.
management
3.5.2 Restrict access to cryptographic keys to the fewest number
45 of custodians necessary.
3.5.3 Store secret and private keys used to encrypt/decrypt
46 cardholder data in one (or more) of the following forms at all
times:
3.5.4 Store cryptographic
• Encrypted keys in the
with a key-encrypting keyfewest
that is possible locations.
at least as strong as
47
the data-encrypting key, and that is stored separately from the
data-encrypting
3.6 Fully document keyand implement all key-management processes and procedures for cryptographic keys used for
48 • Within a secure cryptographic device (such as a hardware
(host) security module (HSM) or PTS-approved point-of-
interaction device)of strong cryptographic keys
3.6.1 Generation
49 • As at least two full-length key components or key shares, in
accordance with an industry-accepted method
3.6.2
Note:Secure
It is notcryptographic key distribution
required that public keys be stored in one of these
50
forms.
3.6.3 Secure cryptographic key storage
51
3.6.4 Cryptographic key changes for keys that have reached the
52 end of their cryptoperiod (for example, after a defined period of
time has passed and/or after a certain amount of cipher- text has
3.6.5 Retirementbyorareplacement
been produced given key), as (for example,
defined archiving,
by the associated
53 destruction, and/or or
revocation) ofand
keysbased
as deemed necessary
application vendor key owner, on industry best
when the
practices integrity
and of the
guidelines key
(for has been
example, weakened
NIST (for
Special example,
Publication
3.6.6 If manual
departure of an clear-text
employeecryptographic
with knowledge key-management
of a clear-text key
54 800-57).
operations
component), or keys are suspected of being be
are used, these operations must managed using
compromised.
split
Note: knowledge and dual
If retired orofreplaced control.
cryptographic keysofneed to be
3.6.7 Prevention
Note: Examples unauthorized
of manual key- substitution
management cryptographic
55 retained,
keys. these keys must be securely archivedoperations include,
(for example, by
but are not limited to: key generation, transmission,
using a key-encryption key). Archived cryptographic keys should loading,
storage
only be
3.6.8 and destruction.
used
Requirement for decryption/verification
for cryptographic keypurposes.
custodians to formally
56 acknowledge that they understand and accept their key-
custodian responsibilities.
3.7 Ensure that security policies and operational procedures for
57 protecting stored cardholder data are documented, in use, and
known to all affected parties.
Requirement 4: Encrypt transmission of cardholder data across open, public networks
Sensitive information must be encrypted during transmission over networks that are easily accessed by malicious individuals. M
4.1 Use strong cryptography and security protocols to safeguard

58 sensitive cardholder data during transmission over open, public
networks, including the following:
4.1.1
• OnlyEnsure
trustedwireless
keys andnetworks transmitting
certificates cardholder data or
are accepted.
59 connected to the cardholder data environment, use industdry
• The protocol in use only supports secure versions or
best practices
configurations. to implement strong encryption for authentication
4.2
and Never send unprotected PANs by end-user messaging
60 Thetransmission.
•technologies
encryption
(for strength
example,ise-mail,
appropriate
instantformessaging,
the encryption
SMS, chat,
methodology
etc.). in use.
Note:
4.3 Wherethat
Ensure SSL/early
securityTLS is used,
policies and the requirements
operational in
procedures for
61 Appendix A2
encrypting must be completed.
transmissions of cardholder data are documented, in
Examples
use, of open,
and known public
to all networks
affected include but are not limted to:
parties.
Maintain a Vulnerability
• The internetManagement Program
• Wireless technologies, including 802.11 and Bluetooth
Requirement• Cellular technologies,
5: Protect all systems for against
example,malware
Global System for Mobile
and regularly update anti-virus software or programs
communications (GSM), Code division multiple access (CDMA)
• Gemneral Packet Radio Service (GPRS)
• Satelite
Malicious software, commuications
commonly referred to as “malware”—including viruses, worms, and Trojans—enters the network during man
evolving malicious software threats. Additional anti-malware solutions may be considered as a supplement to the anti-virus soft
5.1 Deploy anti-virus software on all systems commonly affected
62 by malicious software (particularly personal computers and
servers).
5.1.1 Ensure that anti-virus programs are capable of detecting,
63 removing, and protecting against all known types of malicious
software.
5.1.2 For systems considered to be not commonly affected by
64 malicious software, perform periodic evaluations to identify and
evaluate evolving malware threats in order to confirm whether
5.2
suchEnsure
systems thatcontinue
all anti-virus
to notmechanisms
require anti-virus are maintained
software. as
65 follows:
• Are kept current,
5.3 Ensure periodic
• Perform that anti-virus
scansmechanisms are actively running and
66 cannot be disabled or altered by users, unless specifically
• Generate audit logs which are retained per PCI DSS
authorized
Requirement by management
10.7. on a case-by-case basis for a limited
5.4
timeEnsure
period.that security policies and operational procedures for
67 protecting systems againstmay malware are documented,
Note: Anti-virus solutions be temporarily disabledinonly use,if and
Requirementthere is legitimate
6: Develop andtechnical
maintainneed, secure as authorized
systems and by management
applications
on a case-by-case basis. If anti-virus protection needs to be
disabled for a specific purpose, it must be formally authorized.
Unscrupulous Additional
individuals security measures
use security may also need
vulnerabilities to gain to privileged
be implemented access to systems. Many of these vulnerabilities are fixe
for the period of time during which anti-virus protection is not
active.
Note:
Appropriate
software
patches 6.1 Establish a process to identify security vulnerabilities, using
68 are reputable outside sources for security vulnerability information,
those
patches and assign a risk ranking (for example, as “high,” “medium,” or
6.2 Ensure
“low”) to newlythatdiscovered
all system components and software are
security vulnerabilities.
that have
69 protected from known vulnerabilities by installing
been Note: Risk rankings should be based on industry applicable
best practices
vendor-
as well supplied
as security
consideration patches.
of potential Install
impact. critical
For security patches
example, criteria
evaluated 6.3 withinDevelop
one month internal and external software applications (including
of release.
70 for ranking
and tested web-based vulnerabilities
administrative may
accessinclude consideration
to applications) of the
securely, CVSS
asto
Note:
base Critical
score, security
and/or the patches should
classification bybethe identified
vendor, according
and/or type
sufficiently follows:
the risk ranking process defined
to of
 systems
6.3.1 In Remove affected.
accordance Methods
development,
with PCI DSS forin
test Requirement
evaluating
and/or
(for custom
example,
6.1.
vulnerabilities
application
secure and
71 assigning
accounts, risk
user ratings
IDs, will
and vary based
passwords on
before an organization’s
applications become
determine authentication and logging)
that the environment
active
 or are
Based and
onreleased risk- standards
industry assessment
to customers. strategy.
and/or best Risk rankings
6.3.2
should, Review
at a custom
minimum, code prior
identify allto release
vulnerabilities to practices.
production
considered or to be
patches
72 do  Incorporating
customers in order information
to identify security
any throughout
potential coding the software-
vulnerability
not conflict a “high risk” tolife
development
(using either manual
thecycle
environment. In addition to the risk ranking,
orconsidered
automated“critical”
processes) to pose
include at least
with vulnerabilities
Note: this
6.4 following: appliesmay
Follow change control tobeall software
processes developed if internally
they
and procedures asanwell
for all as
73 the
imminent threat to the environment, impact critical systems,
existing bespoke
changes
•and/or
Codewouldor system
to custom
changes software developed
components.
are The by a third
processes party.
must include
the the
security following: result in reviewed
a potentialbycompromise
individuals other
if not than
addressed.
originating
Examples code
of author,
critical and by
systems may individuals knowledgeable
include security systems, about
configuratio 6.4.1 Separate
code-review
development/test
techniques and secure
environments
coding
from
practices.
production
74 public-facing devices and systems, databases, and other
ns. For in- environments,
• Code reviews
and enforce
ensure
the separation
codeoristransmit
developed
with access
according
controls.
to secure
house systems that store, process, cardholder data.
codingSeparation
6.4.2 guidelinesof duties between development/test and
developed
75 • Appropriate
production corrections are implemented prior to release.
environments
applications • Code-review results are reviewed and approved by
, numerous 6.4.3 Production
management priordata (live PANs) are not used for testing or
to release.
76
vulnerabiliti development
Note: This requirement for code reviews applies to all custom
es can be code (both internal and public-facing), as part of the system
avoided by 6.4.4 Removal of test data and accounts before production
development life cycle.
77 systems become active / goes into production.
using Code reviews can be conducted by knowledgeable internal
standard personnel or third parties. Public-facing web applications are also
6.4.5 Change control procedures must include the following:
system78 subject to additional controls, to address ongoing threats and
developme vulnerabilities after implementation, as defined at PCI DSS
nt 6.4.5.1
RequirementDocumentation
6.6. of impact.
79
processes
and secure
coding 6.4.5.2 Documented change approval by authorized parties.
80
techniques.
6.4.5.3 Functionality testing to verify that the change does not
81 adversely impact the security of the system.
6.4.5.4 Back-out procedures.
82
6.4.6 Upon completion of a significant change, all relevant PcI

83 DSS requirements must be implemented on all new or changed
systems and networks, and documentation updated as
6.5 Address common coding vulnerabilities in software-
applicable.
84 development processesisasa follows:
Note: This requirement best practice until January 31, 2018,
•after
Train developers
which it becomes in secure
a coding techniques, including how to
requirement.
Note: common
avoid Requirements coding6.5.1 through 6.5.6,
vulnerabilities, andbelow, apply to all
understanding how
85 applications (internal or external).
sensitive data is handled in memory.
•6.5.1
Develop applications
Injection based onSQL
flaws, particularly secure codingAlso
injection. guidelines.
consider OS
86 Note:
Command Injection, LDAP and XPath injection flaws aswere
The vulnerabilities listed at 6.5.1 through 6.5.10 well as
current with industry
other injection flaws. best practices when this version of PCI DSS
was
6.5.2published. However, as industry best practices for
Buffer overflows
87 vulnerability management are updated (for example, the OWASP
Guide, SANS CWE Top 25, CERT Secure Coding, etc.), the
6.5.3 Insecure
current cryptographic
best practices must bestorage
used for these requirements.
88
6.5.4 Insecure communications

89
6.5.5 Improper error handling

90
6.5.6 All “high risk” vulnerabilities identified in the vulnerability

identification process (as defined in PCI DSS Requirement 6.1).
91 Note: Requirements 6.5.7 through 6.5.10, below, apply to web
Note: Requirements
applictions 6.5.7 through
and application 6.5.10,
interfaces below,
(internal apply to web applications and application interfaces (internal or e
or external):
6.5.7 Cross-site scripting (XSS)

92
6.5.8 Improper access control (such as insecure direct object

93 references, failure to restrict URL access, directory traversal, and
failure to restrict user access to functions).
6.5.9 Cross-site request forgery (CSRF)
94
6.5.10 Broken authentication and session management

95
6.6 For public-facing web applications, address new threats and

96 vulnerabilities on an ongoing basis and ensure these
applications are protected against known attacks by either of the
6.7 Ensure
following that security policies and operational procedures for
methods:
97 developing and maintaining secure systemsviaand applications are
• Reviewing public-facing web applications manual or
documented,
automated in use, and
application known to all
vulnerability affected
security parties. tools or
assessment
Implement Strong Access Control Measures
methods, at least annually and after any changes
Note: This assessment is not the same as the vulnerability scans
Requirementperformed for Requirement
7: Restrict 11.2.
access to cardholder data by business need to know
• Installing an automated technical solution that detects and
prevents web-based attacks (for example, a web-application
To ensure critical dataincan
firewall) frontonly be accessed web
of public-facing by authorized personnel,
applications, systems and processes must be in place to limit access
to continually
“Need to know” is when access
check all traffic. rights are granted to only the least amount of data and privileges needed to perform a job.
7.1 Limit access to system components and cardholder data to
98 only those individuals whose job requires such access.
7.1.1 Define access needs for each role, including:
99 • System components and data resources that each role needs
to access for their job function
7.1.2
• LevelRestrict accessrequired
of privilege to privileged user IDs user,
(for example, to least privileges
administrator,
100 necessary to perform job responsibilities.
etc.) for accessing resources.
7.1.3 Assign access based on individual personnel’s job
101 classification and function.
7.1.4 Require documented approval by authorized parties
102 specifying required privileges.
7.2 Establish an access control system for systems components
103 that restricts access based on a user’s need to know, and is set
to “deny all” unless specifically allowed.
7.2.1 Coverage
This access of allsystem
control systemmust
components
include the following:
104
7.2.2 Assignment of privileges to individuals based on job

105 classification and function.
7.2.3 Default “deny-all” setting.
106

107 restricting access to cardholder data are documented, in use,
and known to all affected parties.
Requirement 8: Identify and authenticate access to system components
Assigning a unique identification (ID) to each person with access ensures that each individual is uniquely accountable for their a
—particularly, how frequently password attempts can be made by an attacker, and the security methods to protect user passwo
The effectiveness of a password is largely determined by the design and implementation of the authentication system—particul
Note: These requirements are applicable for all accounts, including point-of-sale accounts, with administrative capabilities and
However, Requirements 8.1.1, 8.2, 8.5, 8.2.3 through 8.2.5, and 8.1.6 through 8.1.8 are not intended to apply to user accounts
8.1 Define and implement policies and procedures to ensure
108 proper user identification management for non- consumer users
and administrators on all system components as follows:
8.1.1 Assign all users a unique ID before allowing them to
109 access system components or cardholder data.
8.1.2 Control addition, deletion, and modification of user IDs,
110 credentials, and other identifier objects.
8.1.3 Immediately revoke access for any terminated users.
111
8.1.4 Remove/disable inactive user accounts within 90 days.

112
8.1.5 Manage IDs used by vendors to access, support, or

113 maintain system components via remote access as follows:
 Enabled only during the time period needed and disabled
8.1.6
when Limit
not inrepeated
use. access attempts by locking out the user ID
114 after not more than six attempts.
 Monitored when in use.
8.1.7 Set the lockout duration to a minimum of 30 minutes or until
115 an administrator enables the user ID.
8.1.8 If a session has been idle for more than 15 minutes,
116 require the user to re-authenticate to re-activate the terminal or
session.
8.2 In addition to assigning a unique ID, ensure proper user-
117 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.1 Using strong cryptography, render all authentication
118 credentials (such as passwords/phrases) unreadable during
transmission and storage on all system components.
8.2.2 Verify user identity before modifying any authentication
119 credential—for example, performing password resets,
provisioning new tokens, or generating new keys.
8.2.3 Passwords/phrases must meet the following:
120  Require a minimum length of at least seven characters.
 Contain both numeric and alphabetic characters.
8.2.4 Changethe
Alternatively, user passwords/passphrases
passwords/phrases at least
must have once every
complexity and
121 90 days.
strength at least equivalent to the parameters specified above.
8.2.5 Do not allow an individual to submit a new
122 password/phrase that is the same as any of the last four
passwords/phrases he or she has used.
8.2.6 Set passwords/phrases for first- time use and upon reset to
123 a unique value for each user, and change immediately after the
first use.
8.3 Secure all individual non-console administrative access and
124 all remote access to the CDE using multi-factor authentication.
Note: Multi-factor authentication requires that a minimum of two
8.3.1
of theIncorporate multi-factor
three authentication authentication
methods for all non-console
(see Requirement 8.2 for
125 access
descriptions of authentication methods) be used for access
into the CDE for personnel with administrative
Note: This requirement
authentication. Using one is a best twice
factor practice (foruntil January
example, 31, two
using 2018,
8.3.2 which
after Incorporate
it multi-factor
becomes a authentication
requirement. for all remote
126 separate passwords) is not considered multi-factor
network access (both user and administrator, and including third-
authentication.
party access for support or maintenance) originating form outside
8.4 Document
the entity's and communicate authentication procedures and
network
127 policies to all users including:
 Guidance on selecting strong authentication credentials
8.5 Do not usefor
 Guidance group, shared,
how users or generic
should protectIDs, passwords,
their or
authentication
128 other authentication methods as follows:
credentials

 Generic
Instructions usernot IDstoare
reusedisabled or removed.
previously usedproviders
passwords
8.5.1
 Additional
Shared user requirement
IDs do not existfor
forservice
system only:and
administration
129  Instructions
Service providers to change
with passwords
remote access if there
to is any premises
customer suspicion the
(for
other
passwordcriticalcouldfunctions.
be compromised.
example,
 forandsupport of POS systems or used
servers) must use a
8.6 Shared
Where
unique othergeneric
authentication
user IDs
authentication
credential
are not
mechanisms
(such as a
to administer
are used (for any
password/phrase) for
130 system
example, components.
physical or logical security tokens, smart cards,
each customer.
certificates, etc.), use of these mechanisms must be assigned as
8.7 All access to any database containing cardholder data
follows:
131 Note: Thisaccess
(including requirementby is not intended
applications, to apply to and
administrators, shared hosting
all other
 Authentication
providers accessing mechanisms
their own must
hosting be assigned towhere
environment, an
users)
individualis restricted
account as follows:
and not shared among multipleprocedures
accounts. for
multiple
8.8AllEnsure
 user customer
access environments
that security
to, user policies
queries are
and
of,hosted.
operational
andbeuser actions
132  Physical
identification and/or
and logical controls
authentication are must
documented,in placein to on
ensure
use, and
databases
only the are
intended through
account programmatic
can use that methods.
mechanism to gain
Requirement 9:Only
access. database
Restrict administrators
physical access tohave the abilitydata
cardholder to directly
access or query databases.
 Application IDs for database applications can only be used by
Any physicalthe applications
access to data or (and not bythat
systems individual
house users or other
cardholder datanon-
provides the opportunity for individuals to access devices o
application
facility for a short duration, processes).
usually not more than one day. “Media” refers to all paper and electronic media containing cardholde
9.1 Use appropriate facility entry controls to limit and monitor
133 physical access to systems in the cardholder data environment.
9.1.1 Use video cameras and/or access control mechanisms to
134 monitor individual physical access to sensitive areas. Review
collected data and correlate with other entries. Store for at least
9.1.2
three Implement
months, unlessphysical and/orrestricted
otherwise logical controls
by law.to restrict access
135 to publicly accessible network jacks.
Note: “Sensitive areas” refers to any data center, server room or
For
any example,
area that network
houses jacks located
systems that in public
store, areasor
process, and areas
transmit
9.1.3 Restrict
accessible to physicalcould
visitors accessbe to wireless
disabled access
and only points,
enabled when
136 cardholder
gateways, data. This
handheld excludes
devices, public-facing areas
networking/communications where only
network
point-of- access
sale is explicitly
terminals are authorized.
present, suchAlternatively,
as the processes
cashier areas in
hardware,
could be and telecommunication
implemented toto
ensure lines.
a retail
9.2 store.
Develop procedures easilythat visitors are
distinguish escorted
between at all
onsite
137 times in areas
personnel and with active
visitors, network jacks.
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).
9.3 Control physical access for onsite personnel to the sensitive
138 areas as follows:
 Access must be authorized and based on individual job
9.4 Implement procedures to identify and authorize visitors.
function.
139 Procedures
 Access isshould include
revoked the following:
immediately upon termination, and all
physical
9.4.1 Visitors are authorized before as
access mechanisms, such keys, access
entering, cards, at
and escorted etc.,
all
140 are returned
times within, or disabled.
areas where cardholder data is processed or
maintained.
9.4.2 Visitors are identified and given a badge or other
141 identification that expires and that visibly distinguishes the
visitors from onsite personnel.
9.4.3 Visitors are asked to surrender the badge or identification
142 before leaving the facility or at the date of expiration.
9.4.4 A visitor log is used to maintain a physical audit trail of
143 visitor activity to the facility as well as computer rooms and data
centers where cardholder data is stored or transmitted.
9.5 Physically
Document the secure
visitor’sall media.
name, the firm represented, and the
144
onsite personnel authorizing physical access on the log.
Retain this log
9.5.1 Store for abackups
media minimum in of three months,
a secure location,unless otherwise
preferably an
145 restricted by law.
off-site facility, such as an alternate or backup site, or a
commercial storage facility. Review the location’s security at least
9.6 Maintain strict control over the internal or external distribution
annually.
146 of any kind of media, including the following:
9.6.1 Classify media so the sensitivity of the data can be
147 determined.
9.6.2 Send the media by secured courier or other delivery
148 method that can be accurately tracked.
9.6.3 Ensure management approves any and all media that is
149 moved from a secured area (including when media is distributed
to individuals).
9.7 Maintain strict control over the storage and accessibility of
150 media.
9.7.1 Properly maintain inventory logs of all media and conduct
151 media inventories at least annually.
9.8 Destroy media when it is no longer needed for business or
152 legal reasons as follows:
9.8.1 Shred, incinerate, or pulp hard- copy materials so that
153 cardholder data cannot be reconstructed. Secure storage
containers used for materials that are to be destroyed.
9.8.2 Render cardholder data on electronic media unrecoverable
154 so that cardholder data cannot be reconstructed.
9.9 Protect devices that capture payment card data via direct
155 physical interaction with the card from tampering and
substitution.
9.9.1
Note:Maintain an up-to-date
These requirements list oftodevices.
apply The list
card- reading shouldused in
devices
156 include the following:
card-present transactions (that is, card swipe or dip) at the point
•ofMake,sale. model
This of device is not intended to apply to manual key-
requirement
9.9.2
•entry Periodically
Location of device inspect
(for as device surfaces
example, to detect
thekeyboards
address thetampering
ofand site or
157 (for components
example, such
addition of computer
card skimmers to devices), POS
or
facility
keypads. where the device is located)
•substitution
Device serial
9.9.3
(fornumber
example, by checking
orpersonnel
other methodbethe serial
uniquenumber
ofaware or other
ofidentification.
158 deviceProvide training for
characteristics to verify it hastonot been swapped attempted
with a
tampering
fraudulent or replacement of devices. Training should include the
device).
following:
Note: Examples
9.10 Ensure
•tampered
Verify the that of
identity
signs that
security
of anypolicies
a device might have procedures
and persons
third-party operational been
claiming to be for
159 restricting with or
physical substituted
access to include
cardholderunexpected
data are attachments
documented, or
repair
cables or maintenance
plugged into the personnel,
device, prior toorgranting
missing changed them access in
security
use,
to and known
modify to all affected
or troubleshoot parties.
devices.
labels, broken or differently colored casing, or changes to the
•serial
Do number
not install, replace, or return
or other external markings. 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).
Regularly Monitor and Test Networks
Requirement 10: Track and monitor all access to network resources and cardholder data
Logging mechanisms and the ability to track user activities are critical in preventing, detecting, or minimizing the impact of a dat
10.1 Implement audit trails to link all access to system

160 components to each individual user.
10.2 Implement automated audit trails for all system components
161 to reconstruct the following events:
10.2.1 All individual user accesses to cardholder data
162
10.2.2 All actions taken by any individual with root or

163 administrative privileges
10.2.3 Access to all audit trails
164
10.2.4 Invalid logical access attempts

165
10.2 5 Use of and changes to identification and authentication

166 mechanisms—including but not limited to creation of new
accounts and elevation of privileges—and all changes, additions,
10.2.6 Initialization,
or deletions stopping,
to accounts or pausing
with root of the audit
or administrative logs
privileges
167
10.2.7 Creation and deletion of system- level objects

168
10.3 Record at least the following audit trail entries for all system
169 components for each event:
10.3.1 User identification
170
10.3.2 Type of event

171
10.3.3 Date and time

172
10.3.4 Success or failure indication

173
10.3.5 Origination of event

174
10.3.6 Identity or name of affected data, system component, or

175 resource.
10.4 Using time-synchronization technology, synchronize all
176 critical system clocks and times and ensure that the following is
implemented for acquiring, distributing, and storing time.
10.4.1
Note: OneCritical systems
example havesynchronization
of time the correct and technology
consistent time.
is
177
Network Time Protocol (NTP).
10.4.2 Time data is protected.
178
10.4.3 Time settings are received from industry-accepted time
179 sources.
10.5 Secure audit trails so they cannot be altered.
180
10.5.1 Limit viewing of audit trails to those with a job-related

181 need.
10.5.2 Protect audit trail files from unauthorized modifications.
182
10.5.3 Promptly back up audit trail files to a centralized log

183 server or media that is difficult to alter.
10.5.4 Write logs for external-facing technologies onto a secure,
184 centralized, internal log server or media device.
10.5.5 Use file-integrity monitoring or change-detection software
185 on logs to ensure that existing log data cannot be changed
without generating alerts (although new data being added should
10.6 Review
not cause an logs
alert).and security events for all system components
186 to identify anomalies or suspicious activity.
Note: Log harvesting, parsing, and alerting tools may be used to
10.6.1
meet this Review the following at least daily:
Requirement.
187 • All security events
• Logs of all system components that store, process, or transmit
10.6.2
CHD and/or Review SAD logs of all other system components periodically
188 based on the organization’s policies and risk management
• Logs of all critical system components
strategy,
•10.6.3
Logs Follow as determined
of all servers by
and systemthe organization’s annual risk
assessment. up exceptions and components that perform
anomalies identified during the
189 security functions
review process. (for example, firewalls, intrusion-detection
systems/intrusion-prevention systems (IDS/IPS), authentication
servers,
10.7 Retain e-commerce
audit trail redirection
history for at servers,
least oneetc.).
year, with a
190 minimum of three months immediately available for analysis (for
example, online, archived, or restorable from backup).
10.8 Additional requirement for service providers only:
191 Implement a process for the timely detection and reporting of
failures of critical security control systtems, including but not
10.8.1
limited Additional
to failure of:requirement for service providers only:
192 Respond
•Firewallsto failures of any critical security controls in a timely
manner.
•IDS/IPS Processes for responding to failures in security
10.9 Ensure that
controlsmust security policies and operational procedures for
include:
193 •FIM
monitoring all access to network resources and cardholder data
•Restoring
•Anti-virus security functions
are documented, in use, and known to all affected parties.
Requirement•Identifying
•Physical
11: Regularly and documenting
access securitythe
controls
test systems and processes.
duration (date and
•Logical access time start to end)
controls
of the security
•Audit failure
logging mechanisms
Vulnerabilities•Identifying
are being and
•Segmentation documenting
discovered
controls continually
(if used) by malicious individuals and researchers, and being introduced by new software
cause(s) of failure,
Note: This requirement is a bestincluding rootpractice until January 31, 2018,
cause,
after and documenting
which it becomes a requirement.
11.1 Implement
remediation processes
required to test for the presence of wireless
to address
194 access points (802.11), and detect and identify all authorized and
root cause
unauthorized
•Identifying andwireless
addressing access any points on a quarterly basis.
11.1.1
Note: Maintain that
Methods an inventory
may be of authorized
used wireless
in the process access
include butpoints
are
195 security
including issues
a that
documented arose during
business justification.
not limited
the failure to wireless network scans, physical/logical inspections
of system
•Performing
11.1.2 components
Implement a risk incident andresponse
assessment infrastructure,
to procedures network in access
the eventcontrol
196 (NAC), or wireless
determine whether
unauthorized wireless IDS/IPS.
further
access Whichever
actions methods
points are detected. are used, they
must be sufficient
are required to detect
as a result of theand identify both authorized and
unauthorized
11.2 Runfailure
security devices..
internal and external network vulnerability scans at
197 least quarterly and aftertoany significant change in the network
•Implementing controls prevent
(such
use as new
of failure system
from component
reoccurring installations, changes in
11.2.1
network Perform
topology, quarterly
firewall internal
rule vulnerabilityproduct
modifications, scans and rescans
upgrades).
198 •Resuming
as needed, monitoring of security
until all “high-risk” vulnerabilities (as identified in
controls
Requirement 6.1)
Note:
Note: Multiple
This scanare
requirement
resolved.
reports
is a can
Scans
bestbe
must be
combined
practice untilfor
performed by
the quarterly
January 31, 2018,
qualified
scan personnel.
process to show that all systems were scanned and all
after which it becomes a requirement.
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
11.2.2 Perform quarterly external vulnerability scans, via an
199 Approved Scanning Vendor (ASV) approved by the Payment
Card Industry Security Standards Council (PCI SSC). Perform
11.2.3
rescansPerform
as needed, internal
untiland external
passing scansscans,are and rescans as
achieved.
200 needed, after any significant change. Scans must be performed
performed
Note: Quarterly external vulnerability scans must be
by
by qualified
anImplement personnel.
Approved aScanning Vendor
11.3 methodology for (ASV),
penetrationapprovedtestingbythat
the
201 Payment
includes the Card Industry Security Standards Council (PCI SSC).
following:
Refer to the ASV
 Is based Program Guide published
on industry-accepted penetration ontesting
the PCI SSC
website
11.3.1 for
Perform scan customer
external responsibilities,
penetration
approaches (for example, NIST SP800-115) testing scan
at preparation,
least annually and etc.
202 after any significant infrastructure or application upgrade or
 Includes coverage for the entire CDE perimeter and critical
modification
systems (such as an operating system upgrade, a sub-
11.3.2 Perform
network added internal penetration testing
to the environment, orand
a web at server
least annually toand
203 
afterIncludes
any significant from
testing both inside
infrastructure outside
or application theadded
upgradenetwork
or
the
environment).
 Includes testing toanvalidate any system
segmentation anda scope-
modification (such as operating upgrade, sub-
reduction
11.3.3 controls
network added to the environment, or a web server addedtesting
Exploitable vulnerabilities found during penetration to the
204 
are Defines
corrected application-layer penetration
and testing is repeated tests the
to verify to include, at a
corrections.
environment).
minimum, the vulnerabilities listed in Requirement 6.5
11.3.4
 DefinesIf segmentation
network-layer is used to isolate
penetration thetoCDE
tests from other
include
205 networks, perform penetration tests at least as annually
components that support network functions well asand after
operating
any changes
systems to segmentation controls/methods to verify that the
11.3.4.1
segmentationAdditionalmethods requirement
are for service
operational and providers
effective, and only:
isolateIf
206  Includes review
segmentation is andconfirm
used, consideration
PCI DSS of scope
threatsbyand performing
all out-of-scope
vulnerabilities systems from
experienced systems
in the 12inmonths
lastcontrols the CDE.
penetration testing on segmentation at least every six
 Specifies
11.4 Useand
months retention
intrusion-detection of
after any changes penetration
and/or testing results and
intrusion-prevention
to segmentation
207 remediation
techniques toactivities
detect results.
and/or prevent intrusions into the network.
controls/methods.
Monitor
Note: all traffic
This requirement at the perimeter of
is a best mechanismthe cardholder
practice until(for January data31, 2018,
11.5 Deploy
environment aaschange-detection
well as at critical points in the example,
cardholder file-
data
208 after which
integrity it becomes
monitoring tools)a requirement.
to alert personnel to unauthorized
environment, and alert personnel to suspected compromises.
modification
Keep (including changes, additions, and deletions) of
11.5.1all
critical
intrusion-detection
Implement
system files, a process and
configuration
prevention
to respond
files, or
engines,
tocontent
any alerts baselines,
generated
files; and
209 and
by signatures
the change- up to date.
detection solution.critical file comparisons at least
configure the software to perform
weekly.
210 security monitoring and testing are documented, in use, and
Note:
knownFor change-detection
to all affected parties.purposes, critical files are usually
Maintain an those that do Security
Information not regularly change, but the modification of which
Policy
could indicate a system compromise or risk of compromise.
Change-detection mechanisms such as file-integrity monitoring
Requirementproducts
12: Maintain
usuallya come
policypre-configured
that addresses information
with critical files security
for the for all personnel.
related operating system. Other critical files, such as those for
custom
A strong security applications,
policy must be
sets the security evaluated
tone and defined
for the whole by the
entity and entity personnel what is expected of them. All personne
informs
(that is, the merchant or service provider).
12.1 Establish, publish, maintain, and disseminate a security

211 policy.
12.1.1 Review the security policy at least annually and update
212 the policy when the environment changes.
12.2 Implement a risk-assessment process that:
213 • Is performed at least annually and upon significant changes to
the environment (for example, acquisition, merger, relocation,
12.3
etc.),Develop usage policies for critical technologies and define
214 proper use critical
of these technologies.
• Identifies assets, threats, and vulnerabilities, and
Note:
•12.3.1 Examples
Results in a of critical
formal, technologies
documented include,
analysis butExamples
of risk. are not of
limited Explicit
to, remoteapproval
access byandauthorized
wireless parties
technologies, laptops,
215 risk-assessment methodologies include but are not limited to
tablets, removable electronic media,
OCTAVE, ISO 27005 and NIST SP 800-30. e- mail usage and Internet
usage.
12.3.2 Authentication for use of the technology
216 Ensure these usage policies require the following:
12.3.3 A list of all such devices and personnel with access

217
12.3.4 A method to accurately and readily determine owner,
218 contact information, and purpose (for example, labeling, coding,
and/or inventorying of devices)
12.3.5 Acceptable uses of the technology
219
12.3.6 Acceptable network locations for the technologies

220
12.3.7 List of company-approved products

221
12.3.8 Automatic disconnect of sessions for remote-access

222 technologies after a specific period of inactivity
12.3.9 Activation of remote-access technologies for vendors and
223 business partners only when needed by vendors and business
partners, with immediate deactivation after use
12.3.10 For personnel accessing cardholder data via remote-
224 access technologies, prohibit the copying, moving, and storage
of cardholder data onto local hard drives and removable
12.4 Ensure
electronic that the
media, security
unless policy
explicitly and procedures
authorized clearly
for a defined
225 define information security responsibilities for all personnel.
business need.
Where there is an authorized
12.4.1 Additional requirement business need,providers
for service the usageonly:policies
226 must require
Executive the data beshall
management protected in accordance
establish with
responsibility forallthe
applicable
protection ofPCI DSS Requirements.
cardholder data and PCI DSS compliance program
12.5 Assign
to include: to an individual or team the following information
227 security
•Overall management
accountabilityresponsibilities:
for maintaining PCI DSS compliance
•Defining
12.5.1 Establish, document,DSS
a charter for PCI andcompliance program
distribute security and and
policies
228 communication
procedures. to executive management.
Note: This requirement is a best practice until January 31, 2018,
after which
12.5.2 it becomes
Monitor a requirement.
and analyze security alerts and information, and
229 distribute to appropriate personnel.
12.5.3 Establish, document, and distribute security incident
230 response and escalation procedures to ensure timely and
effective handling of all situations.
12.5.4 Administer user accounts, including additions, deletions,
231 and modifications.
12.5.5 Monitor and control all access to data.
232
12.6 Implement a formal security awareness program to make all

233 personnel aware of the importance of cardholder data security
policy and procedures.
12.6.1 Educate personnel upon hire and at least annually.
234 Note: Methods can vary depending on the role of the personnel
and their level of access to the cardholder data.
12.6.2 Require personnel to acknowledge at least annually that
235 they have read and understood the security policy and
procedures.
12.7 Screen potential personnel prior to hire to minimize the risk
236 of attacks from internal sources. (Examples of background
checks include previous employment history, criminal record,
12.8
creditMaintain and reference
history, and implementchecks.)
policies and procedures to manage
237 service
Note: For those potential personnel to bedata
providers with whom cardholder is shared,
hired or that
for certain
could affect
positions theas
such security
store of cardholder
cashiers who data,have
only as follows:
access to one
12.8.1 Maintain a list of service providers.
238 card number at a time when facilitating a transaction, this
requirement is a recommendation only.
12.8.2 Maintain a written agreement that includes an
239 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
cardholder data environment.
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.
12.8.3 Ensure there is an established process for engaging
240 service providers including proper due diligence prior to
engagement.
12.8.4 Maintain a program to monitor service providers’ PCI DSS
241 compliance status at least annually.
12.8.5 Maintain information about which PCI DSS requirements
242 are managed by each service provider, and which are managed
by the entity.
243 Service providers acknowledge in writing to customers that they
are responsible for the security of cardholder data the service
12.10
provider Implement
possesses an orincident
otherwise response
stores,plan. Be prepared
processes, to
or transmits
244 respond
on behalfimmediately
of the customer, to a system
or to the breach.
extent that they could impact
the
12.10.1 security
Createof the
thecustomer’s cardholder
incident response plandata
to beenvironment.
implemented in
245 Note: This requirement is a best practice
the event of system breach. Ensure the plan addresses until June 30, 2015,
the
after which it becomes
following, at a minimum: a requirement.
Note:
•12.10.2 The
Roles, exactand
Review wording
responsibilities,test theof
and an acknowledgement
plan, includingall and
communication will
elements depend
contact on
listed in
246 the agreement
Requirement between
12.10.1, at the
leasttwo parties,
annually. the details of the service
strategies in the event of a compromise including notification of
being
the provided,
payment and the
brands, at aresponsibilities
minimum assigned to each party.
12.10.3
The Designate
acknowledgement specific
does personnel
not to be available on a 24/7
247 •basis
Specific
to incident
respond to response
alerts. proceduresinclude the exact
have to
wording
• Business provided
recoveryin this
and requirement.
continuity procedures
•12.10.4
Data backup processes
Provide appropriate training to staff with security breach
248 • Analysis
response of legal requirements for reporting compromises
responsibilities.
• Coverage and responses of all critical system components
12.10.5 Include
• Reference or alerts
inclusionfromofsecurity
incidentmonitoring systems, from
response procedures
249 including but not limited to intrusion-detection, intrusion-
the payment brands.
prevention, firewalls, and file-integrity monitoring systems.
12.10.6 Develop a process to modify and evolve the incident
250 response plan according to lessons learned and to incorporate
industry developments.
12.11 Additional requirement for service providers only: Pergorm
251 reviews at least quarterly to confirm personnel are following
security policies and operational procedures. Revviews must
12.11.1
cover the Additional requirement for service providers only:
following processes:
252 Maintain
• Daily logdocumentation
reviews of quarterly review process to include:
•Documenting results of the reviews
Appendix A:••Review
Firewall
Additionalrule-set
and PCI DSSreviews
sign-off ofRequirements
results for Shared
by personnel assignedHosting Providers
• Applying configuration standards to new systems
responsibiliity
• Responding to forsecurity
the PCI alerts
DSS compliance program
Note:
• ChangeThis requirement
management
Requirement A.1: Shared hosting providers is a best practice
processes until January
must protect 31, 2018, data environment
the cardholder
after
Note:which it becomes aisrequirement.
This requirement a best practice until January 31, 2018,
As referenced in Requirement 12.8 and 12.9, all service providers with access to cardholder data (including shared hosting pro
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.1.1 Ensure
A hosting that each
provider mustentity only runs
fulfill these processesas
requirements that have
well as all
access to that entity’s cardholder
other relevant sections of the PCI DSS. data environment.
Note: Even though
A.1.2 Restrict each a hosting
entity’s provider
access andmay met these
privileges to its own
requirements, the compliance
cardholder data environment only. of the entity that uses the hosting
provider is not guaranteed. Each entity must comly with the CI
DSS and
A.1.3 validate
Ensure compliance
logging and audit trails are enabled and unique to
each entity’s cardholder data environment and 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.
Testing
Procedures
protect cardholder data
an entity’s networks (internal) and untrusted networks (external), as well as

l trusted networks. The cardholder data environment is an example of a more
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 Examine documented procedures to verify there

is a formal process for testing and approval of all:
• Network connections and
• Changes to firewall and router configurations
1.1.1.b For a sample of network connections, interview
responsible personnel and examine records to verify that
network connections were approved and tested
1.1.1.c Identify a sample of actual changes made to
firewall and router configurations, compare to the change
records, and interview responsible personnel to verify the
changes were approved and tested.
1.1.2.a Examine diagram(s) and observe network

configurations to verify that a current network diagram
exists and that it documents all connections to cardholder
data, including any wireless networks.
1.1.2.b Interview responsible personnel to verify that the
diagram is kept current.
1.1.3 Examine data-flow diagram and interview personnel

to verify the diagram:
• Shows all cardholder data flows across systems and
networks.
• Is kept current and updated as needed upon changes to
the environment.
1.1.4.a Examine the firewall configuration standards and
verify that they include requirements for a firewall at each
Internet connection and between any DMZ and the
internal network zone.
1.1.4.b Verify that the current network diagram is
consistent with the firewall configuration standards.
1.1.4.c Observe network configurations to verify that a
firewall is in place at each Internet connection and
between any demilitarized zone (DMZ) and the internal
network zone, per the documented configuration
standards and network diagrams.
1.1.5.a Verify that firewall and router configuration

standards include a description of groups, roles, and
responsibilities for management of network components.
1.1.5.b Interview personnel responsible for management
of network components to confirm that roles and
responsibilities are assigned as documented.

standards include a documented list of all services,
protocols and ports, including business justification and
approval for each.
1.1.6.b Identify insecure services, protocols, and ports
allowed; and verify that security features are documented
for each service.
1.1.6.c Examine firewall and router configurations to
verify that the documented security features are
implemented for each insecure service, protocol, and
port.

standards require review of firewall and router rule sets at
least every six months.
1.1.7.b Examine documentation relating to rule set
reviews and interview responsible personnel to verify that
the rule sets are reviewed at least every six months.
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.a Examine firewall and router configuration

standards to verify that they identify inbound and
outbound traffic necessary for the cardholder data
environment.
1.2.1.b Examine firewall and router configurations to
verify that inbound and outbound traffic is limited to that
which is necessary for the cardholder data environment.
1.2.1.c Examine firewall and router configurations to
verify that all other inbound and outbound traffic is
specifically denied, for example by using an explicit “deny
all” or an implicit deny after allow statement.
1.2.2.a Examine router configuration files to verify they

are secured from unauthorized access.
1.2.2.b Examine router configurations to verify they are
synchronized—for example, the running (or active)
configuration matches the start-up configuration (used
when machines are booted).
1.2.3.a Examine firewall and router configurations to

verify that there are perimeter firewalls installed between
all wireless networks and the cardholder data
environment.
1.2.3.b Verify that the firewalls deny or, if traffic is
necessary for business purposes, permit only authorized
traffic between the wireless environment and the
cardholder data environment
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:
1.3.1 Examine firewall and router configurations to verify
that a DMZ is implemented to limit inbound traffic to only
system components that provide authorized publicly
accessible services, protocols, and ports.
that inbound Internet traffic is limited to IP addresses
within the DMZ.

that inbound Internet traffic is limited to IP addresses
within the DMZ

that anti-spoofing measures are implemented, for
example internal addresses cannot pass from the
Internet into the DMZ.

that outbound traffic from the cardholder data
environment to the Internet is explicitly authorized.
that the firewall permits only established connections into
the internal network and denies any inbound connections
1.3.6 Examine firewall
not associated and routerestablished
with a previously configurations to verify
session.
that system components that store cardholder data are
on an internal network zone, segregated from the DMZ
1.3.7.a
and other Examine
untrusted firewall and router configurations to
networks.
verify that methods are in place to prevent the disclosure
of private IP addresses and routing information from
1.4.a
internalExamine
networks policies
to theand configuration standards to
Internet.
verify:
1.3.7.b Interview personnel and examine documentation

to Personal
verify thatfirewall
any softwareof
disclosure orprivate
equivalent functionality
IP addresses andis
1.5 Examine
required for documentation
all portable and
computing interview
devices personnel
(including to
routing
verify information
that security to external
policies andentities is authorized.
operational procedures
company and/or employee-owned) that connect to the
for managing
Internet when firewalls
outside are:
the network (for example, laptops
em passwords
 and other security parameters
Documented,
used by employees), and which are also used to access
 In use, and
the CDE.

endor default Known
Specifictoconfiguration
 passwords all
andaffected parties.
settingsdefault
other vendor are defined
settingsfortopersonal
compromise systems. These passwords and settings are well known by hacke
firewall (or equivalent functionality).
 Personal firewall (or equivalent functionality) is
2.1.a Choose
configured a sample
to actively run.of system components, and
attempt
 Personal to log on (with
firewall (or system
equivalent administrator
functionality)help)
is to the
devices
configured and applications
to not responsible using default
be alterable personnel vendor-supplied
by users ofand theexamine
portable
2.1.1.a
accounts Interview
and passwords, to verify that ALL default
computing
supporting devices.
documentation toonverify that: systems,
passwords
1.4.b Inspect (including
a sample those
ofchanged
companyoperating
and/or employee-
 Encryption
software keys
that provides were security from default at
owned devices
2.2.a Examine
installation to verify
the that: services,
organization’s system application
configuration and
system

standards accounts,
Personal firewall
for all POS
types(or terminals,
equivalent
of system and Simple
functionality)
components Network
is
and verify
 Encryption keys
Management Protocolare (SNMP)
changedcommunity
anytime anyone strings)with
have
installed
the system
knowledge andof configured
configuration
the keys per
leaves the
standards
theorganization’s
are consistent
company or specific
with
changes
been changed.
configuration
industry-accepted (Use
settings. vendor manuals
hardening standards. and sources on the
positions.
Internet to find vendor-supplied accounts/passwords.)
 Personal firewall (or equivalent functionality) is actively
2.1.b
2.2.b For
running.Examinethe sample
policies ofand
system components,
interview personnel verify
toandthat
verify
2.1.1.b
all Interview
unnecessary personnel
default and examine
accounts (including policies
accounts

thatPersonal
system
procedures firewall (or
configuration
to verify: equivalent
standards functionality)
are updated is not
as new
used by operating
alterable
vulnerability by users
issuesof systems, security
theidentified,
are portable as software,
computing
defined devices.
in
2.2.1.a Select a sample of system components and
inspect the system configurations to verify that only one
primary function is implemented per server.
2.2.2.a Select a sample of system components and
inspect
2.2.1.b Ifenabled virtualization systemtechnologies
services, daemons, are used,and inspect the
protocols
system to verify
configurations that only
to verify necessary
that only services
one or
primary
2.2.3.a Inspect
protocols are configuration settings to verify that
enabled.
function
security is implemented
featuresany areenabled per
documented virtual system
andservices, component
implemented foror
2.2.2.b
device. Identify insecure daemons,
all
or insecure services,
protocols and interview daemons, personnel or protocols.
to verify
2.2.4.a Interview system administrators and/orthey securityare
justified
managers per documented
to verify that configuration standards
2.2.3.b If SSL/early TLSthey is used, haveperform knowledge testing of common
security
procedures parameterin Appendix settings for system components.
2.2.5.a Select a sample A2: of systemAdditional PCI DSSand
components
Requirements
inspect the for Entities using
configurations to verify SSL/Early
that TLS.
all unnecessary
2.2.4.b Examine the system configuration standards to
functionality
verify that common (for example, security scripts,
parameter drivers, features,
settings
2.3 Select
subsystems, a sample
file systems, of system etc.) components
is removed. andare verify
included.
that non-console administrative access is encrypted by
2.2.4.c
performing Select theafollowing:
sample of system components and
2.2.5.b.
inspect
2.4.a Observe Examine
the
Examine common the security
system documentation
inventory parameters
to verifyand that security
to verify listthat
asystem of
2.3.a
parameters to an
verify administrator
enabled log
functions on to are eachdocumented
they
hardware
and are
examine setand appropriately
software
system and
components
configurations in accordance
is
to maintained
verify with
that a the
and
strong
and
includessupport
configuration secure
standards.
a description configuration.
of function/use for administrator’s
each.
encryption
2.2.5.c. Examine method is invoked
the documentation before the
2.5
2.4.b Examine
password Interview is
documentation
personnel
requested.
and interview
to verify theand security
documentedpersonnel to
parameters
verify
inventory that to
security verify
is kept current. that
policies only and documented
operational functionality
procedures is
2.3.b
present
for Review
managingon theservices sampled
vendor and system
defaults parameter
and components.
other files on systems to
security
determine
2.6 Perform
parameters that Telnet
testing
are: and other A1.1
procedures insecure through remote-login
A1.4
commands
detailed
 Documented, in are
Appendix not available
A1: Additional for non-console
PCI DSS access.
2.3.c Observe
Requirements
 In use, and an
for administrator
Shared Hosting log on to
Providers each for system
PCI DSS to
verify
assessmentsthat administrator
of
 Known to all affected parties. shared access
hosting to any
providers, web-basedto verify that
management
shared hostinginterfaces providersisprotect encrypted theirwith entities’strong (merchants
cryptography.
and service providers) hosted environment and data.
2.3.d Examine vendor documentation and interview
personnel to verify that strong cryptography for the
technology
ashing are critical components in use isofimplementedcardholder data according
protection. to industryIf an intruder circumvents other security controls and gains access to encrypte
best practices
t storing cardholder data unless and/orabsolutely
vendor recommendations.
necessary, truncating cardholder data if full PAN is not needed, and not sending unprotected PA
2.3.e
eviations, and If SSL/early
Acronyms TLS is used,
for definitions of “strong perform testing
cryptography” and other PCI DSS terms.
3.1.a
proceduresExamine the data retention
in Appendix A2: Additional and disposal
PCI DSSpolicies,
procedures
Requirements andforprocesses
Entities using to verify SSL/Earlythey include TLS. the
following for all cardholder data (CHD) storage:
3.2.a
 LimitingFor issuersdata storage and/oramount companies and that retentionsupport time issuing
to that
services and store sensitive
which is required for legal, regulatory, and/or business authentication data, review
policies
requirements. and interview personnel to verify there is a
3.2.1 For a sample
documented business of system
justification components,for thecardholder examine
storage ofdatadata
 Specific
sources requirements
including but notdata. for
limitedretention to theoffollowing, and
sensitive
(for example, authentication
verify that the cardholder
full contents data of any needs track to from
be held thefor X
magnetic
period
3.2.2
stripe for
For
on the aY business
sample
backand/or of reasons).
system
of cardcompanies components,
or equivalent examine data
3.2.b

sources, For
Processes issuers
including for secure
but notdeletion
limited ofto thatdata
cardholder
the support
following,
on aissuing
data
chip
and when
are not stored
services aftersensitive
authorization:
no
verify
 thatand
longer
Incoming needed
the store for legal,
three-digit
transaction
authentication
regulatory,
or four-digit
data card data, examine
or business
verification
data
3.2.3
reasons.
code stores
For
or a
value and
sample system
printed of configurations
system
on the components,
front of the tocard
verify or that
examine the the data
 All logsincluding
sensitive
sources, (for example,
authentication but nottransaction,
data limitedis secured.
to history,
the followingdebugging,and
 A quarterly
signature
error) panel process
(CVV2,forCVC2, identifying CID, and CAV2 securely
data) is not
3.2.c
verify
deleting
stored For
that all
PINs
stored
after other and entities,
cardholder
authorization: encrypted ifdata
sensitive
PIN
that authentication
blocks
exceeds aredefined
not stored data

is History
3.3.a Examine
received,
after files
authorization: review written policies
policies and and procedures
procedures, and forexamine
retention

 Incoming
Trace
masking requirements.
files
the transaction
display of to data to verify:
PANs
system
 Incoming
3.1.b
 All configurations
Interview
logs (for transaction
personnel
example, verify
datato verify
transaction, the that:data is not
history, retained
debugging,
 Several
A list
after
 All of rolesdatabase
authorization.
logs (for example,that need schemas access
transaction, to displays
history, of more than
debugging,


the All
error)
3.4.a locations
Examine
Database
first six/last of
contents. stored
documentation
fourentities, cardholder
(includes about data
the
full PAN)authentication are
system included
is documented, used in to
3.2.d
error)
the
 For
data
History
protect the all
retention
files other
PAN, and
including disposalif sensitive
the processes.
vendor, type of data
together
is
 received,
History withreview a legitimateprocedures business and need
examine for eachthe(if role to

haveEither
Trace
system/process,
such afiles
files quarterly
access. and automatic
the encryption or manual algorithmsprocess is in
processes
 Trace
3.4.1.a
place
 Several
applicable) files
tomust for
Ifidentify
disk
database
tobe securely
encryption
andthat
verify deleting
securely
schemas is used,
the PAN the
delete is data
inspect
stored
rendered totheverify
cardholder that the
unreadable

data
 PAN is
Several
configurationunrecoverable.
database
and masked schemas
observe when the displayed
authentication such that onlyto
process
data.
 Database
using
personnel any of with contents.
thea following
legitimate methods:
business need can see ismore

 Database
verify
The
One-waythat
quarterly contents.
logical
hashes access
automaticbased tooron encrypted
manual
strong file systems
process
cryptography, is
than
3.5 the
Examine
implemented first six/last
key-management
via a four
mechanism digits of the
policies
that is PAN. and procedures
separate from the
performed


to Truncation
All
verifyroles for all locations
not specifically
processes are specified of cardholder
authorized to protectto seedata. the full
keys used PAN for
native
3.1.c
 Index operating
Fortokens
asee sample system’s
andofpads, system authentication
withcomponents
the pads mechanism
beingthat securely
store (for
must
encryption
example, only not of masked
cardholder
using PANs.
local userdata against
account and disclosure
databases andor
cardholder
stored
3.5.1
3.3.b
misuse Interview
Examine
and data: responsible
system
include personnel
configurations
at credentials).
least the following: to verify review that full
general
 Examine
Strong
documentation network files
cryptography, login
and
to verify systemwith
that records
associated
a todocument to verify that
key-management
exists to theof
PAN

3.4.1.b is only
Access todisplayed
Observe keys for
is restricted
processes users/roles
and the fewest
interview with a number
documented
personnel to in
data
processes
describe
business stored the and
need, does not
procedures.
cryptographic exceed
and that keys PAN the
architecture,
is requirements including: defined
custodians
verify
the
3.4.b
 data
Examine
Details of
necessary.
thatretention
cryptographic
all policy
several
algorithms, tables aremasked
or
protocols, stored
files from
and
for
a
keys
all other
securely
sampleused (foroffor
requests.
 Key-encrypting
example, stored on keys are at least
removable media as that
strong iskey as the data-
adequately

data
the Observe
3.3.c repositories
protection
encryptingExamine the deletion
of to verify
cardholder
displays
keysstrong they protect. mechanism
the
of PAN PAN
data, isto verify
rendered
including
(for example, on screen, data is
strength
protected
deleted
unreadable
and expiry with
securely. (that is,
date access
not stored controls).
inPANsplain-text).
on
 paper
Key-encrypting
3.4.1.c receipts)
Examine the to
keys verify
are
configurationsthat
stored andare
separately masked
observe from the when
data-
3.4.c

displaying
encryptingExamine
Description a
of
cardholder
keys. sample
the key
data,of
usage removable
and for
that each
onlymedia
key
those (forwith a
processes
example, toofverify
back-up anytapes) that cardholder data on removable

 Inventory
legitimate
Keys
media isare business
stored
encrypted need to
HSMs
securely
wherever
and
are confirm
in other
able
the
stored. tothat
SCDs
fewestsee
Note:
the
more PAN
used
possible
If
for
than
disk
is key
the
rendered
management
first six/last unreadable.
locations
encryption and isfour digits
forms.
not used of to the
encrypt PAN.removable media, the
3.5.2 Examine user access lists to verify that access to
keys is restricted to the fewest number of custodians
necessary
3.5.3.a Examine documented procedures to verify that
cryptographic keys used to encrypt/decrypt cardholder
data must only exist in one (or more) of the following
3.5.4
formsExamine
at all times. key storage locations and observe
processes
 Encrypted to with
verifya that keys are stored
key-encrypting in the
key that is atfewest
least as
possible
strong as locations.
the data-encrypting key, and that is stored
3.6.a Additional testing procedure for service provider
separately
assessments from theIfdata-encrypting
only: the service provider key shares keys

with their customers for transmission or (such
Within a secure cryptographic device storage asofa
hardware
3.6.1.a Verify
cardholder (host) that
data, security module
key-management
examine (HSM) or PTS-approved
procedures
the documentation thatspecify
the
point-of-interaction
how
service to generate device)
strong
provider provides keys.
to their customers to verify that
 As key
3.6.1.b
it3.6.2.a
includes components
Observe
guidance the on orhow
keytoshares,
procedures in accordance
for generating
securely transmit, keys with
to
store,
an
verify Verify
industry-accepted
that strongthatkeyskey-management
method
are generated. procedures specify
and
how update
to securely customers’
distribute keys,
keys.in accordance with
3.5.3.b
RequirementsExamine system
3.6.1 through configurations
3.6.8 below. and key storage
3.6.2.b Observe
locations to verify thethatmethod for distributing
cryptographic keys keystoto verify
used
3.6.b
3.6.3.a
that Examine
keysVerify the key-management
that key-management
are distributed securely. procedures
procedures and
specify
encrypt/decrypt
processes
how for keys
to securely cardholder
store used data exist in one
for encryption of cardholder
keys. (or more)data of
the following
and perform
3.6.3.b Observe form at
the following:all times.
the method for storing keys to verify that

keys Encrypted
3.6.4.a areVerify
stored with
that akey-management
key-encrypting key
securely. procedures include a
 Withincryptoperiod
defined a secure cryptographic
for each keydevice type in(such
use and as adefine
hardware
a process (host) for keysecurity
changes module
at the (HSM)
end of or thePTS-approved
defined
3.6.5.a Verify that key-management
point-of-interaction
cryptoperiod(s). device) procedures specify
processes
 As key
3.6.4.b for thepersonnel
components
Interview following:
or keytoshares, in accordance
verify that keys are with

an The retirement
industry-accepted
changed at the end or of
replacement
method
the defined ofcryptoperiod(s).
keys when the
3.6.6.a
integrity Verify
of thethat manual
keykey-encrypting
has been clear-text
weakened key-management
3.5.3.c
procedures Whereverspecify processes forkeys
the are of
use used, examine
the following:
 The replacement
system configurations of known
and key orstorage
suspected compromised
locations to verify:

keys.Split knowledge of keys, such that key components are

underKey-encrypting
3.6.7.athe Verify thatof
control keys are
key-management
atafter
least at least
two people as strong
procedures
who only as the data-
specify
have
 Any
encrypting
processes keys retained
keys
to they protect retiring or replacing are not
knowledge
used of prevent
for encryptiontheir own unauthorized
key components;
operations
substitution
AND of keys.

 Key-encrypting
Dual Verify
controlthat keys
of personnel
keys, are stored
suchtothat separately
at least two from
people data-
are
3.6.5.b
3.6.8.a
encrypting
3.6.7.b Interview
keys.
Interview key-management
personnel verify
and/or the
observe following
procedures specify
processes to
required
processes to perform
arekey
for any
implemented:
custodianskey-management
to acknowledge operations
(in and
writing
verify
no that
one person unauthorized
has access substitution
to the of keys is prevented.
 Keys
or are retired
electronically) or
that replaced
they as authentication
understand necessary
and accept whenmaterials
the
their
(for
3.7 example,
Examine
integrity
key-custodian passwords
of thedocumentation
key has been
responsibilities. or keys)
and of another.
interview
weakened, personnel
including whento
verify
someone that with
security policiesofand
knowledge theoperational
key leaves procedures
the company.
3.6.6
for
 Keys
3.6.8.b b Interview
protecting stored
are replaced
Observe personnel
cardholder
if known
documentation and/or
ordata
or observe processes
are:evidence
suspected
other to be to
oss open, public
verify
 networks
that
Documented, manual clear-text keys are managed with:
compromised.
showing that key custodians have acknowledged (in

 In Split
Any
writing use,knowledge,
keys
or and retainedAND
electronically) after retiring
that or replacing and
they understand are accept
not

used
theirDual
Known
forcontrol
to all affected
encryption
key-custodian
networks that are easily accessed byparties.
operations.
responsibilities.
malicious individuals. Misconfigured wireless networks and vulnerabilities in legacy encryption and aut
4.1.a Identify all locations where cardholder data is

transmitted or received over open, public networks.
Examine documented standards and compare to system
4.1.1 Identify all
configurations towireless
verify the networks transmitting
use of security protocols and
cardholder
strong cryptography for all locations.cardholder data
data or connected to the
environment.
4.1.b Review Examine
documented documented
policies standards
and proceduresand to
4.2.a
compareIf end-user
to system messaging technologies
configuration settings areverify
to usedtheto
verify
send processes data,
cardholder are specified
observe for the following:
processes for sending
following
 Forand for all wireless
acceptance of onlynetworks
trusted identified:
keys and/or certificates
PAN
 Industry examine
best a sample
practices ofused
areonly outbound transmissions
to implement strong

4.3
as For
they the
Examine protocol
occur to in
verifyuse
documentationthatto and
PAN support
isinterview
renderedsecure versions
personnel
unreadable to
encryption
and
verify that for
configurationsauthentication
security (that
policies and
insecure
and transmission.
versions
operational or
procedures
or
 secured
Weak with strong
encryption cryptography
(forsupported)
example, WEP, whenever
SSL) isitnot
is sent
configurations
for
via encrypting
end-user are not
transmissions
messaging of cardholder
technologies. data are:used
as
 a security
For
Documented, control forofauthentication
implementation proper encryption or transmission.
strength of pera
4.2.b Review written policies to verify the existence
the
 Inencryption
use, and methodology in use
policy stating that unprotected PANs are not to be sent
ularly update4.1.c
 Select
Known
viaanti-virus
end-user and
to all observe
affected
messaging
software or aprograms
sample of inbound and
parties.
technologies.
outbound transmissions as they occur (for example, by
observing system processes or network traffic) to verify
that all
viruses, worms, andcardholder
Trojans—entersdata is theencrypted
networkwith strong
during many business-approved activities including employee e-mail and use of the Intern
cryptography
ns may be considered as during transit. to the anti-virus software; however, such additional solutions do not replace the need for anti-virus
a supplement
4.1.d Examine keys and certificates to verify that only
trusted keys and/or certificates are accepted.
4.1.e Examine system configurations to verify that the
protocol is implemented to use only secure configurations
and does not support insecure versions or configurations.
4.1.f Examine system configurations to verify that the
proper encryption strength is implemented for the
5.1 For a sample of system components including all
operating system types commonly affected by malicious
software, verify that anti-virus software is deployed if
5.1.1
applicableReview vendortechnology
anti-virus documentation exists. and examine anti-
virus configurations to verify that anti-virus programs;
 Detect all known types of malicious software,
5.1.2
 Remove Interview personnel
all known typestoofverify malicious that evolving
software, malware
and
threats
 Protect areagainst
monitored and evaluated
all known types of malicious for systems not
software.
currently
Examples considered
of types ofto be commonly
malicious software affected byviruses,
5.2.a
malicious Examine software, policies in and procedures
order to confirm toinclude
whetherverifysuch that anti-
Trojans,
virus worms,
software and spyware,
definitions adware,are and rootkits.
required to be kept up
systems continue to not require anti-virus software.
to date.
installation
5.2.b Examine of the software
anti-virus and a sampleincluding
configurations, of systemthe
components,
master installation to verify of thethesoftware
anti-virustosoftware is actively
verify anti-virus
running.
mechanisms are:
5.4
5.3.b Examine
Examine documentation and interview personnel to
 Configured
verify that toanti-virus
security perform
policies
configurations,
automatic
and updates,
operational
including
and the
procedures
master
 installation
Configured of the periodic
to perform softwarescans. and a sample of
for protecting
system components, systems toagainst
verify malware
that the are:
anti-virus software
5.2.c Examine
pplications  Documented, a sample of system components, including
cannot
all be
operating disabled
system or altered
types by
commonly users. affected by
 In use,
5.3.c and responsible personnel and observe
Interview
malicious
 Known software,
to all affected to verify
parties. that:
processes
ged access to
 systems.
The anti-virus to verify
Many ofthat
these
software anti-virus software
vulnerabilities
and definitions are
arecannot
fixed
current. be vendor-provided security patches, which must be installed by the entities t
by
disabled or altered
 Periodic scans are performed. by users, unless specifically
authorized
5.2.d Examine by management on a case-by-case
anti-virus configurations, including basis the for a
limited
master time period.of the software and a sample of
installation
system components, to verify that:
 Anti-virus
6.1.a Examine software
policieslog andgeneration
procedures is enabled,
to verify and that
 Logs areare
processes retained
defined in for
accordance
the following: with PCI DSS
Requirement
 To identify new 10.7.security vulnerabilities
6.2.a Examine
 To assign policies
a risk ranking andtoprocedures
vulnerabilities relatedthatto includes
security-patch
identification ofinstallationall “high risk” to verify processes
and “critical” are defined
vulnerabilities.
for:
 To use reputable outside sources for security
6.3.a
 Examine
Installation ofwritten
applicable software-development
critical vendor-supplied processes
vulnerability
to verify that information.
the processes are based on industry
security patches within one month of release.
standards
 Installation and/orallbest practices.
6.1.b
6.3.1 Examineofwritten
Interview applicable
responsible vendor-supplied
personnel
software-development and observe security
procedures
patches
processes
and within
interview to an
verify appropriate
that:
responsible time frame
personnel to (for that
verify example,
pre-
6.3.b
within Examine
three written software-development processes
months).

to New
production security
verifyExamine and/or vulnerabilities
that information custom are
application identified.
accounts,
security is included throughout user IDs
6.3.2.a
 A
and/or risk ranking
passwords written
is assigned
are software-development
removed to vulnerabilities
before an that
application
the
6.2.b lifeFor
procedures cycle.
aproduction
sample
and interviewoforsystem components and related
includes
goes
6.3.c intoidentification
Examine written ofisallresponsible
“high
released risk” personnel
and
to customers. “critical” to verify
software,
that all custom
vulnerabilities. compare thesoftware-development
application list ofcode security
changes patchesmust processes
installed
be on
to
6.4
eachverify
Examine
reviewed that
system (using software
policies
to the
eithermostapplications
and procedures
recent
manual orvendor aretodeveloped
automated the in
verifyprocesses)
security-patch
 Processes
accordance
following arewith to identify
PCI DSS.
defined: new security vulnerabilities
list,
as to verify
follows:
include usingthe following:
reputable outside sources for security
6.3.d

 Interview
Development/test
That applicable
Code changes software
critical
are developers
environments
vendor-supplied
reviewed areto separate
by individuals verify that
security
other written
from than
vulnerability
6.4.1.a
production Examine
software-development information.
network
environments documentation
processes
with access are and
implemented.
control network
in place
patches
the
device are
originating installed
configurationscode within
author, one
and month
by of
individuals
to verify that the development/test release. who areto
enforce
 All
knowledgeable separation.
applicable vendor-supplied
in separate
code-review security
techniques patches
and secure are
environments
 A separation are
of duties from
between the production
installed
coding
6.4.2 within processes
practices.
Observe
environment(s). an appropriate timepersonnel
and interview frame (forassigned
personnel example,to
the
within
 development/test
Code threeto months).
reviews ensure environments
code is developedand those assigned
assigned
6.4.1.b
to the Examine
production
development/test
access
environment. controls settings toaccording
environments and
verify thatto
secure
personnel
access coding
controls guidelines
assigned are to (see
production
in place PCI
to are DSS
environments
enforce Requirement
separation to verify
 Production
6.4.3.a
6.5).
that Observe
separation data
of (live
testing
duties PANs)
processes
is in place not
and used
between for testing or
interview
between
development.
personnel the to development/test
verify procedures environments
are and the
 Appropriate
development/test
production corrections
environments
environment(s). andinthe
are implemented place to ensure
prior
production to
 Test
production
release.
environment. data and accounts are removed
data (live PANs) are not used for testing or before a
6.4.4.a
production
development. Observe system testing
becomes processes active.and interview
 Code-review
personnel to results
verify test are
data reviewed
and accountsand approvedare removed by
 Change
6.4.3.b
management Examine control
prior aprocedures
sample
to release. of testrelateddatatotoimplementing
verify
before
security
production a patches
production
data (live and system
software
PANs) becomes
modifications
is change
not used active. are
for testing or
6.4.5.a
6.4.4.b Examine
Examine documented
a sample of data and control
accounts procedures
from
documented.
development.
and verify procedures are defined for:or updated to verify
production systems recently installed

testDocumentation
data and accountsof impact are removed before is the system
6.4.5.1
 Verify that
Documented documentation
change approval by of authorized
impact included
parties in
becomes
the active.
change control documentation
 Functionality testing to verify thatfor theeach changesampled does not
change.
adversely impact the security of the system
6.4.5.2 Verify that documented approval by authorized
 Back-out
parties procedures
is present for each sampled change.
6.4.5.b For a sample of system components, interview
responsible personnel to determine recent changes.
Trace those changes back to related change control
documentation. For each change examined, perform the
following:
6.4.5.3.a For each sampled change, verify that
functionality testing is performed to verify that the change
does not adversely impact the security of the system.
6.4.5.4 Verify
6.4.5.3.b that back-out
For custom procedures
code changes, arethat
verify prepared
all for
each sampled change.
updates are tested for compliance with PCI DSS
Requirement 6.5 before
6.4.6 For a sample being deployed
of significant into
changes, production.
examine
change records, interview personnel, and observe the
affected systems/networks to verify that applicable PCI
6.5.a Examine software-development
DSS requirements were implemented policies and
and documentation
procedures to verify that
updated as part of the change. up-to-date training in secure
coding techniques is required for developers at least
annually, based on industry best practices and guidance.
6.5.b Examine records of training to verify that software
developers
6.5.1 Examine receive up-to-date trainingpolicies
software-development on secure andcoding
techniques at least annually, including how
procedures and interview responsible personnel to verifyto avoid
common coding
that injection vulnerabilities.
flaws are addressed by coding techniques
6.5.c Verify
6.5.2include:
that Examine thatsoftware-development
processes are in placepolicies
to protect
and
applications
procedures from,
and at a minimum,
interview the
responsible following
personnel
 Validating input to verify user data cannot modify to verify
vulnerabilities:
that buffer
meaning overflows
of commands are addressed by coding
and queries. policies and techniques
6.5.3
that Examine
include: software-development
 Utilizing
procedures parameterized queries.
 Validatingand interview
buffer responsible
boundaries. personnel to verify
that
 insecure
Truncating cryptographic
input strings. storage is addressed by
6.5.4
coding Examine
techniques software-development
that: policies and
procedures and interviewflaws.
 Prevent cryptographic responsible personnel to verify
that
 insecure
UseExamine communications
strong cryptographic are addressed
algorithms by coding
and keys.
6.5.5
techniques thatsoftware-development
properly authenticate and policies and all
encrypt
procedures and interview
sensitive communications. responsible personnel to verify
that improper error handling is addressed by coding
6.5.6 Examine
techniques thatsoftware-development
do not leak informationpolicies
via errorand
procedures
messages (for andexample,
interviewby responsible personnel
returning generic to verify
rather than
that coding
specific errortechniques
details). address any “high risk”
y to web applications and application
vulnerabilities interfaces
that could affect (internal or as
the application, external):
identified in PCI DSS Requirement 6.1.
6.5.7 Examine software-development policies and
procedures and interview responsible personnel to verify
that cross-site scripting (XSS) is addressed by coding
6.5.8
techniques Examine thatsoftware-development
include policies and
procedures and interview
 Validating all parameters before inclusionresponsible personnel to verify
that
 improper
Utilizing access
context-sensitivecontrol—such as insecure direct
escaping.policies
6.5.9
object Examine
references, software
failuredevelopment
to restrict URL access, andand
procedures
directory traversal—isand interview responsible
addressed personnel
by coding to verify
technique
that
that cross-site
includes: request forgery (CSRF) is addressed by
6.5.10
coding Examine
techniques software
that ensuredevelopment policies
applications andrely on
do not
 Proper authentication
procedures and interview ofresponsible
users personnel to verify
authorization
 Sanitizing credentials and tokens automatically
input
that
submittedbrokenbyauthentication
browsers. and session management are

6.6 Not
Forexposing
addressed public-facinginternal
via coding web object references
applications,
techniques to users
ensure
that commonly that either
include:

one User
of interfaces
the following that do
methods not permit
is
 Flagging session tokens (for example cookies) as in access
place as to
follows:
unauthorized
 Examine documented
“secure” functions. processes, interview personnel,
6.7
and Examine
examine documentation
records and interview
of application securitypersonnel
assessments to

verifyNot that
exposing
security session
policies IDsandin the URL
to
 verify that public-facing web applications are reviewed
forIncorporating
—using developing
either
appropriate
and
manual maintaining time-outs
or automated secure and rotation
systems
vulnerability andof
security
session
applications IDs after
are: a successful login.
assessment tools or methods—as follows:

- AtDocumented,
least annually
 In use,
- After
ss need to know anyand changes
 Known to all affected
- By an organization thatparties.
specializes in application
security
nel, systems-and That,processes
at a minimum, must be in place to limitinaccess
all vulnerabilities based on need to know and according to job responsibilities.
Requirement
amount of data and privileges needed
6.5 are included in the assessment to perform a job.
-7.1 That all vulnerabilities
Examine written policy arefor corrected
access control, and verify
-that
That the application is re-evaluated
the policy incorporates 7.1.1 through after7.1.4
the as
corrections.
follows:

 Examine
Defining accessthe system needs configuration
and privilege settings and
assignments for
interview
each role responsible personnel to verify that an
automated
 Restriction technical
of access solution that detects
to privileged and to
user IDs prevents
least
web-based attacks (for example,
privileges necessary to perform job responsibilities a web-application
firewall)
 Assignment is in place as follows:
of access based on individual personnel’s
-job
Is classification
situated in front andoffunction
public-facing web applications to
detect and prevent web-based attacks.
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
7.1.2.a
needs toInterview
access for personnel
their jobresponsible
function for assigning
access to verify that access to
 Identification of privilege necessary privileged
for user
eachIDs roleis:to
 Assigned
perform only
theirajob to roles
function. that specifically require such
7.1.3 Select
privileged accesssample of user IDs and interview
responsible
 Restrictedmanagement
to least privilegespersonnel to verify
necessary that
to perform job
privileges assigned
responsibilities. are based on that individual’s job
7.1.4 Select aand
classification sample of user IDs and compare with
function.
7.1.2.b
documentedSelectapprovals
a sample toofverify
user IDs
that:with privileged
access
 Documented approval exists formanagement
and interview responsible the assignedpersonnel
to
7.2verify that privileges
Examine
privileges system settingsassigned andare:
vendor documentation

 Necessary
to verifyapproval
The that anforaccess
that by
was individual’s
control jobparties
function
system(s)
authorized is implemented

as
 Restricted
follows:
That to
specified least privileges necessary
the rolesto perform to job
7.2.1 Confirm
responsibilities. thatprivileges match systems
access control assigned
are in place on
the individual.
all system components.
7.2.2 Confirm that access control systems are configured
to enforce privileges assigned to individuals based on job
classification and function.
7.2.3 Confirm that the access control systems have a
default “deny-all” setting.
7.3 Examine documentation and interview personnel to
verify that security policies and operational procedures
for restricting access to cardholder data are:
omponents  Documented,
 In use, and
 Known
nsures that each to all affected
individual parties.
is uniquely accountable for their actions. When such accountability is in place, actions taken on critical data and
an attacker, and the security methods to protect user passwords at the point of entry, during transmission, and while in storage.
n and implementation of the authentication system—particularly, how frequently password attempts can be made by an attacker, and the se
g point-of-sale accounts, with administrative capabilities and all accounts used to view or access cardholder data or to access systems with
1.6 through 8.1.8 are not intended to apply to user accounts within a point-of- sale payment application that only have access to one card n
8.1.a Review procedures and confirm they define
processes for each of the items below at 8.1.1 through
8.1.8
8.1.1
8.1.b Interview
Verify thatadministrative
procedures are personnel
implementedto confirm that
for user
all users are assigned a unique ID for access
identification management, by performing the following:to system
components or cardholder data.
8.1.2 For a sample of privileged user IDs and general
user IDs, examine associated authorizations and observe
system settings to verify each user ID and privileged user
8.1.3.a Selectimplemented
ID has been a sample of with
users terminated
only in the past
the privileges
six months, and review current user
specified on the documented approval. access lists—for
both local and remote access—to verify that their IDs
8.1.4 Observe
have been user accounts
deactivated to verify
or removed fromthat any
the inactive
access lists.
accounts over 90 days old are either removed
8.1.3.b Verify all physical authentication methods—such or
disabled.
as, smart cards, tokens, etc.—have beenprocesses
returned orfor
8.1.5.a Interview personnel and observe
deactivated.
managing accounts used by third parties to access,
support, or maintain system components to verify that
8.1.6.a
accounts For a sample
used of system
for remote access components,
are: inspect
system configuration
 Disabled when not in use settings to verify that authentication
parameters
 Enabled are set
only when to needed
require that user
by the accounts
third party, be
and
8.1.7
locked For
outaafter
sample not of system
more than components,
six invalid inspect
logon attempts.
disabled
system when not in use.
configuration settings to verify
8.1.6.b
Allowing Additional
vendors testing
to have procedure
24/7that
access forthat
into
password
service provider
youraccount
network
parameters are
assessments set
only: to require
Review internal once a user
processes and to is
8.1.5.b
8.1.8
locked Interview
For a
out, sample
it personnel
remains of system
locked and observe
components,
for a minimum processes
inspect
of 30 minutes
customer/user
verify
system that documentation,
third-party
configuration remote and
settingsaccess
toresetsobserve
verifyaccounts implemented
are
thataccount.
or until
processesa system
to verifyadministrator
that non-consumer the
customer
monitored while
system/session being
idle timeused.
out features have been user
set to 15
accounts
8.2 To are
verify
minutes or less. temporarily
that users locked-out
are authenticatedafter not
usingmore thanID
unique
six invalid
and access
additional attempts. (for example, a
authentication
password/phrase) for access to the cardholder data
environment, perform the following:
 Examine documentation describing the authentication
method(s) used.
 For each type of authentication method used and for
each type of system component, observe an
authentication to verify authentication is functioning
8.2.1.a Examine vendor documentation and system
configuration settings to verify that passwords are
protected with strong cryptography during transmission
8.2.2 Examine authentication procedures for modifying
and storage.
authentication
M credentials and observe security
personnel
8.2.1.b to
Foraasample verify
sample that, if a usercomponents,
ofsystem
system requests a reset examine of an
8.2.3a For
authentication credential of by passwords
phone,components,
e-mail, web,inspect or other
password
system files to verify
configuration settings that to verify are
that userunreadable
non-face-to-face
during storage. method, the user’s identity is verified
password/passphrase
before the authentication parameters
credential areis set to require at
modified.
8.2.1.c
least theFor
8.2.4.a a sample
following of system components, examine
strength/complexity: inspect
data
system transmissions
configuration to verify
settings
 Require a minimum length of at least seven characters.thatto passwords
verify that are
user
unreadable
password/passphrase
 Contain during
both numerictransmission.
parameters
and alphabetic are set to require
characters.
8.2.5.a
8.2.1.d
users For
toAdditional
change a sample testing
passwords of system
procedure components,
at least for
once service
every obtain
provider and
90 days.
8.2.3.b
inspect Additional
system testing
configuration procedure
settingsfor for service
tofiles
verify provider
that
assessments
8.2.4.b
assessments Additional only: Observe
testing
only: Review password
procedure
internal service
processes to verify
provider
and that
password
non-consumer
assessments parameterscustomer
only: arepasswords
Review set to require
internal are
processesthat new
unreadable and
customer/user
8.2.6 Examine
passwords/passphrases documentation
password procedures
cannot to verify
be andthat
the that: non-
observe
same as the four
during
consumer
security storage.
customer/user customer
personnel documentation
topasswords/passphrasesto
verify that first-timeverify are required
previously
8.2.1.e
 Non-consumer used passwords/passphrases.
Additional testing
customer procedure
user for service
passwords/passphrases provider
to meet
8.2.5.b at least
passwords/passphrases
Additional the following
testing for new
procedurestrength/complexity:
users, and reset
for service provider
assessments
are
 required
Require a
passwords/passphrases toonly:
change
minimum Observe
length
for data
periodically;
of
existingat transmissions
and
leastusers, seven are to verify
characters.
assessments
that
 non-consumer
Non-consumer only:customerReview
customer internal
passwords
users areprocesses
given are and to aas
set
unreadable
guidance
 Contain
unique
customer/uservalue both for numeric
each user
documentation andand alphabetic
tochanged
verify that characters.
afternew first
non-use.
during
to when, transmission.
and under what circumstances,
consumer
8.3.1.a customer
Examine
passwords/passphrases networkusermust passwords/passphrase
and/or system configurations,
change. cannot
be applicable,
as the same astothe verifyprevious
multi-factorfour passwords.
authentication is
required for all non-console administrative access into
8.3.2.a
the CDE. Examine system configurations for remote access
servers and systems
8.3.1.b Observe a sample to verify multi-factor authentication
of administrator personnel
is required
login to the for:
CDE and verify that at least two of the three
8.4.a
 Examine
All remote procedures
access and interview
by personnel, both user personneland to
authentication
verify that methods
authentication are used.
policies and procedures are
administrator, and
distributed
 to
All third-party/vendor all users. remotecomponents,
access (including access
8.5.a
8.4.b For a sample
Review of system
authentication policies andfor examine
procedures user
to
ID applications
lists to verify and
the system
following: components support orthat
are distributed
maintenance to users
purposes). and verify they include:

 Generic
Guidance user IDs are disabled
on selecting strong or removed.
authentication
8.3.2.b
8.5.1
 Shared Observe
Additionaluser IDsa sample
testingfor system of personnel
procedure for service
administration (for example,
provider
activities
credentials
users and
assessments administrators)
only: Examine connecting
authentication remotely policiesto theand
and
 other critical
Guidance for howfunctions
users do not exist.
should protect their
network
procedures
 Shared and verify
and
and generic that
interview at least
personnel
user IDs two ofto
are not usedthe
verifythree to different
that
authentication
8.6.a Examine
authentication credentials.
authentication
methods
credentials areare policies
used.used forand access procedures
to each to
administer
 Instructions
verify any
that procedures system
for usersfornot components.
to reuse
using previously used
authentication
customer.
8.5.b Examine authentication
passwords
mechanisms such as physicalpolicies securityand tokens,procedures
smart to
verify
8.7.a that
Review
 Instructions
cards, use of
database
and certificates group
to change and shared
application
arepasswords
defined and IDs and/or
configuration
if there
include: passwords
is any
or other authentication
settings
suspicion
 and
Authentication theverify
password that methods
mechanisms all users
could be
areare explicitlytoprohibited.
authenticated
compromised.
assigned an prior to
8.5.c
access.
8.4.c Interview
Interview
individual account system
a sample administrators
of
and not shared users to to
verify verify
among multiple that that
they group
are
8.8 Examine
and
Withoutshared userIDs documentation
and/or passwords
authentication and
for interview
access orandother personnel
authentication
toprocedures.
databases to
and
familiar
accounts.
verify with
thatare authentication
security policiesfor policies
and operational procedures
methods
applications,
 Physical not
the
and/or distributed,
potential
logical even if
unauthorized
controls are requested. or
defined to ensure malicious
for identification
access increases, and and authentication
such access are:
cannot be logged
only
 the
Documented, intended account can use that mechanism to
since
gain the
access. user has not been authenticated and is
 In use, not
therefore andknown to the system. Also, database
8.6.b
 Known Interviewto allfor security personnel
affected parties. to verify authentication
a provides the access
mechanisms should
opportunity are be granted
individuals
assigned through
to toanaccess programmatic
account devices
and not or shared
data and to remove systems or hardcopies, and should be appropriately restr
refers to all .methods
paper and only (for
electronic
among multiple accounts. example,
media through
containing stored procedures),
cardholder data.
rather
8.6.c than
Examine via direct access
system configuration to the database
settingscontrols by end
and/or for
9.1
users Verify
(except the existence
for DBAs, of
whophysical
maytoneed security direct access to
physical
each controls,
computer as applicable, verify that controls are
the database
implemented forroom,
to their data
ensure only
center, and
administrative
the intended
other physical
duties). account can
areasExamine
8.7.b with systems database in theand cardholder
application dataconfiguration
environment.
use
9.1.1.a
 thatVerify
Verify mechanism
that that
access eitherto controlled
is gain
video access.
cameras
withto, or access
badge readers control
or
settings
mechanisms to verify
(or that
both) all
are user
in access
place to user
monitor queries
the of,
other
and devices
user actions including authorized badges and lock and
entry/exit
key. points toonsensitive (for example, areas.move, copy, delete),
the
9.1.2 database
9.1.1.b Interview
Verify are through
responsible
that either programmatic
personnel
video cameras and methods
or observeonly
access control
 Observe
(for example,
locations of apublicly
system
through administrator’s
stored
accessible procedures).
network attemptjacks totolog into
verify
mechanisms
consoles for (or
randomly both) are protected
selected systems from intampering
the cardholderor
8.7.c
that Examine database access
physical and/or logical controls are in place to restrict
disabling. control settings and
data
9.1.3
database
access environment
Verify that
to application
publicly and
physical verify
accessible access
configuration that they
to
network are
wireless
settings
jacks.to“locked”
access to
verify that
9.1.1.c
prevent
points, Verify
unauthorized
gateways, that data handheld from devices,
use. video cameras and/or
user
access direct
Restricting access
control mechanisms is to or queries
network of
jacks databases
(or
reviewed,and network
and that are ports)
datawill
is
networking/communications
restricted
prevent to
malicious database individuals hardware,
administrators.from plugging into readily
stored
9.2.a for
Review
telecommunication at least
documentedthree
linesand months.
is processes
appropriately to verify
restricted. that
8.7.d
availableExamine
procedures aredatabase
network jacks
defined access
for gain control
identifying access and settings,
into internal
distinguishing
database
network application
resources.
between onsite personnel and visitors. configuration settings, and the
related
Whether application
logical or IDs
physical
 Verify procedures include the following: to verify that
controls, application
or a combination IDs canof
only
both, be
are used
used, by the
they applications
should be
 Identifying onsite personnel and visitors (for example, (and
sufficient not to by individual
prevent an
users
individual
assigning or otheror processes).
device
badges), that is not explicitly authorized from
being able to connect
 Changing access requirements, to the network. and
 Revoking terminated onsite personnel and expired
visitor identification (such as ID badges)
9.3.a For a sample of onsite personnel with physical
access to sensitive areas, interview responsible
personnel and observe access control lists to verify that:
9.4 Verify that
 Access to the visitor authorization
sensitive and access controls
area is authorized.
are in place as follows:
 Access is required for the individual’s job function.
9.3.b
9.4.1.a Observe
Observe personnel
procedures accessing sensitive
and interview areas toto
personnel
verify
verify that
that all personnel
visitors must beareauthorized
authorizedbefore
beforethey
beingare
granted access.
granted access to, and escorted at all times within, areas
9.3.c
whereSelect
9.4.2.a Observea sample
cardholder dataofiswithin
people recently theterminated
processed facility employees
to verify
or maintained. the use
and
of review
visitor access
badges or control
other lists to verify
identification,
9.4.1.b Observe the use of visitor badges or other the
and personnel
that do
visitors
not
are have
easily physical access
distinguishable
identification tovisitors
verify that to
fromsensitive
onsite
a physical areas.
personnel.
token badge does
9.4.3 Observe
9.4.2.b Verify leaving
that visitor badges theorfacility
other to verify visitors
identification
not
are permit
asked unescorted
to surrender access
their to physical
badge or otherareas where
identification
expire.
cardholder data or is processed
upon departure expiration. or maintained.
9.4.4.a Verify that a visitor log is in use to record physical
access to the facility as well as computer rooms and data
9.5 Verify
9.4.4.b thatthat
Verify procedures for protecting cardholder data
the log contains:
include controlsname,
 The visitor’s for physically securing all media
(including
 firmbut
TheVerify not limited and
represented, to computers, removable
9.5.1
electronic that the
media, storage
paper location
receipts, security
paper is reviewed
reports, and

at The
least onsite
annuallypersonnel
to authorizing
confirm that physical
backup media access.
storage is
faxes).
9.4.4.c
secure.Verify that the log is retained for at least three
months.
9.6 Verify that a policy exists to control distribution of
media, and that the policy covers all distributed media
including that distributed to individuals.
9.6.1 Verify that all media is classified so the sensitivity of
the data can be determined.
9.6.2.a Interview personnel and examine records to verify
that all media sent outside the facility is logged and sent
via secured courier or other delivery method that can be
9.6.3 Select a recent sample of several days of offsite
tracked.
tracking logs for
9.6.2.b Select all media.
a recent Fromofexamination
sample several daysofofthe logs
offsite
and interviews
tracking logs with responsible
forexamine
all media, personnel, verify proper
9.7 Obtain
management and authorizationtheand verify
ispolicy fortracking
obtained
details are
controlling
whenever storage
media
documented.
and maintenance of all media and verify that the policyis
is moved from a secured area (including when media
requires periodic
distributed media inventories.
to individuals).
9.7.1 Review media inventory logs to verify that logs are
maintained and media inventories are performed at least
annually.
9.8 Examine the periodic media destruction policy and
verify that it covers all media and defines requirements
for the following:
9.8.1.a
 Hard-copyInterview personnel
materials mustand examine shredded,
be crosscut procedures to
verify that hard-copy materials are
incinerated, or pulped such that there is reasonable crosscut shredded,
incinerated,
assurance theor hard-copy
pulped such that there
materials is reasonable
cannot be
9.8.2 Verifythe
assurance thathard-copy
cardholder data on cannot
materials electronic be media is
reconstructed.
rendered unrecoverable (e.g., via a secure wipe program
reconstructed.
 Storage containers used for materials that are forto be
in accordance
9.8.1.b Examine with industry-accepted
storage containers standards
used for materials
destroyed
9.9
secureExamine must
deletion, be
documentedsecured. policies
or by physically and
destroying procedures to
the media).
that contain
 Cardholder
verify information
they include: to be destroyed
data on electronic media must to verify that the
be rendered
containers
unrecoverable
 Maintaining are asecured.
(e.g.,
list ofvia a secure wipe program in
devices
9.9.1.a
accordance
 Examine
Periodically with the list ofdevices
devicestoto
industry-accepted
inspecting verify
standards
look forittampering
includes:
for secure or
 Make, model of device
deletion, or by physically destroying the media).
substitution

 Location
Training of device (for
personnel to be example,
aware ofthe address of
suspicious the site
behavior
9.9.2.a
or Examine
facility where documented
the device is procedures
located) to verify
and to report
processes aretampering
defined or substitution of devices.
 Device serial numbertoorinclude the following:
other method of unique
 Procedures for inspecting devices
identification.
9.9.3.a
 Review
Frequency training materials for personnel at point-
9.9.1.b
of-sale Selectofa inspections.
locations sample
to verify ofthey
devices
includefrom the listinand
training the
9.9.2.b
observe Interview
devices and responsible personnel
device locations toand observe
verify that the list
following:
inspection processes to verify:and interview personnel to
is
 accurate
9.10 Examine
Verifying and
the up to date.
documentation
identity of
 Personnel
9.9.1.c
verify Interview
that are
security aware
personnel
policiesofany third-party
procedures
to verify
and the
operational
persons
forlist
inspecting
of devices
procedures is
claiming
devices. to be repair or maintenance personnel, prior to
updated
for
granting when
restricting
them devices
physical
access toare
accessadded,
modify toor relocated,
cardholder
troubleshoot datadevices
are:
 All devices are periodically
decommissioned,
 Documented, etc. or return inspected for evidence of
 Not to install,
tampering and replace,
substitution. devices without
 In use, and
verification

 Known
Being awareto all affected
of suspicious parties.
behavior around devices
(for example, attempts by unknown persons to unplug or
open devices)
 Reporting suspicious behavior and indications of
urces and cardholder data
cal in preventing, detecting, or minimizing the impact of a data compromise. The presence of logs in all environments allows thorough track
es.
duals and researchers, and being introduced by new software. System components, processes, and custom software should be tested frequ
security for all personnel.
nd informs personnel what is expected of them. All personnel should be aware of the sensitivity of data and their responsibilities for protecti
sting Providers
ardholder data environment
with access to cardholder data (including shared hosting providers) must adhere to the PCI DSS. In addition, Requirement 2.6 states that s
Guidance
ernal), as well as
example of a more
Firewalls and routers are key components of the architecture that controls
entry to and exit from the network. These devices are software or
hardware devices that block unwanted access and manage authorized
access into and out of the network.
Configuration standards and procedures will help to ensure that the
organization’s first line of defense in the protection of its data remains
strong.
A documented and implemented process for approving and testing all

connections and changes to the firewalls and routers will help prevent
security problems caused by misconfiguration of the network, router, or
firewall.
Without formal approval and testing of changes, records of the changes
might not be updated, which could lead to inconsistencies between
network documentation and the actual configuration.
Network diagrams describe how networks are configured, and identify the
location of all network devices.
Without current network diagrams, devices could be overlooked and be
unknowingly left out of the security controls implemented for PCI DSS and
thus be vulnerable to compromise.
Cardholder data-flow diagrams identify the location of all cardholder data

that is stored, processed, or transmitted within the network.
Network and cardholder data-flow diagrams help an organization to
understand and keep track of the scope of their environment, by showing
how cardholder data flows across networks and between individual
systems and devices.
Using a firewall on every Internet connection coming into (and out of) the
network, and between any DMZ and the internal network, allows the
organization to monitor and control access and minimizes the chances of a
malicious individual obtaining access to the internal network via an
unprotected connection.
This description of roles and assignment of responsibilities ensures that

personnel are aware of who is responsible for the security of all network
components, and that those assigned to manage components are aware
of their responsibilities. If roles and responsibilities are not formally
assigned, devices could be left unmanaged.
Compromises often happen due to unused or insecure service and ports,

since these often have known vulnerabilities and many organizations don’t
patch vulnerabilities for the services, protocols, and ports they don't use
(even though the vulnerabilities are still present). By clearly defining and
documenting the services, protocols, and ports that are necessary for
business, organizations can ensure that all other services, protocols, and
ports are disabled or removed.
Approvals should be granted by personnel independent of the personnel
managing the configuration.
If insecure services, protocols, or ports are necessary for business, the risk
posed by use of these protocols should be clearly understood and
accepted by the organization, the use of the protocol should be justified,
and the security features that allow these protocols to be used securely
should be documented and implemented. If these insecure services,
protocols, or ports are not necessary for business, they should be disabled
or removed.
For guidance on services, protocols, or ports considered to be insecure,
refer to industry standards and guidance (e.g., NIST, ENISA, OWASP,
etc.).
This review gives the organization an opportunity at least every six months
to clean up any unneeded, outdated, or incorrect rules, and ensure that all
rule sets allow only authorized services and ports that match the
documented business justifications.
Organizations with a high volume of changes to firewall and router rule
sets may wish to consider performing reviews more frequently, to ensure
that the rule sets continue to meet the needs of the business.
It is essential to install network protection between the internal, trusted
network and any untrusted network that is external and/or out of the
entity’s ability to control or manage. Failure to implement this measure
correctly results in the entity being vulnerable to unauthorized access by
malicious individuals or software.
For firewall functionality to be effective, it must be properly configured to
control and/or limit traffic into and out of the entity’s network.
Examination of all inbound and outbound connections allows for inspection

and restriction of traffic based on the source and/or destination address,
thus preventing unfiltered access between untrusted and trusted
environments. This prevents malicious individuals from accessing the
entity’s network via unauthorized IP addresses or from using services,
protocols, or ports in an unauthorized manner (for example, to send data
they've obtained from within the entity’s network out to an untrusted
server).
Implementing a rule that denies all inbound and outbound traffic that is not
specifically needed helps to prevent inadvertent holes that would allow
unintended and potentially harmful traffic in or out.
While the running (or active) router configuration files include the current,
secure settings, the start-up files (which are used when routers are re-
started or booted) must be updated with the same secure settings to
ensure these settings are applied when the start-up configuration is run.
Because they only run occasionally, start-up configuration files are often
forgotten and are not updated. When a router re-starts and loads a start-up
configuration that has not been updated with the same secure settings as
those in the running configuration, it may result in weaker rules that allow
malicious individuals into the network.
The known (or unknown) implementation and exploitation of wireless

technology within a network is a common path for malicious individuals to
gain access to the network and cardholder data. If a wireless device or
network is installed without the entity’s knowledge, a malicious individual
could easily and “invisibly” enter the network. If firewalls do not restrict
access from wireless networks into the CDE, malicious individuals that
gain unauthorized access to the wireless network can easily connect to the
CDE and compromise account information.
Firewalls must be installed between all wireless networks and the CDE,
regardless of the purpose of the environment to which the wireless network
is connected. This may include, but is not limited to, corporate networks,
retail stores, guest networks, warehouse environments, etc.
While there may be legitimate reasons for untrusted connections to be
permitted to DMZ systems (e.g., to allow public access to a web server),
such connections should never be granted to systems in the internal
network. A firewall's intent is to manage and control all connections
between public systems and internal systems, especially those that store,
process or transmit cardholder data. If direct access is allowed between
public systems and the CDE, the protections offered by the firewall are
bypassed, and system components storing cardholder data may be
exposed to compromise.
The DMZ is that part of the network that manages connections between
the Internet (or other untrusted networks), and services that an
organization needs to have available to the public (like a web server).
This functionality is intended to prevent malicious individuals from
accessing the organization's internal network from the Internet, or from
using services, protocols, or ports in an unauthorized manner.
Normally a packet contains the IP address of the computer that originally

sent it so other computers in the network know where the packet came
from. Malicious individuals will often try to spoof (or imitate) the sending IP
address so that the target system believes the packet is from a trusted
source. Filtering packets coming into the network helps to, among other
things, ensure packets are not “spoofed” to look like they are coming from
an organization’s own internal network.
All traffic outbound from the cardholder data environment should be

evaluated to ensure that it follows established, authorized rules.
Connections should be inspected to restrict traffic to only authorized
A firewall that maintains
communications the "state"
(for example (or the status)
by restricting for each connection
source/destination
through the firewall knows whether
addresses/ports, and/or blocking of content). an apparent response to a previous
connection is actually a valid, authorized response (since it retains each
If cardholder status)
connection’s data is located within the
or is malicious DMZ,
traffic it istoeasier
trying for an
trick the external
firewall into
attacker
allowing to theaccess this information, since there are fewer layers to
connection.
penetrate. Securing system components that store cardholder data in an
Restricting
internal network the disclosure
zone thatof is internal
segregated or private
from theIP addresses
DMZ and other is essential to
untrusted
prevent a hacker “learning” the IP addresses
networks by a firewall can prevent unauthorized network traffic from of the internal network, and
using
reaching thatthe information
systemdevices to access the
component. Note:network.
This requirement is the
not Internet
intended to
Portable computing
Methods used to meet that are
the intent allowed
of this to connect
requirement mayto vary depending
apply
from to temporary
outside the storage
corporate of cardholder
firewall are moredata in volatile
vulnerable tomemory.
Internet-based
on the specific networking technology being used. For example, the
threats.
controls Use
used oftofirewall
meet functionality
this requirement (e.g.,
may personal
be firewall
different forsoftware
IPv4 or
networks
Personnel
hardware) need
helps to
to be aware
protect of andfrom
devices following security
Internet-based policies
attacks, and which
than for IPv6procedures
operational networks. to ensure firewalls and routers are continuously
could use the device to gain access the organization’s systems and data
managed
once the device to prevent unauthorized
is re-connected toaccess to the network.
the network.
The specific firewall configuration settings are determined by the
organization.
Note:
to compromise This requirement
systems. These passwordsapplies to employee-owned
and settings are welland company-owned
known by hacker communities and are easily determined via public inform
portable computing devices. Systems that cannot be managed by
corporate policy introduce weaknesses and provide opportunities that
Malicious
malicious individuals
individuals (external
may exploit. andAllowing
internal untrusted
to an organization)
systems to often use to
connect
vendor default settings,
an organization’s CDE couldaccount resultnames, and passwords
in access being granted to compromise
to attackers
operating
and other system
malicious software,
users. applications, and the systems on which they
If
arewireless
installed. networks
Because arethese
not implemented
default settings witharesufficient security and are
often published
configurations (including changing default
well known in hacker communities, changing these settings will settings), wireless sniffers
leavecan
eavesdrop
systems on the traffic, easily capture data and passwords, and easily
Thereand
enter arelessknown
attack
vulnerable
weaknesses
the
to attack.
network. with many operating systems, databases,
Even
and if a default
enterprise account
applications, is not
and intended
there are to be used,
also known changing
ways the default
to configure
In addition,
password to the
a key-exchange
strong unique protocol
password for
and older
then versions
disabling ofthe
802.11x
account will
these
encryptionsystems (Wired to fix security vulnerabilities.
Equivalent Privacy, or WEP) To help
has thosebroken
been that areand notcan
prevent
security a malicious
experts, a number individual from
of security re-enabling
organizationsthe account and gaining
render
access the
withencryption
the default useless.
password. Firmware for devices have should established
be updated to
system-hardening
support more secure protocols. guidelines and recommendations, which advise how to
correct these weaknesses.
Examples of sources for guidance on configuration standards include, but
are not limited to: www.nist.gov, www.sans.org, and www.cisecurity.org,
If server functions that need different security levels are located on the
same server, the security level of the functions with higher security needs
would be reduced due to the presence of the lower-security functions.
As stated in Requirement
Additionally, the server functions 1.1.6, there with aare lower many protocols
security levelthat maya introduce
business
may need (or have enabled by default)
security weaknesses to other functions on the same server. By considering that are commonly used by
malicious
the security individuals
needsfeatures of to compromise
different server a network.as Including thissystem
requirement
Enabling
as part ofsecurityan organization's before
configurationnewfunctions
servers
standards are partdeployed of the
and related will processes
prevent
configuration
servers being standards
installed and related
into the environment processes, with organizations
insecure can ensure
configurations.
ensures
that that
functions only
requiring the necessary
different services
security and
levelsand protocols
don’t are
co-existare enabled.
on the same
Ensuring that all insecure services, protocols, daemons
server.
System
adequately secured with appropriate security features makes itspecifically
configuration standards and related processes should more
address
difficult for security
malicious settings and parameters
individuals to take advantage that haveofknown commonly security used
implications
points of for each type
compromise within of asystemnetwork. in use.
Unnecessary
In order functions canconfigured
provide additional securely,opportunities for malicious
Refer
individuals to for
industrysystems
gainstandards
to and/or
to be
access toand best practices
a system. By removing
personnel
for information
unnecessary
responsible
on strong for
configuration
cryptography administering
and secure protocols systems
(e.g., must
NIST SPthe be knowledgeable
800-52 and SP in the
functionality,
specific security organizations
parameters canand focus
settings on securing
that apply to functions
the system. that800-57,
are
OWASP,
If non-console
required etc.).reduce
and (including the risk remote) administration
that unknown functions doeswill notbe use secure
exploited.
authentication and encrypted communications,
Including this in server-hardening standards and processes addresses the sensitive administrative or
operational
specific securitylevel information
implications (like administrator’s IDs and passwords) can
Maintaining
be revealed a current list of allassociated
system with unnecessary
components will enable functions
an this(for
example,
organization by to to
an eavesdropper.
removing/disabling
accurately and
A malicious
FTP
efficiently or the definewebindividual
server
the scope
could
if theof
use
server
their will not
information
be performing to access
those the network, become administrator, and steal data.
functions).
environment
Clear-text for implementing
protocols (such as of PCI DSS
HTTP, telnet, controls.
etc.) doWithout
notpolicies an inventory,
encrypt traffic or
Personnel
some system need to be
components aware could and be following
forgotten, security
and be inadvertently and daily
logon
operational details, making
procedures it easy for an
to ensureconfiguration eavesdropper
vendor defaults to intercept
and other security this
excluded
information. from the organization’s standards.
parameters are continuously managed to prevent insecure configurations.
To
This beisconsidered
intended for “strong
hosting cryptography,”
providers thatindustry-recognizedprovide shared hosting protocols with
appropriate key
environments forstrengths
multiple clients and key onmanagement
the same server. should When be inallplacedata as is on
applicable
the same server for theand typeunder of technology
control ofina use. single (Refer to "strongoften the
environment,
cryptography”
settings on these in the sharedPCI DSS servers andare PA-DSS Glossary ofbyTerms,
not manageable individual clients.
Abbreviations,
This allows clients and to Acronyms,
add insecure and functions
industry standards and scripts and that bestimpactpracticesthe
such
security as ofNIST all otherSP 800-52 client and SP 800-57,and
environments; OWASP,thereby etc.)
make it easy for a
malicious individual to compromise one client's data and thereby gain
access to all other clients' data. See Appendix A1 for details of
requirements
on. If an intruder circumvents other security controls and gains access to encrypted data, without the proper cryptographic keys, the data is
cating cardholder data if full PAN is not needed, and not sending unprotected PANs using end-user messaging technologies, such as e-mai
phy” and other PCI DSS terms.
A formal data retention policy identifies what data needs to be retained,
and where that data resides so it can be securely destroyed or deleted as
soon as it is no longer needed.
Sensitive
The only cardholderauthentication datadata that consists
may be stored of full track after data,
authorizationcard validation is the
code or value, and PIN data.
primary account number or PAN (rendered unreadable), expiration Storage of sensitive authentication data date, after
authorization
cardholder name, is prohibited!
and service This data is very valuable
code.individuals who obtain that data can to malicious
If full track data
individuals as itwhere is stored,
allows them malicious
to generate counterfeit payment cards andbe
Understanding
use it to reproduce paymentcardholder cards dataandiscompletelocated is necessary
fraudulent so it can
transactions.
create fraudulent transactions.
properly retained or disposed of when no longer needed. In order to define
Entities
appropriate
The that retention
purpose issue
of thepayment cardrequirements,cards orcode
validation thatentity
an perform
is to first
protect or
needs support issuing
to understand
"card-not-present"
services will
their own business needs
transactions—Internet often create and
or mailas well control sensitive
as any legal or
order/telephone authentication
orderregulatory
(MO/TO) data
obligations as part
transactions that
of the
apply issuing
to their function.
industry,
—where the consumer and the card are not present. It
and/oris allowable
that apply for companies
to the type ofthatdata perform,
being facilitate,
retained.
or support
These
Identifying
If this values
data issuing
and should
is stolen, deletingservices
bestored
maliciousknown to store onlysensitive
data
individuals to the
that has card
can authentication
owner or
exceeded
execute itsbank data
specified
fraudulent that ONLY issued
Internet IF
they
the
retention
and have
card.
MO/TO If a
period legitimate
this data is business
stolen, need
malicious to store
individuals
prevents unnecessary retention of data that is no longer
transactions. such data.
can execute fraudulent
It should This
PIN-based
needed. bedebit noted
process thatmay
transactions all PCI be(for DSS requirements
example,
automated orATMmanual apply or atocombination
withdrawals). issuers, andofthe
The
only display
exception of fullfor PAN
issuers on anditems suchprocessors
issuer as computer is screens,
that sensitivepayment card
both.
receipts, For faxes,
example, or a programmatic
paper reports can procedure
result in (automatic
this data being or manual)
obtained toby
authentication
locate and remove data data may and/or be retained a manual if there reviewis a legitimate
of data reason
storage areasto do so.
unauthorized
A legitimate individuals
reason is one and thatused fraudulently.
is(databases,
necessary for Ensuring
the performance that fullof PAN the is
could
PANs
only be performed.
stored
displayed in primary
for those for storage
withthe a legitimate or
business flat files
need such as
to see the Any text files
full PAN
function
Implementing
spreadsheets) being secure provided
as well deletion
as non-primary issuer and
methods ensure
storage not one thatofaccess
(backup, theconvenience.
data
audit cannot
logs, be
minimizes
such datawhen the
must riskbe of unauthorized
stored securely persons
andRemember,
in gaining
accordance with to PAN
all PCI data.
DSS
retrieved
exception
The masking or it is
troubleshooting
approach no longer
should needed.
logs) must all be protected.if you don't need it,
and
The
don't
One-way specific
intent
store of
it!
hash payment
this functions brand
requirement based isalways
requirements.
to address
on strong
ensure thethat
cryptography
only the minimum
acceptability can beof disk-level
used to
number
For
encryption of digits
non-issuing for rendering is displayed
entities, retaining
cardholderas necessary
sensitive
data to performDisk-level
authentication
unreadable. a specific
data post- business
encryption
render
function. cardholder
For entire example, data unreadable.
if only theon Hash
lasta four functions
digits and are
are needed appropriate
to perform when a
authorization
encrypts
there is no the need is not tomask permitted.
disk/partition
retrieve computer automatically decrypts
business
Cryptographic
the informationfunction, keys
when mustan bethe
the PAN original
strongly
authorized souser that number
individuals
protected
requests
(one-way
because
it. performing
Many
hashes
those that
who are
disk-encryption obtain
irreversible).
function
access can
will It able
beview is recommended,
only the lastsystem
to decrypt four
data. butdigits.
not currently
As another
Key-encrypting a keys,
requirement,
example,ifand
used, if athat anbe
function
must
solutions
additional, intercept
random operating
input value be added read/write
to the operations
cardholder data carry
prior out
to
needs
at
the least access
as strong
appropriate tocryptographic
theas bank identification
the data-encrypting transformations number
key inwithout (BIN) to
order for
any routing
ensure
special purposes,
properaction by
hashing
entity
unmask
protection to of
being
only reduce
assessed
the
the BIN
key thethat feasibility
is
digits aencrypts
service of provider.
(traditionally an attacker
the the
data first
as comparing
wellsix digits)
as the the
during
data data against
that
encrypted
the
(and user other
deriving
Maintaining than
the PAN
current supplying a password
from) tables of pre-computed
documentation or pass
the cryptographic phrase
hash upon
values.
architecture system
function.
with
startup that key.
oran at the beginning
The
enables
This
The intent
requirement
requirement ofentity
truncation to protect
relates
to istotoof
understand a session.
permanently
protection
keys the
from of
Based
algorithms,
PANremove
disclosure
on athese
segment
protocols,
displayed
and misuse
characteristics
on and of PAN paper
screens,
applies data
to
of
disk-level
so that
cryptographic only encryption,
a portion
keys used to be
(generally
to compliant
protect not to with
exceed
cardholder this data,
requirement,
the firstas six
well andthe
as method
last
the four
devices
receipts,
both
cannot: printouts, etc.,
data-encrypting keys and and is not to be confused
key-encrypting keys. with Requirement
Because one key- 3.4 for
digits)
that
protection
encrypting of the
generate, of
key PAN
PANuse
may isand
whenstored.
grant protect
stored
access the
in keys.
files,
to many This
databases, allows
data-encrypting etc. an entity keys, to keep
the pace
key-
1)
An
withUse
index thetoken
evolving same is
threats user
a to account
cryptographic
their authenticator
architecture,token that as the them
replaces
enabling operating
the toPANplansystem,
based
for or a
on
encrypting
2) Use a keys require
decryption key strong
that is protection
associated measures.
with or derived from the
given index
updates as the for an unpredictable
assurance levels value. provided A one-time
by different padalgorithms/key
is a system in
system’s
which
strengths local
a randomly
changes. usergeneratedaccount
Maintaining database
private
suchkey or isgeneral
used only
documentation network oncelogin
also credentials.
to encrypt
allows an entity a
Full
message
to disk encryption
detect thator
lost thenhelps
is missing decrypted
keysto protect
or using data in the event
a matching
key-management one-time
devices,of physicalpad
and and losskey.
identify of a
disk and therefore may be appropriate for portable devices that store
There should be very few who have access to cryptographic keys
(reducing the potential for rending cardholder data visible by unauthorized
parties), usually only those who have key custodian responsibilities.
Cryptographic keys must be stored securely to prevent unauthorized or
unnecessary access that could result in the exposure of cardholder data.
It is not intended that the key-encrypting keys be encrypted, however they
Storing
are to be cryptographic keys in
protected against the fewest
disclosure andlocations
misuse helps an organization
as defined in to
keep track and
Requirement monitor
3.5. all key locations,
If key-encrypting andused,
keys are minimizes thethe
storing potential
key- for
keys to be exposed
encrypting keys to unauthorized
in physically parties separate locations from the
and/or keys
logically
The manner in which cryptographic are managed is a critical part of
data-encrypting keys reduces
the continued security the risk ofsolution.
of the encryption unauthorized access
A good to both keys
key-management
process, whether it is manual or automated as part of the encryption
The encryption
product, is based solution must generate
on industry standardsstrong keys, as defined
and addresses in the PCIat
all key elements
DSS
3.6.1 and PA-DSS
through 3.6.8.Glossary of Terms, Abbreviations, and Acronyms under
"Cryptographic
Providing guidance Key toGeneration." Use of strong cryptographic keys
The encryption
significantly solutioncustomers
increases must
the level of
on how
distribute
security
to securely
keys of securely,
encrypted
transmit,
meaning store
cardholder
and
the data.
keys
update cryptographic keys can help prevent keys
are distributed only to custodians identified in 3.5.1, and are never from being mismanaged
or disclosedintothe
distributed unauthorized
clear. entities.
This requirement
The encryption appliesmust
solution to keys used
store keys tosecurely,
encrypt stored cardholder
for example, by data,
and any respective
encrypting them withkey-encrypting
a key-encrypting keys. Note:
key. Testing
Storing keysProcedure 3.6.a is
without proper
an additional
protection couldprocedure
provide thataccessonlytoapplies if theresulting
attackers, entity beingin theassessed
decryption is a
A cryptoperiod
service
and provider.
exposure is cardholder
of the time span during which a particular cryptographic key
data.
can be used for its defined purpose. Considerations for defining the
cryptoperiod include, but are not limited to, the strength of the underlying
Keys that are
algorithm, sizeno orlonger
lengthused
of theorkey,
needed,
risk oforkeykeys that are known
compromise, and theor
suspected
sensitivity of to the
be compromised,
data being encrypted.should be revoked and/or destroyed to
ensure
Periodic that the keys
changing can
of dual no longer
encryption bewhen
used. If such keys need to bethekept
Split
(for knowledge
example, to and
support controlkeys
archived, keys arethe
ofencrypted usedkeys
data) to have reached
eliminate
they should the
be
end
strongly
of their cryptoperiod
possibility is imperative to minimize the risk
of one person having access to the whole key. This control is of someone’s
protected.
obtaining the
applicable
The for encryption keys, and usingoperations,
manual key-management them to decrypt datakey
or where
The encryption
encryptionis solution
management solution
not
should
should provide
implemented notbyallow
the
for
forand facilitate
or accept
encryption
a process
substitution
product.
to keys
of
replace
coming keys unauthorized
from that are due for replacement
sources or or that are
unexpected known to be, or
processes.
Split knowledge
suspected of being,is a compromised.
method in which two or more people separately have
key components, where
This process will help ensure each individuals
person knows thatonly
act as their
keyown key
custodians commit
component, and the individual key components convey
to the key-custodian role and understand and accept the responsibilities. no knowledge of
the original cryptographic key.
Dual control
Personnel requires
need to betwoawareor more
of andpeople to perform
following securitya policies
function,and and no
single personoperational
documented can accessprocedures
or use the authentication
for managing the materials
secureof another.
storage of
cardholder data on a continuous basis.
Misconfigured wireless networks and vulnerabilities in legacy encryption and authentication protocols continue to be targets of malicious in
Sensitive information must be encrypted during transmission over public

networks, because it is easy and common for a malicious individual to
intercept and/or divert data while in transit.
Malicious users use free
Secure transmission and widelydata
of cardholder available
requirestools to eavesdrop
using trusted on
wireless communications. Use of strong cryptography
keys/certificates, a secure protocol for transport, and proper can help limit
encryption
disclosure
strength of sensitive
to encrypt information
cardholder data.across wireless networks.
E-mail,
Strong instant messaging,
cryptography SMS,
forrequired andConnection
authentication chat
andcan berequests from systems
easily intercepted
transmission of cardholder bydata
that do not
packet-sniffingsupport the
during delivery encryption
across strength,
internal and and
public that wouldDo
networks. result
not
is
in required
an insecureto prevent malicious
connection, shouldusers from
not PAN
be gaining access to the wireless
accepted.
utilize
network these
or messaging
utilizing tools
wireless to send
networks to unless
access theyinternal
other are configured
networks toor
Note that
Personnel
provide some protocol
needencryption.
strong to be awareimplementations (such
of and following as SSL,
security SSH v1.0,
policies and and
data.
early TLS)
operational have known vulnerabilities that an attacker can use to gain
Additionally, if an entity requests PAN via end-user messaging of
procedures for managing the secure transmission
control of
cardholder the affected
data on a system.
continuous Whichever
basis security protocol
technologies, the entity should provide a tool or method to protect these is used, ensure
itPANs
is configured to use only secure versions and configurations
using strong cryptography or render PANs unreadable before to prevent
use of an insecure connection—for example, by using only trusted
transmission.
certificates and supporting only strong encryption (not supporting weaker,
insecure protocols or methods).
Verifying that certificates are trusted (for example, have not expired and
are issued from
any business-approved a trusted
activities source)
including helps ensure
employee e-mailtheandintegrity of the
use of the securemobile computers, and storage devices, resulting in the
Internet,
connection.
oftware; however, such additional solutions do not replace the need for anti-virus software to be in place.
Generally, the web page URL should begin with "HTTPS" and/or the web
browser display a padlock icon somewhere in the window of the browser.
Many TLS certificate vendors also provide a highly visible verification seal
—sometimes referred to as a “security seal,” "secure site seal," or “secure
trust seal”)—which may provide the ability to click on the seal to reveal
information about the website.
Refer to industry standards and best practices for information on strong
There is a constant stream of attacks using widely published exploits, often
called "zero day" (an attack that exploits a previously unknown
vulnerability), against otherwise secured systems. Without an anti-virus
It is important
solution that istoupdated
protect regularly,
against ALL types
these newand forms
forms of of malicious
malicious software.
software
can attack systems, disable a network, or lead to compromise of data.
Typically, mainframes, mid-range computers (such as AS/400) and similar
systems may not currently be commonly targeted or affected by malware.
However, industry trends for malicious software can change quickly, so it is
Even the best
important anti-virus solutions
for organizations are limited
to be aware of new in malware
effectiveness if theyaffect
that might are not
maintained and kept current with the latest security
their systems—for example, by monitoring vendor security notices and updates, signature
files, or malware
anti-virus news protections.
groups to runs
determine
Anti-virus
Audit logs that continually
provide thefrom
ability and
toand iswhether
monitor unable their
to
virusmalware.
and
systems
bemalware
altered will might be
provide
activity and anti-
coming
persistent under threat
security against new
malware. evolving
malware
Trends reactions. Thus,
in malicious software it is imperative
should that
be included anti-malware solutions
in theanti-malware
identification of benew
Use of policy-based
configured to generate controls
audit on
logs alland
systems
that to ensure
these logs be managed in
security
Personnel
protectionsvulnerabilities,
need
cannot to be and methods
be aware
altered oforand to address
following
disabled new
security
will help trends
policies
prevent should
and be
system
accordance
incorporated
operational with
into Requirement
the
procedures company's
to ensure 10.
configuration
systems are standards
protected and
from protection
malware on
weaknesses from being exploited by malicious software.
mechanisms
a continuous as needed
basis.
Additional security measures may also need to be implemented for the
period of time during which anti-virus protection is not active—for example,
disconnecting the unprotected system from the Internet while the anti-virus
protection issecurity
xed by vendor-provided disabled, and running
patches, whichamustfull scan after it isbyre-enabled.
be installed the entities that manage the systems. All systems must have all approp
The intent of this requirement is that organizations keep up to date with

new vulnerabilities that may impact their environment.
Sources for vulnerability information should be trustworthy and often
There
includeisvendor a constant websites,stream of attacks
industry news using widely
groups, published
mailing list, orexploits,
RSS feeds. often
called
Once an "zero day" (an attack
organization identifies thataexploits a previously
vulnerability that could unknown
affect their
vulnerability),
environment, against
the risk of otherwise
that secured systems.
the vulnerability poses If thebemost
must recent and
evaluated
Without
patches the
are inclusion
not implemented security on during
critical the requirements
systems as soon definition, design,
ranked.
analysis, Theand organization
testing phases must of therefore
software have a methodsecurity
development, in place to a
as possible,
malicious
evaluate individual canon
vulnerabilities use anthese
ongoing exploits
basistoand attack or disable
assign risk rankings a system, or
vulnerabilities
gain access to can be inadvertently
sensitive data. or maliciously introduced into the to
those vulnerabilities.
Development,
production This is not achieved by
test and/or custom application accounts, user IDs, and
environment. an ASV scan or internal
Prioritizing
vulnerability patches
scan, forremoved
critical infrastructure ensures that high-priority
passwords
Understanding
systems and
should howrather
devices
be sensitive
are
this requires
from
data
protected isfroma process
production
handled to
theactively
bycode
vulnerabilities
before monitor
the application
application—including
as soonmay as possible
industry
becomes
when sources
stored,active for
or is
transmitted, vulnerability
released and whento information.
customers,
in memory—cansince thesehelp items
identify give
where
after
Security a
Classifying
away patch
informationtheis released.
vulnerabilities
risks
about (for in Consider
custom
example,
the functioning prioritizing
code
as are
“high,”
of the patch
commonly
“medium,” installations
application. exploited
or “low”)
Possession bysuch
allows that
of
data
securityneeds
malicious patchesto be for
individuals protected.
critical
to gain or at-risk
access systems
to a network are installed
and within
compromise 30 days,
organizations
such information to identify, prioritize,
could facilitate and address
compromise highest riskand
of the application items more
related
and
quicklyother
cardholder
cardholder and lower-risk
data.
reduce
data. patches
the likelihood are installed
that within 2-3 posing
vulnerabilities months.the greatest
Without
This
An individualproperly
requirement documented
applies to applicable
knowledgeable andexperienced
and implemented
patchesinfor change controls,
all installed
code-review security
software,
techniques
risk will
features be exploited.
including
should becould
payment
involvedbe inadvertently
applications
in the review(both orprocess.
deliberately
thoseCodethatomitted
are orshould
PA-DSS
reviews rendered
validated
be and
inoperable,
those
performed that are
byprocessing
not).
someone irregularities
other than thecould occur, or
developer of malicious
the code code
to allow could
for an
Due
be to the constantly changing state of development and test
introduced.
independent, objective review. Automated
environments, they tend to be less secure than the production tools or processes may also be
used in lieu ofWithout
environment. manualadequate reviews, but keep in mind
separation between thatenvironments,
it may be difficult or
it may
even
Reducing impossible
be possible the fornumber
theforproduction
anofautomated
personnel tool
withtoaccess
environment, identify some
andtocardholder coding
the production data, issues.
to be
Correcting
environment
compromised coding
and errors
duecardholder before
to less-stringent data the code is deployed
minimizes
security risk and helps
configurations into aand production
ensure that
possible
environment
access is
vulnerabilities limitedor released
to
in aare those
testusually to customers
individuals
or development prevents
with a the
business
environment. code
need exposing
to know. the
Security
environments
The intent controls
of thisto potential
requirement not
exploit. as
is to stringent
Faulty
separate inistest
alsoorfar
codedevelopment development
more
and difficult
test and
environments.
expensivefrom
functions Use of production
to address
production it has data
afterfunctions. been Forprovides
deployed
example, malicious
orareleased
developerindividuals
into may use withan
the opportunity
production
administrator-level to gain
environments. account unauthorized
withbe elevatedaccess to production
privileges in the data (cardholder
development
Test
data). data and accounts should removed before the system component
Including
environment, a formal review and signoff
becomes active (in production), since these items may giveaccess
and have a separate by
account management
with user-level prior to
awayrelease to the
helps
productionto ensure that
environment. code is approved and
information about the functioning of the application or system. Possession has been developed in
accordance
If
ofnot
such properly with
information policies
managed, couldand the procedures.
impact
facilitate of system changes—such
compromise of the system and as related
hardware
cardholder data. or software updates and installation of security patches—might
not be fully realized and could have unintended consequences.
The impact of the change should be documented so that all affected
parties can plan appropriately for any processing changes.
Approval by authorized parties indicates that the change is a legitimate
and approved change sanctioned by the organization.
Thorough testing should be performed to verify that the security of the
environment is not reduced by implementing a change. Testing should
validate that all existing security controls remain in place, are replaced with
For eachstrong
equally change, there or
controls, should be documented
are strengthened after back-out
any change proceduresto the in
case the
environment. change fails or adversely affects the security of an application or
system, to allow the system to be restored back to its previous state.
Having processes to analyze significant changes helps ensure that all
appropriate PCI DSS controls are applied to any systems or networks
added or changed within the in-scope environment.
The application
Building layer isinto
this validation high-risk
change and may be targeted
management processes by both internal
helps ensure and
external threats.
that device inventories and configuration standards are kept up to date and
Requirements
security controls 6.5.1
are through
applied 6.5.10 where needed.are the minimum controls that should
be in place,
A change and organizations
management processshould shouldincorporate
include supportingthe relevant securethat
evidence
coding practices as applicable to the particular
PCI DSS requirements are implemented or preserved through the iterative technology in their
environment.
process. flaws,
Injection Examples of PCI DSS
particularly SQL requirements
injection, are athat could beused
commonly impactedmethod for
Application
include, but developers
compromising areapplications.
not limited should
to: be properly
Injection occurstrainedwhen to identify and data
user-supplied resolve is
issues
 Network
sent related to these
diagram isas
to an interpreter (and
updated other)
part of to common
reflect changes.
a command or query. The attacker'sHaving
coding vulnerabilities. hostile
staff
Buffer knowledgeable
 Systems
data overflows
tricks occur
areinterpreter
the of when
configured secureperan
into coding
application
configuration
executing guidelinesdoes should
standards,
unintended notcommands
have minimize
with orthe
appropriate
all default
number
bounds
passwordsdata,
changing of security
checking
changed on vulnerabilities
and allowsits buffer
and unnecessary space. introduced
the attackerservicesThis can through
cause
to attackdisabled. poor
the coding
information
components inside the in the
practices.
buffer
 Systems to beTraining
pushed
are forout developers
of the buffer’smay be
memory providedspace in-house
and into or by third
executable
network
Applications
parties
memory
through
and
space. thatprotected
should
the
dobe
When not with required
application,
utilize
applicable
this occurs,
to initiate
strong
forthe
controls—e.g.,
technology
attacks such
cryptographic
attacker used.
has the
file-integrity
functionsas buffer
ability properly
insert to
toapplication
monitoring
overflows,
store data (FIM),
or
are toat anti-virus,
reveal
increased both patches,
confidential
risk of being audit logging.
information
compromised, and server
and exposing
As
 industry-accepted
malicious
Sensitive code at the secure
authentication end of data coding
the buffer
(SAD) practices
and
is notthen change,
stored push organizational
thatall malicious code
functionality.
authentication
coding
into practices
executable credentials
and
memory and/or
developer
space cardholder
training
by should
overflowing data. Ifand
likewise
the an attacker
buffer. beThe
cardholder
updated is able
malicious to
data
to
(CHD)
Information
Applications
exploit storage
weak should
thatis documented
be validated
fail to adequately
cryptographic andbefore
processes, incorporated
encryptbeing
they sent
network
may into
be to data-retention
the
traffic
able application—for
tousing
gain strongpolicy
clear-text
address
code
and is new
then
procedures
example, threats—for
executed and example,
often memory
enables the scraping
attacker attacks.
remote access
numerictheto
cryptography
access
The to by
vulnerabilities
application
checking
are at increased
encrypted
and/or
for all alpha
data.
identified
infected in
system.
risk of
6.5.1
characters,
being compromised
through
mix of alpha
6.5.10 provide
and and
a
exposing
minimum
 New systems
characters,
cardholder etc. are
data. If anincluded
attackerinisthe able quarterly
to exploit vulnerability
weak cryptographic scanning
baseline.
process. It they
Applications
processes, iscanup may
to the beorganization
unintentionallyable to gain leakto remain
information
control of up to
anabout date
application withconfiguration
their vulnerability
or even gain
trends
or internaland incorporate
workings,
clear-text access to encrypted data. or appropriate
expose measures
privileged into
information their secure
through coding
improper
practices.
error handling methods. Attackers use this weakness to steal sensitive
All
data vulnerabilities
or compromise identified
the system by analtogether.
organization’s vulnerability
If a malicious risk-ranking
individual can
process
create errors (defined that in the Requirement
application does 6.1) tonot behandle
“high risk” properly,and that theycouldcan gainaffect
the application
detailed should
system information, be identified
create and addressed
denial-of-service during application
interruptions, cause
Web applications,
development. both internally and externally (public) facing, have
security to fail, or crash the server. For example,
unique security risks based upon their architecture as well as the relative the message "incorrect
password provided" tells
ease and occurrence an attacker the user ID provided was accurate
of compromise.
and
XSSthat flaws theyoccurshouldwhenever focus their efforts onlytakes
an application on the password. Use
user-supplied datamore and
genericit error
sends to a web messages,
browserlike "datafirst
without could not be verified."
validating or encoding that content.
XSS allows attackers to execute script in the victim's browser, which can
A directuser
hijack object reference
sessions, defaceoccurs webwhen sites,apossibly
developer exposesworms,
introduce a referenceetc. to
an internal implementation object, such as a file, directory, database
record, or key, as a URL or form parameter. Attackers can manipulate
A CSRF
those attack forces
references to access a logged-on
other objects victim'swithout
browser to send a pre-
authorization.
authenticated
Consistently enforce requestaccess to a vulnerable
control inweb application,
presentation layer which
and then businessenables
the
logic attacker to
forauthentication perform
all URLs. Frequently, any state-changing
the only operations
way an application the victim
protects is
Secure
authorized to perform is and session
(such as updating management
account prevents
details, unauthorized
making
sensitive
individuals functionality
from compromising by preventing
legitimate the display
account of links
credentials, or URLs
keys,toor
purchases,
unauthorized orusers.
even authenticating
Attackers can to
usethe thisapplication).
weakness to access andthe
session tokens that would otherwise enable the intruder to assume
perform
Public-facing
identity of unauthorized
web applications
an authorized operations
user. arebyprimary accessing targetsthose forURLsattackers, directly.
and poorly
An attacker
coded may be ableprovide
web applications to enumerate an easy andpath navigate
for attackersthe directory to gainstructure
access
of sensitive
to a websitedata (directory
and systems.traversal) The thus gaining access
requirement to unauthorized
for reviewing applications
Personnel
or installingneed
information as to be
well as aware
web-application gaining offurther
and following
firewalls insight
is intended security
into thereduce
to policies
workings theand of the site
number of
for later exploitation.
compromises on public-facing web applications due to poor are
to ensure systems and applications codingsecurely
or
developed
If user interfaces
application and protected
management permit access practices. to unauthorized functions, this access
could
 Manual result orinautomated
unauthorized individuals
vulnerability gaining
security access to privileged
assessment tools or methods
credentials
review and/or or test
cardholder data. Only
the application for authorized
vulnerabilities users should be permitted
to Web-application
 access direct object references
firewalls filter and to sensitive resources. traffic
block non-essential Limiting access
at the
to data resources
application layer. Used will help prevent cardholder
in conjunction data from being
with a network-based presented
firewall, a
to unauthorized
properly configured resources.
web-application firewall prevents application-layer
s based on need
attacks to ifknow and according
applications to job responsibilities.
are improperly coded or configured. This can be
achieved through a combination of technology and process. Process-
based
The more solutions
peoplemust whohave havemechanisms
access to cardholder that facilitate data,timely the more responses
risk there to
alerts in order to meet the intent of this requirement,
is that a user’s account will be used maliciously. Limiting access to those which is to prevent
attacks. Note: “An
with a legitimate organization
business reason that forspecializes
the accessinhelps application security” can
an organization
be either a third-party company or
prevent mishandling of cardholder data through inexperience or an internal organization, as long as the
malice.
reviewers specialize in application security and can demonstrate
independence from the development team.
In order to limit access to cardholder data to only those individuals who
need such access, first it is necessary to define access needs for each role
(for example, system administrator, call center personnel, store clerk), the
When assigning privileged
systems/devices/data eachIDs,role itneeds
is important
accesstoto,assign
and the individuals only the
level of privilege
privileges they need to perform their job (the “least privileges”).
each role needs to effectively perform assigned tasks. Once roles and For
example, the database
corresponding access administrator
needs are roles or backup
defined, administrator
individuals should not
can be granted
Once
be needs are
assigned defined
the same for user
privileges as the(per PCIsystems
overall DSS requirement 7.1.1), it
administrator.
access
is accordingly.
easy to grant individualshelps
access according
Assigning least privileges prevent userstowithout
their job classification
sufficient and
knowledge
function
about by using the
the application already-created roles.
Documented approvalfrom(for incorrectly
example, inorwriting
accidentally changing application
or electronically) assures
configuration or altering its security settings. Enforcing
that those with access and privileges are known and authorized least privilege
by also
helps to minimize the scope of damage if an unauthorized
management, and that their access is necessary for their job function person gains
access
Withoutto a user ID. to restrict access based on user’s need to know, a
a mechanism
user may unknowingly be granted access to cardholder data. Access
control systems automate the process of restricting access and assigning
privileges. Additionally, a default “deny-all” setting ensures no one is
granted access until and unless a rule is established specifically granting
such access. Entities may have one or more access controls systems to
manage user access. Note: Some access control systems are set by
default to “allow-all,” thereby permitting access unless/until a rule is written
to specifically deny it.
Personnel need to be aware of and following security policies and

operational procedures to ensure that access is controlled and based on
need-to-know and least privilege, on a continuous basis.
r actions. When such accountability is in place, actions taken on critical data and systems are performed by, and can be traced to, known a
words at the point of entry, during transmission, and while in storage.
ularly, how frequently password attempts can be made by an attacker, and the security methods to protect user passwords at the point of e
d all accounts used to view or access cardholder data or to access systems with cardholder data. This includes accounts used by vendors a
ts within a point-of- sale payment application that only have access to one card number at a time in order to facilitate a single transaction (s
By ensuring each user is uniquely identified—instead of using one ID for
several employees—an organization can maintain individual responsibility
for actions and an effective audit trail per employee. This will help speed
issue resolution and containment when misuse or malicious intent occurs.
To ensure that user accounts granted access to systems are all valid and
recognized users, strong processes must manage all changes to user IDs
and other authentication credentials, including adding new ones and
If an employee
modifying has left
or deleting the company
existing ones. and still has access to the network via
their user account, unnecessary or malicious access to cardholder data
could occur—either by the former employee or by a malicious user who
Accounts
exploits the thatoldare not used
and/or unusedregularly areTo
account. often targets
prevent of attack since
unauthorized it is
access,
less likely that any changes (such as a changed password)
user credentials and other authentication methods therefore need to be will be noticed.
As such,promptly
revoked these accounts may be more easily exploited and used to access
in case they
cardholder need (as
data.
soon
to support asyour
possible)
systems upon the employee’s
increases the chancesdeparture.
of
unauthorized access, either from a user in the vendor’s environment or
from a malicious individual who finds and uses this always-available
Without
external account-lockout
entry point into your mechanisms
network. in place, an
Enabling attacker
access onlycan
for continually
the time
attempt to guess a password through manual or
periods needed, and disabling it as soon as it is no longer needed,automated tools (for
helps
example,
prevent password
misuse of cracking),
these until
connections. they achieve success and gain access
If
to an account
a user’s is locked
account. out Testing
Note: due to someone
Procedure continually
8.1.6.b trying to guess a
Monitoring
password, of vendor
controls toaccess
delay provides
reactivationassurance
of these thatisvendors
locked
an additional
are stops the
accounts
procedure
accessing that only applies ifnecessary
the entity and
being assessed is a service
malicious individual from continually guessing the password (theytime
provider.
only the systems only during approved will have
frames.
When
to stopusers walk awayoffrom
for a minimum an openuntil
30 minutes machine with access
the account to critical
is reactivated).
system components
Additionally, or cardholder
if reactivation must bedata, that machine
requested, the admin mayorbe used
help deskby can
others
validate in the user’s absence,
that it is the actual resulting
account in unauthorized account access
These
and/or authentication
misuse. methods, whenowner
used requesting
in addition reactivation.
to unique IDs, help
protect users’ IDs from being compromised, since
The re-authentication can be applied either at the system level the one attempting the
to protect
compromise needs toonknow
all sessions running both the unique
that machine, or at theID application
and the password
level. (or other
authentication used). Note that a digital certificate is a valid option for
“something you have” as long as it is unique for a particular user.
Since one of the first steps a malicious individual will take to compromise a
system is to exploit weak or nonexistent passwords, it is important to
implement good processes for authentication management.
Many network devices and applications transmit unencrypted, readable
passwords across the network and/or store passwords without encryption.
A malicious individual can easily intercept unencrypted passwords during
Many malicious
transmission usingindividuals
a “sniffer,” useor"socialdirectlyengineering”—for
access unencrypted example,passwords callingina
help desk and acting as a legitimate user—to
files where they are stored, and use this data to gain unauthorized access. have a password changed
so
Note:they can utilize
Testing Proceduresa user ID. 8.2.1.dConsider and use of are
8.2.1.e a “secret question” that only
Strong
the passwords/passphrases
proper userifcan answer to help are the first line ofadditional
administrators defensethe
identify
procedures
into usera network
prior to
that
since only apply
a malicious the entity
individual being assessed
will often first is a service provider.
try to find accounts with weak or
re-setting or modifying authentication credentials.
non-existent passwords. If passwords are short or simple to guess, it is
Passwords/passphrases
relatively easy for a malicious that are valid for
individual toafindlong time weak
these without a change
accounts and
provide malicious individuals
compromise a network under the guise of a valid user ID.with more time to work on breaking the
password/phrase.
This requirement Note: Testing
specifies that aProcedureminimum 8.2.4.b
of sevenischaracters
an additional and both
If password
procedure history
that only isn’tapplies maintained,
if the entity thebeingeffectiveness
assessed ofischanging
a service
numeric
passwords and is alphabetic
reduced, ascharacters
previous should
passwords be used
can for
be passwords/
reused over and
provider.
passphrases.
over. RequiringFor that cases
passwordswhere this cannot minimum
be reused cannot for be met due
a period to
of time
technical
If the same
reduces limitations,
the likelihoodentities
password is used
that canfor use
passwords every “equivalent
newhave
that user,been strength”
an internal
guessed to user,
evaluate former
or brute- their
alternative.
employee, orFor information
malicious on
individual variability
may
forced will be used in the future. Note: Testing Procedure 8.2.5.b is an knowand equivalency
or easily of
discover password
this
strength
password,
additional (also andreferred
procedure use it that totogainas
only entropy)
access
applies toforaccounts.
passwords/passphrases of
Multi-factor
different formats,authentication
refer to industry requires an ifindividual
standards
the entitytobeing
(e.g., the present assessed
current a minimum is a
version ofof
service
two provider
NIST SP 800-63.) Note: Testing Procedure 8.2.3.b is an additional 8.2),
separate forms of authentication (as described in Requirement
before
procedure access that isonly granted.
applies if to theapply entitytobeing assessed is aadministrative
service
This requirement
Multi-factor is intended
authentication provides all personnel
additional assurance with that the individual
provider.
access to the CDE.access This requirement
attempting to gain is who theyapplies claim toonly be. to Withpersonnel
multi-factor with
administrative
authentication, access
anisattacker and only
would for non-console
needtotoallcompromise access to the
at least two CDE; it does
different
Thisapply
not requirement
to application intendedor system to apply accounts personnel—including
performing automated general
authentication
users, mechanisms, increasing
administrators, and vendors (for support or maintenance) with the difficulty of compromise and
functions.
thus reducing the risk.network—where that remote access could lead to
remote
If access
the entity does tonot the use segmentation topolicies
separate the CDE from the
Multi-factor
Communicating
access authentication
to the CDE. If remote is not
password/authentication access requiredis to at both the
anmulti-factor
entity’s and system-level
procedures
network that has and
to allrest
of their
users network,
application-level
helps segmentation, an
thoseforusers administrator
a particular
understand could
system and use
component.
abide authentication
by theMulti-factor
policies.
appropriate
either when logging onto thesuch CDE that remote
network orusers
whencannot logging access
onto aorsystem.
impact
authentication
For
the example,
cardholder can
guidance
data be performed
on
environment, selecting eitherstrongupon
multi-factor authentication
passwords
authentication to
may includefor theremote
If the CDE
multiple network
particular is
users segmented
share tothe from
thesame
orpersonnel system the rest of
authentication the entity’s network,
credentials an
(for example,
suggestions
access
user to that
administrator
account
tonetwork
help
would
and need
password), wouldto use not
itthat becomponent.
select hard-to-guess
required.
multi-factor
becomes However,
authentication
impossible
passwords
tonot multi-factor
trace when
that don’t
system
Examples
contain of
dictionary
authentication multi-factor
words, technologies
and don’t include
contain but are
information limited
about toaccess
remote
the user
connecting
access and
authentication
(such as the to ais
activities
and
user
required
CDE ID, system
to
dial-in
names
for
anservice any remote
from
individual.
of a non-CDE
(RADIUS)
family This access
members, inwith
turn to
network. networks
prevents
tokens;
date of anwith
Multi-factor
terminal
birth, entity
etc.). from
access
to the This
Note: cardholder
authentication requirement data
cancontrol environment,
applies
be implemented only at and
when isthe
network recommended
entity being for all
assessed remote is a
assigning
controller
Guidance
access
service to
accountability
access
for protecting
the
provider. entity’s
for,
system or having
authentication
networks. (TACACS) effective withlevel
credentials logging
tokens;
mayor atof,and another
include individual’s
not writing
system/application
actions,
technologies
down sincethat
passwords a given level;
facilitate
or saving it multi-factor
action does
themcould not have
in have
insecure to be
been
authentication. both.
performed
files, and Ifbeing
thebyadministrator
anyone
alert for in the
To
uses
groupprevent
MFA
that the compromise
when
has logging
knowledge into ofofthe
the multiple
CDE customers
network,
authentication they through
do
credentials. not the
also use need of ato
malicious
If user set
single individuals
authentication
oflogcredentials, who may
mechanisms
vendors attemptsuch
with to exploit
as tokens,
remote accesstheir
smartpasswords
cards,toand
accounts (for
customer
use MFA to
example,
certificates bycan into
calling
be used a particular
anuse employee
bya multiple system
and or application
asking
accounts, for their
it may within
password
be the so
impossible CDE. the
to
environments should different authentication credential for each
caller
identify
customer.can
the “troubleshoot
individual usinga problem”).
the authentication mechanism. Having physical
Without
Instructing
and/or user
logical usersauthentication
to change
controls for access
passwords to databases
if there is that and
a chance applications,
theaapassword theis
Technologies,
potential for such
unauthorized as (for or
example,
multi-factor
malicious
a PIN,
mechanisms,
access
biometric
increases,
data,
provide and
or password)
unique
such access
no
to longer secure
uniquely
credential for eachcan
identify theprevent
user ofmalicious
connection the
(for account
example, users will
viafrom
prevent using
a single-use a legitimate
unauthorizedpassword) users
cannot
password
from be to
gaining logged
gain
access since
unauthorized the user
through use has
access.
of a not
sharedbeen authenticated
authentication and
mechanism. is
could
thereforealso
Personnelnot meet
need known the intent
to betoaware of
the system. this requirement.
of andAlso, following database security policies
access shouldand be
operational
granted through procedures
programmatic for managing methods identification
only (for example, and authorization
through stored on a
continuous basis
procedures), rather than via direct access to the database by end users
(except for DBAs, who may need direct access to the database for their
administrative duties).
or data and to remove systems or hardcopies, and should be appropriately restricted. For the purposes of Requirement 9, “onsite personne
der data.
Without physical access controls, such as badge systems and door
controls, unauthorized persons could potentially gain access to the facility
to steal, disable, disrupt, or destroy critical systems and cardholder data.
When
Locking investigating
console login physical
screensbreaches,
preventsthese controls can
unauthorized help from
persons identify the
gaining
individuals that physically accessed the sensitive areas,
access to sensitive information, altering system configurations, introducing as well as when
they entered and
vulnerabilities intoexited.
the network,jacks
or destroying records.
Restricting access
Criminals attempting to to
network
gain physical(oraccessnetwork ports) willareas
to sensitive prevent will often
malicious individuals from plugging into readily available
attempt to disable or bypass the monitoring controls. To protect these network jacks and
gain access
controls from into internal network
tampering, video resources.
cameras could be positioned so they are
Without
Whether security
logical over
or access
physical to wireless
controls, or acomponents
combination and devices,
of both, are used,
out of reach
malicious and/or
users be monitored
could usetoan to detect
organization’s tampering.
unattended Similarly,
wireless access
they should
control be sufficient
mechanisms could be prevent an individual
monitored or have or device
physical that is devices
protectionsnot
to access
explicitly network
authorized resources,
from being or even
able toconnect
connect their
to own
the devices
network. to the
installed
Identifying to authorized
prevent
wireless network to them
gain beingsodamaged
visitors they are
unauthorized or disabled
easily
access. by malicious
distinguished
Additionally, from onsite
securing
individuals.
personnel prevents unauthorized visitors from being
networking and communications hardware prevents malicious users from granted access to
Examples
areas ofnetwork
containing
intercepting sensitive areas
cardholder
traffic include
ordata.
physicallycorporate database
connecting server
their own rooms,to
devices
back-office
wired network rooms at retail locations that store cardholder data, and storage
resources.
areas for large quantities of cardholder data. Sensitive areas should be
identified by each organization to ensure the appropriate physical
monitoring controls are implemented.
Controlling physical access to sensitive areas helps ensure that only
authorized personnel with a legitimate business need are granted access.
When personnel leave the organization, all physical access mechanisms
Visitor
should controls are important
be returned topromptly
or disabled reduce the(asability
soon of
asunauthorized
possible) upon and
their
malicious persons to gain access to facilities (and potentially, to
departure, to ensure personnel cannot gain physical access to sensitive cardholder
data).
areas once their employment has ended.
Visitor controls ensure visitors are identifiable as visitors so personnel can
monitor their activities, and that their access is restricted to just the
duration of their legitimate visit.
Ensuring that visitor badges are returned upon expiry or completion of the
visit prevents malicious persons from using a previously authorized pass to
gain physical access into the building after the visit has ended.
A visitor log documenting minimum information on the visitor is easy and
inexpensive to maintain and will assist in identifying physical access to a
building or room, and potential access to cardholder data.
Controls for physically securing media are intended to prevent

unauthorized persons from gaining access to cardholder data on any type
of media. Cardholder data is susceptible to unauthorized viewing, copying,
If
orstored
scanning in aifnon-secured
it is unprotectedfacility, backups
while it is onthat contain or
removable cardholder data
portable media,
may easily be lost, stolen, or
printed out, or left on someone’s desk. copied for malicious intent.
Periodically reviewing the storage facility enables the organization to
Procedures
address identified and processes help protect
security issues cardholder
in a timely manner, data on mediathe
minimizing
distributed
potential risk. to internal and/or external users. Without such procedures data
can be lost or stolen and used for fraudulent purposes.
It is important that media be identified such that its classification status can
be easily discernible. Media not identified as confidential may not be
adequately protected or may be lost or stolen. Note: This does not mean
Media mayneeds
the media be losttoorhave
stolen if sent via a non-trackable
a “Confidential” label attached; method suchisas
the intent that
regular postal mail.
the organization hasUse of secure
identified couriers
media to deliver
that contains any media
sensitive datathat
so it can
contains
protect it.acardholder data allows organizations to use their tracking systems
Without
to maintain firm processand
inventory for location
ensuringofthat all media movements are
shipments.
approved before the media is removed from secure areas, the media
would not be tracked or appropriately protected, and its location would be
Without
unknown, careful
leading inventory methods
to lost or and storage controls, stolen or missing
stolen media.
media could go unnoticed for an indefinite amount of time.
If media is not inventoried, stolen or lost media may not be noticed for a
long time or at all.
If steps are not taken to destroy information contained on hard disks,

portable drives, CD/DVDs, or paper prior to disposal, malicious individuals
may be able to retrieve information from the disposed media, leading to a
data compromise. For example, malicious individuals may use a technique
known as “dumpster diving,” where they search through trashcans and
recycle bins looking for information they can use to launch an attack.
Securing storage containers used for materials that are going to be
destroyed prevents sensitive information from being captured while the
materials are
Criminals attempt beingtocollected.
steal cardholder For example, data by“to-be-shredded” containers
stealing and/or manipulating
could have a devices
card-reading lock preventing
and terminals.access For to its contentsthey
example, or physic
will tryally prevent
to steal
access
devicesto sothethey inside
can of thehow
learn container.
to break into them, and they often try to
Keeping
Examples
replace anofup-to-date
legitimatemethods devices listsecurely
for of
withdevices helpsdevices
destroying
fraudulent anelectronic
organization media
that send keep
them track
include
paymentof
where
secure
card devices are
wiping, degaussing,
information supposed
every time a to
orcard be,
physical and quickly
destruction
is entered. identify if
(suchwill
Criminals a device
as also
grinding is
try tooradd
missing
shredding
“skimming” or hard
lost. disks).
components to the outside of devices, which are designed to
Regular
The method inspections of devices
for maintaining willofhelp
a before
list organizations
devices may to more quickly
be automated (for
capture
detect payment
tampering card details
or replacement system) they
of a device, even enter
and therebythe device—for
minimize the
example,
example, a
bydevice-management
attaching anfraudulent
additional devices. or manual
card reader (forofexample,
on top the legitimate
potential impact
documented in of using
electronic or paper records). For on-the-road devices, the
card
The reader
Criminals
type ofwillsooften
that pose
inspection thewillpayment
asdepend card
authorized details are captured
maintenance
on personnel
the device—for personnel
example,twice: inonce
order byto
location
the
gain accessmay
criminal’s include
to component
POS the
devices.name
and Allof
then the
by
third the device’s
parties to whom
legitimate
requesting the
access device
component.
to is
devices
photographs
assigned. of devices that are known to be secure can be used to
In this way,
should
compare always
a transactions
device’sbe verified
current maybeforestill being
be completed
appearance provided
with its without interruption
access—for
original example,
appearance while
to by
see
Personnel
the criminal
checking need
with is to be
“skimming”
management aware the ofpayment
or and following
phoning card
the security
information
POS policies
during
maintenance and
the
company
whether
operational it has changed.
procedures Another
for restricting option may be
physical accessto use a secure marker
process.
(such
pen, as the
such as vendor
a UV on or acquirer)
light marker, to formark
verification. Many to
device surfaces
cardholder
criminals
and device
data
will try to
and personnel
This
fool CDE systems
requirement by is a continuous
recommended,
dressing for the basis.
but
part not
(for required,
example, for manual
carrying key-entry
toolboxes
openings so any tampering or replacement will be apparent. Criminals will
components
and replacesuch
oftendressed intheworkas wear),
outer computer
casing andofkeyboards
could
a device and
alsoto POS
behide keypads.
knowledgeable
their tampering, about and
Additional
locations ofbest practices
devices, so on
it’s skimming
important
these methods may help to detect such activities. Device vendors prevention
personnel are
are available
trained to on may
follow the PCI
SSC website.
procedures at all times.
also be able to provide security guidance and “how to” guides to help
Another
determine trick criminals
whether the like
device to use hasisbeen to send a “new”with.
tampered POS system with
instructions
The frequency for of swapping
inspections it withwilla depend
legitimate on system
factors and
such“returning”
as locationthe of
legitimate system to a specified address.
device and whether the device is attended or unattended. For The criminals may even provide
example,
data compromise. The presence of logs in all environments allows thorough tracking, alerting, and analysis when something does go wrong.
are. System components, processes, and custom software should be tested frequently to ensure security controls continue to reflect a chan
nel should be aware of the sensitivity of data and their responsibilities for protecting it. For the purposes of Requirement 12, “personnel” refe
roviders) must adhere to the PCI DSS. In addition, Requirement 2.6 states that shared hosting providers must protect each entity’s hosted e
Evidence of
Control Exists: Control is Executed Correctly:
Yes or No Comments
See Below See Below
The firewall and router configuration standard (can be in the Documentation (firewall and router configuration)
network standard) must include: provides for the "life cycle" cradle-to-grave, of
• The formal process for testing and approval (lifecycle) of firewall rules and router connections. And, there
each network connection and firewall and router configuration. is in place, via document or automation,
documentation and formal approval of each
There exists the formal "tracking" of the introduction and/or network connection and the firewall and router
changes to network connections and changes to the firewall configuration.
and router configuration. This can exist through automation
(Service Now) or tracked in microsoft suite.
Provide the network diagram(s) that illustrate the location of all The configuration document matches with the
network hardware. Can be cross referenced against the network diagram.
firewall and network configuration.
Note, this is a separate document from the network diagram. it Data flow diagram is coherent: diagram is
must clearly illustrate the movement of credit card data within supported with appropriate verbiage to accurately
the cardholder data environment (app, os, network, database explain the data flow.
tiers). Nothing can be taken for granted. These must be in
great detail complete, with ports, protocols, encryptions, etc.
The firewall and router configuration standard (can be in the The provided documentation must provide the
network standard) must include: assurance of the firewall requirement AND that
• The requirement for a firewall at each internet connection, the firewall is in place. The network diagram must
includes the DMZ and internal network zones. clearly illustrate this requirement.
• Testing of all firewall configuration changes
• Approval of all firewall configuration changes
The firewall and router configuration standard (can be in the Network security team and the network security
network standard) must include: manager understand their roles regarding the
• A description of groups, roles, and responsibilities for logical ongoing management and approval of the router,
management of network components. This formal assignment port and protocol inventory.
ensures that the network administrator(s) and the network
security manager understand their roles and that they have an
understanding of the network inventory.
The firewall and router configuration standard (can be in the The firewall and router configuration standard
• Minimum guidance for the network lifecycle on tracking, secure and "approved" insecure network
cradle-to-grave, each of the network services, protocols and services, protocols and ports.
ports.
• The identification of "approved: insecure services, protocols
and ports. List compensation controls to overcome their
insecurities.
There exists the formal "tracking" of the introduction and/or

changes to each of the network services, protocols and ports.
This can exist through automation (Service Now) or tracked in
microsoft suite.
network standard) must include: provides for the review of the firewall and router
• The requirement to review the firewall and router rule sets, as rules set to occur every six months as a
a minimum, every six months. minimum.
There exists the formal "tracking" of the review of the firewall

and router rule sets that occure every six months.
See Below See Below
• All inbound and outbound traffic necessary for the cardholder ensuring all inbound and outbound traffic is
data environment. understood and has a justification.
• Note-limit traffic to minimum necessary-every concession
must have a legitimate requirement.
• Default rule must be an implicit "deny."
The firewall and router configuration standard (can be in the Requirement is effectively communicated in the
network standard) must include: firewall and router configuration standard, the
• Minimum guidance for ensuring router configuration files are current file is stored with only authoraiced access,
secure from unauthorized access. synchronized and can be tested at any time.
• And that the latest file is synchronized (running). The latest
file must be the start-up file.
• Minimum guidance for the network lifecycle on tracking, secure and "approved" insecure network
cradle-to-grave, each of the network services, protocols and services, protocols and ports.
ports.
insecurities.
There exists the formal "tracking" of the introduction and/or

changes to each of the network services, protocols and ports.
This can exist through automation (Service Now) or tracked in
microsoft suite.
See Below See Below

The firewall and router configuration must: The firewall and router configuration ensures the
• Provide a DMZ that limits inbound traffic to system DMZ is used to limit inbound traffic for only
components that provide only authorized publicly accessible publicly accessible services and ports AND the
services, protocols and ports. inbound traffic is limited to only IP addresses
• Limit inbound internet traffic to only IP addresses within the within the DMZ.
DMZ.
hacker communities and are easily determined via public information.

crypted data, without the proper cryptographic keys, the data is unreadable and unusable to that person. Other effective methods of protect
d PANs using end-user messaging technologies, such as e-mail and instant messaging.
d authentication protocols continue to be targets of malicious individuals who exploit these vulnerabilities to gain privileged access to cardh
nternet, mobile computers, and storage devices, resulting in the exploitation of system vulnerabilities. Anti-virus software must be used on a
virus software to be in place.
ties that manage the systems. All systems must have all appropriate software patches to protect against the exploitation and compromise o
a and systems are performed by, and can be traced to, known and authorized users and processes. The effectiveness of a password is larg
he security methods to protect user passwords at the point of entry, during transmission, and while in storage.
with cardholder data. This includes accounts used by vendors and other third parties (for example, for support or maintenance).
ard number at a time in order to facilitate a single transaction (such as cashier accounts).
restricted. For the purposes of Requirement 9, “onsite personnel” refers to full-time and part-time employees, temporary employees, contra
racking, alerting, and analysis when something does go wrong. Determining the cause of a compromise is very difficult, if not impossible, w
frequently to ensure security controls continue to reflect a changing environment.
otecting it. For the purposes of Requirement 12, “personnel” refers to full-time and part-time employees, temporary employees, contractors a
hat shared hosting providers must protect each entity’s hosted environment and data. Therefore, shared hosting providers must additionally
Evidence of Controls
Control Process Control Output:
Artifact
See Below See Below
Assuming all firewall rules start with deny/deny, An excel spreadsheet or a word document
fire wall rules are not arbitrary. Each rule beyond or a dashboard (automated) that reflects
deny must have a definition (why it's there) and each and every rule, port and protocol,
an approval. Each network connection (port and their definition, inception date and
protocol) has a role and must contain a reason. approval.
The lifecycle must identify and show why rule,
ports and protocols are in place.
Ensure the network diagram is current and A drawing in some form:

updated as new devices and/or rules are entered • Visio drawing
onto the network. Network diagram is a controlled • Output from a network application
document.
Merchant (or service provider) reponsible for the A drawing in some form:
data flow must possess a current, up-to-date, • Visio drawing
diagram of the cardholder data flow with • Output from a network application
appropriate support verbiage. The document Must also contain full explanations.
must run in parallel to the network diagram.
The firewall configuration standard must require • The firewall configuratin standard.
the requirement for a firewall at each internet • The network topology drawing.
connection, includes the DMZ and internal • Interview with the network security SME.
network zones.
• The configuration standard provides for the • Current router (network) configuration
roles and responsibilities of the aligned network standard with the requirement.
team and its manager. • Interview with any of the router (network)
• The team and manager clearly represent the team to demonstrate the understanding is
standard's requirement. in place and supported.
The network lifecycle must be formally tracked, An excel spreadsheet or a word document
via microsoft suite or in automation (ServiceNow) or a dashboard (automated) that reflects
for the inception, changes and approvals to each and every rule, port and protocol,
secure and "appproved" insecure services, their definition, inception date and
protocols and ports. approval.
In following the firewal and router configuration An excel spreadsheet or a word document
standard, the activity of a complete firewall and or a dashboard (automated) that reflects
router rule review. Each review must be formally the review. Availabilty of a resource that
tracked, via microsoft suite or in automation attended/conducted the review.
(ServiceNow) to demonstrate the review
occurred. .
See Below See Below
for the inception, changes and approvals to any the requirement for the assurance that
inbound and outbound traffic ensuring justification inbound and outbound traffic is limited
for each instance. minimum necessary and each instance is
justified.
The firewall and router configuration standard • An excel spreadsheet or a word

(can be in the network standard) provides the document or a dashboard (automated)
latest configuration file secure from unauthorized that reflects the requirement for
access and that the most current file is configuration files to be secure and the
synchronized. most current is synchronized.
• Screenshot of the most current router
configuration file being stored securely.
configuration file synchronized and
running.
for the inception, changes and approvals to each and every rule, port and protocol,
secure and "appproved" insecure services, their definition, inception date and
protocols and ports. approval.
See Below See Below

The firewall and router configuration standard The network inventory demonstrates that
provides the guidance that the DMZ is used to all inbound traffic to system components
host all public accessible services and ports AND provide only authorized access to publicly
the inbound traffic is limited to only IP addresses accessible services, protocols and ports
within the DMZ. This is a de facto standard for and limits inbound internet traffic to only IP
any changes or new rule implementations. addresses within the DMZ
ective methods of protecting stored data should also be considered as potential risk mitigation
rivileged access to cardholder data environments.
ftware must be used on all systems commonly affected by malware to protect systems from current and
tation and compromise of cardholder data by malicious individuals and malicious software.
ess of a password is largely determined by the design and implementation of the authentication system
maintenance).
orary employees, contractors and consultants who are physically present on the entity’s premises. A “visitor” refers to a vendor, guest of an
ficult, if not impossible, without system activity logs.
employees, contractors and consultants who are “resident” on the entity’s site or otherwise have access to the cardholder data environmen
oviders must additionally comply with the requirements in this Appendix.
Comment
See Below
ises. A “visitor” refers to a vendor, guest of any onsite personnel, service workers, or anyone who needs to enter the
ve access to the cardholder data environment
#
PCI DSS 3.2 Controls
Requirement 1: Install and maintain a firewall configuration to protect cardholder data.

1.1 Establish and implement firewall and router configuration
standards that include requirements 1.1.1 through 1.1.7.
1.1.1 A formal process for approving and testing all network

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

between the cardholder data environment and other networks,
including any wireless networks
1.1.3 Current diagram that shows all cardholder data flows

across systems and networks
4
1.1.4 Requirements for a firewall at each Internet connection and
between any demilitarized zone (DMZ) and the internal network
zone
1.1.5 Description of groups, roles, and responsibilities for

management of network components
6
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.7 Requirement to review firewall and router rule sets at least

every six months
1.2 Build firewall and router configurations that restrict

connections between untrusted networks and any system
components in the cardholder data environment.
Note: An “untrusted network” is any network that is external to

9 the networks belonging to the entity under review, and/or which
is out of the entity's ability to control or manage.
1.2.1 Restrict inbound and outbound traffic to that which is
necessary for the cardholder data environment, and specifically
deny all other traffic.
10
1.2.2 Secure and synchronize router configuration files.
11
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.
12
1.3 Prohibit direct public access between the Internet and any
system component in the cardholder data environment.
13
1.3.1 Implement a DMZ to limit inbound traffic to only system

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

DMZ.
15
1.3.3 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.)
16
1.3.4 Do not allow unauthorized outbound traffic from the

cardholder data environment to the Internet.
17
1.3.5 Permit only "established" connections into the network.
18
1.3.6 Place system components that store cardholder data (such

as a database) in an internal network zone, segregated from the
DMZ and other untrusted networks.
19
1.3.7 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.
20
1.4 Install personal firewall software or equivalent functionality on

any portable computing devices (including company and/or
employee-owned) that connect to the internet when outside the
network (for example, laptops used by employees), and which
are also used to access the CDE. Firewall (or equivalent)
configurations include:
• Specific configuration settings are defined

• Personal firewall (or equivalent functionality) is actively
running.
• Personal firewall (or equivalent functionality) is not alterable by
users of mobile and/or employee-owned devices.
21
managing firewalls are documented, in use, and known to all
affected parties.
22
Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters
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, point-of-sale
(POS) terminals, Simple Network Management Protocol (SNMP)
community strings, etc.).
23
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.
24
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
• Center for Internet Security (CIS)

• International Organization for Standardization (ISO)
• SysAdmin Audit Network Security (SANS) Institute
• National Institute of Standards Technology (NIST).
25
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.
26
2.2.2 Enable only necessary services, protocols, daemons, etc.,

as required for the function of the system.
27
2.2.3 Implement additional security features for any
required services,
Note: Where SSL/early TLS is used, the requirements in
28
2.2.4 Configure system security parameters to prevent misuse.
29
2.2.5 Remove all unnecessary functionality, such as scripts,

drivers, features, subsystems, file systems, and unnecessary
web servers.
30
2.3 Encrypt all non-console administrative access using
strong cryptography. Note: Where SSL/early TLS is used,
the requirements in Appendix A2 must be completed.
31
2.4 Maintain an inventory of system components that are in

scope for PCI DSS.
32

managing vendor defaults and other security parameters are
33
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 A1: Additional PCI
DSS Requirements for Shared Hosting Providers.
34
Requirement 3: Protect Cardholder Data

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 cardholder data (CHD)
storage:
• Limiting data storage amount and retention time to that which

is required for legal, regulatory, and 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.
35
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:
36
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:
37 ▪ The cardholder’s name

▪ Primary account number (PAN)
▪ Expiration date
▪ Service code To minimize risk, store only these data elements
as needed for business.
3.2.2 Do not store the card verification code or 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.
38
3.2.3 Do not store the personal identification number (PIN) or the

encrypted PIN block after authorization.
39
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 more
than the first six/last four digits of the 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.
40
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
41 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.
Note: This requirement applies to addition to all other PCI DSS

encryption and key-management requirements.
42
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
43 be at least as strong as the data-encrypting key.
3.5.1 Additional requirement for service providers only:

Maintain a documented description of the cryptographic
architecture that includes:
• Details of all algorithms, protocols, and keys used for the

protection of cardholder data, including key strength and expiry
date
• Description of the key usage for each key
• Inventory of any HSMs and other SCDs used for key
44 management

3.5.2 Restrict access to cryptographic keys to the fewest number
of custodians necessary.
45
3.5.3 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.
46
3.5.4 Store cryptographic keys in the fewest possible locations.
47
3.6 Fully document and implement all key-management processes and procedures for cryptographic keys used for
48
3.6.1 Generation of strong cryptographic keys
49
3.6.2 Secure cryptographic key distribution
50
3.6.3 Secure cryptographic key storage
51
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).
52
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.
53
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.
54
3.6.7 Prevention of unauthorized substitution of cryptographic
keys.
55
3.6.8 Requirement for cryptographic key custodians to formally

acknowledge that they understand and accept their key-
custodian responsibilities.
56

protecting stored cardholder data are documented, in use, and
57
Requirement 4: Encrypt transmission of cardholder data across open, public networks

4.1 Use strong cryptography and security protocols 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.
Note: Where SSL/early TLS is used, the requirements in

Examples of open, public networks include but are not limited to:
• The internet
• Cellular technologies, for example, Global System for Mobile
58 • General Packet Radio Service (GPRS)
• Satelite communications
4.1.1 Ensure wireless networks transmitting cardholder data or

connected to the cardholder data environment, use industry best
practices to implement strong encryption for authentication and
transmission.
59
4.2 Never send unprotected PANs by end-user messaging
technologies (for example, e-mail, instant messaging, SMS, chat,
etc.).
60

encrypting transmissions of cardholder data are documented, in
use, and known to all affected parties.
61
Requirement 5: Maintain a Vulnerability Management Program

5.1 Deploy anti-virus software on all systems commonly affected
by malicious software (particularly personal computers and
servers).
62
5.1.1 Ensure that anti-virus programs are capable of detecting,
removing, and protecting against all known types of malicious
software.
63
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.
64
5.2 Ensure that all anti-virus mechanisms are maintained as

follows:

• Perform periodic scans
• Generate audit logs which are retained per PCI DSS
Requirement 10.7.
65
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
66 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.

protecting systems against malware are documented, in use, and
67
Requirement 6: Develop and maintain secure systems and applications

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,
68 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.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.
69
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.
▪ Incorporating 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.
70
6.3.1 Remove development, test and/or custom application

accounts, user IDs, and passwords before applications become
active or are released to customers.
71
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

72 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.
6.4 Follow change control processes and procedures for all

changes to system components. The processes must include the
following:
73
6.4.1 Separate development/test environments from production
environments, and enforce the separation with access controls.
74
6.4.2 Separation of duties between development/test and

production environments
75
6.4.3 Production data (live PANs) are not used for testing or
development
76
6.4.4 Removal of test data and accounts before production

systems become active / goes into production.
77
6.4.5 Change control procedures must include the following:
78
6.4.5.1 Documentation of impact.
79
6.4.5.2 Documented change approval by authorized parties.
80
6.4.5.3 Functionality testing to verify that the change does not
adversely impact the security of the system.
81
6.4.5.4 Back-out procedures.
82
6.4.6 Upon completion of a significant change, all relevant PCI

DSS requirements must be implemented on all new or changed
systems and networks, and documentation updated as
applicable.

83
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.
84
Note: Requirements 6.5.1 through 6.5.6, below, apply to all applications (internal or external).
85
6.5.1 Injection flaws, particularly SQL injection. Also consider OS
Command Injection, LDAP and XPath injection flaws as well as
other injection flaws.
86
6.5.2 Buffer overflows
87
6.5.3 Insecure cryptographic storage
88
6.5.4 Insecure communications
89
6.5.5 Improper error handling
90
6.5.6 All “high risk” vulnerabilities identified in the vulnerability
identification process (as defined in PCI DSS Requirement 6.1).
Note: Requirements 6.5.7 through 6.5.10, below, apply to web
applications and application interfaces (internal or external):
91
Note: Requirements 6.5.7 through 6.5.10, below, apply to web applications and application interfaces (inter
6.5.7 Cross-site scripting (XSS)
92
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).
93
6.5.9 Cross-site request forgery (CSRF)
94
6.5.10 Broken authentication and session management
95
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.
96

developing and maintaining secure systems and applications are
97
Requirement 7: Implement Strong Access Control Measures

7.1 Limit access to system components and cardholder data to
only those individuals whose job requires such access.
98
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
99 • Level of privilege required (for example, user, administrator,
etc.) for accessing resources.
7.1.2 Restrict access to privileged user IDs to least privileges

necessary to perform job responsibilities.
100
7.1.3 Assign access based on individual personnel’s job

101
7.1.4 Require documented approval by authorized parties

specifying required privileges.
102
7.2 Establish an access control system for systems components

that restricts access based on a user’s need to know, and is set
103 to “deny all” unless specifically allowed.
This access control system must include the following:
7.2.1 Coverage of all system components
104
7.2.2 Assignment of privileges to individuals based on job

105
7.2.3 Default “deny-all” setting.
106

restricting access to cardholder data are documented, in use,
and known to all affected parties.
107
Requirement 8: Identify and authenticate access to system components

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:
108
8.1.1 Assign all users a unique ID before allowing them to

access system components or cardholder data.
109
8.1.2 Control addition, deletion, and modification of user IDs,
credentials, and other identifier objects.
110
8.1.3 Immediately revoke access for any terminated users.
111
8.1.4 Remove/disable inactive user accounts within 90 days.
112
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.
113
8.1.6 Limit repeated access attempts by locking out the user ID
after not more than six attempts.
114
8.1.7 Set the lockout duration to a minimum of 30 minutes or until

an administrator enables the user ID.
115
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.
116
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.
117
8.2.1 Using strong cryptography, render all authentication

credentials (such as passwords/phrases) unreadable during
transmission and storage on all system components.
118
8.2.2 Verify user identity before modifying any authentication

credential—for example, performing password resets,
provisioning new tokens, or generating new keys.
119
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.
120
8.2.4 Change user passwords/passphrases at least once every

90 days.
121
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.
122
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.
123
8.3 Secure all individual non-console administrative access and

all remote access to the CDE using multi-factor authentication.
Note: Multi-factor authentication requires that a minimum of 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 multi-factor
authentication.
124
8.3.1 Incorporate multi-factor authentication for all non-console
access into the CDE for personnel with administrative access
125
8.3.2 Incorporate multi-factor authentication for all remote

network access (both user and administrator, and including third-
party access for support or maintenance) originating form outside
the entity's network
126
8.4 Document and communicate authentication procedures and
policies 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.
127
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.
128

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.
129 Note: This requirement is not intended to apply to shared hosting

providers accessing their own hosting environment, where
multiple customer environments are hosted.
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.
130
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).
131
identification and authentication are documented, in use, and
132
Requirement 9: Restrict physical access to cardholder data

9.1 Use appropriate facility entry controls to limit and monitor
physical access to systems in the cardholder data environment.
133
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
134 a retail store.
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
135 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.
9.1.3 Restrict physical access to wireless access points,

gateways, handheld devices, networking/communications
hardware, and telecommunication lines.
136
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
137
9.3 Control physical access for onsite personnel to the 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.
138
9.4 Implement procedures to identify and authorize visitors.

Procedures should include requirements 9.4.1 through 9.4.4.
139
9.4.1 Visitors are authorized before entering, and escorted at all

times within, areas where cardholder data is processed or
maintained.
140
9.4.2 Visitors are identified and given a badge or other

identification that expires and that visibly distinguishes the
visitors from onsite personnel.
141
9.4.3 Visitors are asked to surrender the badge or identification

before leaving the facility or at the date of expiration.
142
9.4.4 A visitor log is used to maintain a physical audit trail of
visitor activity to the facility as well as computer rooms and data
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
143 restricted by law.
9.5 Physically secure all media.
144
9.5.1 Store media backups in a secure location, preferably an

off-site facility, such as an alternate or backup site, or a
commercial storage facility. Review the location’s security at least
145
annually.
9.6 Maintain strict control over the internal or external distribution

of any kind of media, including the following:
146
9.6.1 Classify media so the sensitivity of the data can be

determined.
147
9.6.2 Send the media by secured courier or other delivery

method that can be accurately tracked.
148
9.6.3 Ensure management approves any and all media that is
moved from a secured area (including when media is distributed
to individuals).
149
9.7 Maintain strict control over the storage and accessibility of

media.
150
9.7.1 Properly maintain inventory logs of all media and conduct

media inventories at least annually.
151
9.8 Destroy media when it is no longer needed for business or

legal reasons as follows:
152
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.
153
9.8.2 Render cardholder data on electronic media unrecoverable
so that cardholder data cannot be reconstructed.
154
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.
155
9.9.1 Maintain an up-to-date list of devices. The list should

• 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.
156
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.
157
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).
158
restricting physical access to cardholder data are documented, in
use, and known to all affected parties.
159
Requirement 10: Regularly Monitor and Test Networks

10.1 Implement audit trails to link all access to system
components to each individual user.
160
10.2 Implement automated audit trails for all system components

to reconstruct the following events:
161
10.2.1 All individual user accesses to cardholder data
162
10.2.2 All actions taken by any individual with root or

administrative privileges
163
10.2.3 Access to all audit trails
164
10.2.4 Invalid logical access attempts
165
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
166
10.2.6 Initialization, stopping, or pausing of the audit logs
167
10.2.7 Creation and deletion of system- level objects
168
10.3 Record at least the following audit trail entries for all system
components for each event:
169
10.3.1 User identification
170
10.3.2 Type of event
171
10.3.3 Date and time
172
10.3.4 Success or failure indication
173
10.3.5 Origination of event
174
10.3.6 Identity or name of affected data, system component, or

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

176 Network Time Protocol (NTP).
10.4.1 Critical systems have the correct and consistent time.
177
10.4.2 Time data is protected.
178
10.4.3 Time settings are received from industry-accepted time

sources.
179
10.5 Secure audit trails so they cannot be altered.
180
10.5.1 Limit viewing of audit trails to those with a job-related

need.
181
10.5.2 Protect audit trail files from unauthorized modifications.
182
10.5.3 Promptly back up audit trail files to a centralized log

server or media that is difficult to alter.
183
10.5.4 Write logs for external-facing technologies onto a secure,
centralized, internal log server or media device.
184
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).
185
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.
186
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.).
187
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.
188
10.6.3 Follow up exceptions and anomalies identified during the

review process.
189
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).
190

Implement a process for the timely detection and reporting of
failures of critical security control systems, including but not
limited to failure of:
•Firewalls
•IDS/IPS
•FIM
•Anti-virus
191 •Physical access controls
•Logical access controls
•Audit logging mechanisms
•Segmentation controls (if used)

Respond to failures of any critical security controls in a timely
manner. Processes for responding to failures in security controls
must include:
• Restoring security functions

• Identifying and documenting the
duration (date and time start to end)
of the security failure
• Identifying and documenting
cause(s) of failure, including root
cause, and documenting
remediation required to address
root cause
• Identifying and addressing any
security issues that arose during
the failure
192 • Performing a risk assessment to
determine whether further actions
are required as a result of the
security failure
• Implementing controls to prevent
use of failure from reoccurring
• Resuming monitoring of security
controls


monitoring all access to network resources and cardholder data
are documented, in use, and known to all affected parties.
193
Requirement 11: Regularly test security systems and processes.

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..
194
11.1.1 Maintain an inventory of authorized wireless access points
including a documented business justification.
195
11.1.2 Implement incident response procedures in the event

unauthorized wireless access points are detected.
196
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
197
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.
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.
198
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.
199
11.2.3 Perform internal and external scans, and rescans as

needed, after any significant change. Scans must be performed
by qualified personnel.
200
11.3 Implement a methodology for penetration testing that
includes 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 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
201 remediation activities results.
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).
202
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).
203
11.3.3 Exploitable vulnerabilities found during penetration testing
are corrected and testing is repeated to verify the corrections.
204
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.
205
11.3.4.1 Additional requirement for service providers only: If
segmentation is used, confirm PCI DSS scope by performing
penetration testing on segmentation controls at least every six
months and after any changes to segmentation
controls/methods.

206
11.4 Use intrusion-detection 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.
207
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.
208 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.1 Implement a process to respond to any alerts generated

by the change- detection solution.
209

security monitoring and testing are documented, in use, and
210
Requirement 12: Maintain an Information Security Policy

12.1 Establish, publish, maintain, and disseminate a security
211 policy.
12.1.1 Review the security policy at least annually and update
212 the policy when the environment changes.
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
213 • 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.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,
214 tablets, removable electronic media, e- mail usage and Internet
usage.
Ensure these usage policies require the following:
215 12.3.1 Explicit approval by authorized parties

216 12.3.2 Authentication for use of the technology
12.3.3 A list of all such devices and personnel with access
217
12.3.4 A method to accurately and readily determine owner,

218 contact information, and purpose (for example, labeling, coding,
and/or inventorying of devices)
219 12.3.5 Acceptable uses of the technology

220 12.3.6 Acceptable network locations for the technologies
221 12.3.7 List of company-approved products
12.3.8 Automatic disconnect of sessions for remote-access
222 technologies after a specific period of inactivity
12.3.9 Activation of remote-access technologies for vendors and
business partners only when needed by vendors and business
223 partners, with immediate deactivation after use
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
224 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.4 Ensure that the security policy and procedures clearly

225 define information security responsibilities for all personnel.
Executive management shall establish responsibility for the
protection of cardholder data and PCI DSS compliance program
to include:
•Overall accountability for maintaining PCI DSS compliance

•Defining a charter for PCI DSS compliance program and
226 communication to executive management.

12.5 Assign to an individual or team the following information

227 security management responsibilities:
12.5.1 Establish, document, and distribute security policies and
228 procedures.
12.5.2 Monitor and analyze security alerts and information, and
229 distribute to appropriate personnel.
12.5.3 Establish, document, and distribute security incident
230 response and escalation procedures to ensure timely and
effective handling of all situations.
12.5.4 Administer user accounts, including additions, deletions,
231 and modifications.
232 12.5.5 Monitor and control all access to data.
12.6 Implement a formal security awareness program to make all
233 personnel aware of the importance of cardholder data security
policy and procedures.
12.6.1 Educate personnel upon hire and at least annually.
Note: Methods can vary depending on the role of the personnel

234 and their level of access to the cardholder data.
12.6.2 Require personnel to acknowledge at least annually that

235 they have read and understood the security policy and
procedures.
12.7 Screen potential personnel prior to hire to minimize the risk
of attacks from internal sources. (Examples of background
checks include previous employment history, criminal record,
credit history, and reference checks.)
236 Note: For those potential personnel to be hired for certain

positions such as store cashiers who only have access to one
card number at a time when facilitating a transaction, this
requirement is a recommendation only.
12.8 Maintain and implement policies and procedures to manage
service providers with whom cardholder data is shared, or that
237 could affect the security of cardholder data, as follows:
238 12.8.1 Maintain a list of service providers.

12.8.2 Maintain a written agreement that includes an
acknowledgement that the service providers are responsible for
the security of cardholder data the service providers possess 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
Note: The exact wording of an acknowledgement will depend on

239 the agreement between the two parties, the details of the service
The acknowledgement does not have to include the exact
wording provided in this requirement.
12.8.3 Ensure there is an established process for engaging

240 service providers including proper due diligence prior to
engagement.
12.8.4 Maintain a program to monitor service providers’ PCI DSS
241 compliance status at least annually.
12.8.5 Maintain information about which PCI DSS requirements
242 are managed by each service provider, and which are managed
by the entity.
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,

243 The exact wording of an acknowledgement will depend on the

agreement between the two parties, the details of the service
The acknowledgement does not have to include the exact
wording provided in this requirement.
12.10 Implement an incident response plan. Be prepared to

244 respond immediately to a system breach.
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
245 • Data backup processes
• Analysis of legal requirements for reporting compromises
• Coverage and responses of all critical system components
• Reference or inclusion of incident response procedures from
the payment brands.
12.10.2 Review and test the plan, including all elements listed in
246 Requirement 12.10.1, at least annually.
12.10.3 Designate specific personnel to be available on a 24/7
247 basis to respond to alerts.
12.10.4 Provide appropriate training to staff with security breach
248 response responsibilities.
12.10.5 Include alerts from security monitoring systems,
249 including but not limited to intrusion-detection, intrusion-
prevention, firewalls, and file-integrity monitoring systems.
12.10.6 Develop a process to modify and evolve the incident
250 response plan according to lessons learned and to incorporate
industry developments.
12.11 Additional requirement for service providers only.
Perform reviews at least quarterly to confirm personnel are
following security policies and operational procedures. Reviews
must cover the following processes:
• Daily log reviews

• Firewall rule-set reviews
• Applying configuration standards to new systems
251
• Responding to security alerts
• Change management processes

Maintain documentation of quarterly review process to include:
•Documenting results of the reviews

•Review and sign-off of results by personnel assigned
responsibility for the PCI DSS compliance program
252
Appendix A: Additional PCI DSS Requirements for Shared Hosting Providers

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

requirements, the compliance of the entity that uses the hosting
provider is not guaranteed. Each entity must comply with the CI
DSS and validate compliance
A.1.1 Ensure that each entity only runs processes that have
access to that entity’s cardholder data environment.
A.1.2 Restrict each entity’s access and privileges to its own
cardholder data environment only.
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.4 Enable processes to provide for timely forensic
investigation in the event of a compromise to any hosted
merchant or service provider.
Testing
Procedures
protect cardholder data.

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 Examine documented procedures to verify there is a formal process for

testing and approval of all:
• Network connections and

• Changes to firewall and router configurations
1.1.1.b For a sample of network connections, interview responsible personnel

and examine records to verify that network connections were approved and
tested
1.1.1.c Identify a sample of actual changes made to firewall and router

configurations, compare to the change records, and interview responsible
personnel to verify the changes were approved and tested.
1.1.2.a Examine diagram(s) and observe network configurations to verify that a

current network diagram exists and that it documents all connections to
cardholder data, including any wireless networks.
1.1.2.b Interview responsible personnel to verify that the diagram is kept
current.
1.1.3 Examine data-flow diagram and interview personnel to verify the diagram:
• Shows all cardholder data flows across systems and networks.
• Is kept current and updated as needed upon changes to the environment.
1.1.4.a Examine the firewall configuration standards and verify that they include
requirements for a firewall at each Internet connection and between any DMZ
and the internal network zone.
1.1.4.b Verify that the current network diagram is consistent with the firewall
configuration standards.
1.1.4.c Observe network configurations to verify that a firewall is in place at
each Internet connection and between any demilitarized zone (DMZ) and the
internal network zone, per the documented configuration standards and network
diagrams.
1.1.5.a Verify that firewall and router configuration standards include a

description of groups, roles, and responsibilities for management of network
components.
1.1.5.b Interview personnel responsible for management of network

components to confirm that roles and responsibilities are assigned as
documented.
1.1.6.a Verify that firewall and router configuration standards include a
documented list of all services, protocols and ports, including business
justification and approval for each.
1.1.6.b Identify insecure services, protocols, and ports allowed; and verify that
security features are documented for each service.
1.1.6.c Examine firewall and router configurations to verify that the documented
security features are implemented for each insecure service, protocol, and port.
1.1.7.a Verify that firewall and router configuration standards require review of
firewall and router rule sets at least every six months.
1.1.7.b Examine documentation relating to rule set reviews and interview

responsible personnel to verify that the rule sets are reviewed at least every six
months.
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.a Examine firewall and router configuration standards to verify that they
identify inbound and outbound traffic necessary for the cardholder data
environment.
1.2.1.b Examine firewall and router configurations to verify that inbound and
outbound traffic is limited to that which is necessary for the cardholder data
environment.
1.2.1.c Examine firewall and router configurations to verify that all other inbound
and outbound traffic is specifically denied, for example by using an explicit “deny
all” or an implicit deny after allow statement.
1.2.2.a Examine router configuration files to verify they are secured from
unauthorized access.
1.2.2.b Examine router configurations to verify they are synchronized—for

example, the running (or active) configuration matches the start-up configuration
(used when machines are booted).
1.2.3.a Examine firewall and router configurations to verify that there are
perimeter firewalls installed between all wireless networks and the cardholder
data environment.
1.2.3.b Verify that the firewalls deny or, if traffic is necessary for business
purposes, permit only authorized traffic between the wireless environment and
the cardholder data environment
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:
1.3.1 Examine firewall and router configurations to verify that a DMZ is

implemented to limit inbound traffic to only system components that provide
authorized publicly accessible services, protocols, and ports.
1.3.2 Examine firewall and router configurations to verify that inbound Internet
traffic is limited to IP addresses within the DMZ.
1.3.2 Examine firewall and router configurations to verify that inbound Internet
traffic is limited to IP addresses within the DMZ
1.3.3 Examine firewall and router configurations to verify that anti-spoofing
measures are implemented, for example internal addresses cannot pass from
the Internet into the DMZ.
1.3.4 Examine firewall and router configurations to verify that outbound traffic
from the cardholder data environment to the Internet is explicitly authorized.
1.3.5 Examine firewall and router configurations to verify that the firewall permits
only established connections into the internal network and denies any inbound
connections not associated with a previously established session.
1.3.6 Examine firewall and router configurations to verify that system

components that store cardholder data are on an internal network zone,
segregated from the DMZ and other untrusted networks.
1.3.7.a Examine firewall and router configurations to verify that methods are in
place to prevent the disclosure of private IP addresses and routing information
from internal networks to the Internet.
1.3.7.b Interview personnel and examine documentation to verify that any

disclosure of private IP addresses and routing information to external entities is
authorized.
1.4.a Examine policies and configuration standards to verify:
▪ Personal firewall software or equivalent functionality is required for all portable

computing devices (including company and/or employee-owned) that connect to
the Internet when outside the network (for example, laptops used by
employees), and which are also used to access the CDE.
▪ Specific configuration settings are defined for personal firewall (or equivalent
functionality).
▪ Personal firewall (or equivalent functionality) is configured to actively run.
▪ Personal firewall (or equivalent functionality) is configured to not be alterable
by users of the portable computing devices.
1.4.b Inspect a sample of company and/or employee-owned devices to verify

that:
▪ Personal firewall (or equivalent functionality) is installed and configured per the
organization’s specific configuration settings.
▪ Personal firewall (or equivalent functionality) is actively running.
▪ Personal firewall (or equivalent functionality) is not alterable by users of the
portable computing devices.
1.5 Examine documentation and interview personnel to verify that security
policies and operational procedures for managing firewalls are:
▪ Documented,
▪ In use, and
▪ Known to all affected parties.
em passwords and other security parameters

2.1.a Choose a sample of system components, and attempt to log on (with
system administrator help) to the devices and applications using default vendor-
supplied accounts and passwords, to verify that ALL default passwords
(including those on operating systems, software that provides security services,
application and system accounts, POS terminals, and Simple Network
Management Protocol (SNMP) community strings) have been changed. (Use
vendor manuals and sources on the Internet to find vendor-supplied
accounts/passwords.)
2.1.b For the sample of system components, verify that all unnecessary default
accounts (including accounts used by operating systems, security software,
applications, systems, POS terminals, SNMP, etc.) are removed or disabled.
2.1.c Interview personnel and examine supporting documentation to verify that:
▪ All vendor defaults (including default passwords on operating systems,

software providing security services, application and system accounts, POS
terminals, Simple Network Management Protocol (SNMP) community strings,
etc.) are changed before a system is installed on the network.
▪ Unnecessary default accounts (including accounts used by operating systems,
security software, applications, systems, POS terminals, SNMP, etc.) are
removed or disabled before a system is installed on the network.
2.1.1.a Interview responsible personnel and examine supporting documentation
to verify that:
▪ Encryption keys were changed from default at installation

▪ Encryption keys are changed anytime anyone with knowledge of the keys
leaves the company or changes positions.
2.1.1.b Interview personnel and examine policies and procedures to verify:
▪ Default SNMP community strings are required to be changed upon installation.

▪ Default passwords/passphrases on access points are required to be changed
upon installation.
2.1.1.c Examine vendor documentation and login to wireless devices, with

system administrator help, to verify:
▪ Default SNMP community strings are not used.

▪ Default passwords/passphrases on access points are not used.
2.1.1.d Examine vendor documentation and observe wireless configuration

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

▪ Transmission over wireless networks.
2.1.1.e Examine vendor documentation and observe wireless configuration

settings to verify other security-related wireless vendor defaults were changed, if
applicable.
2.2.a Examine the organization’s system configuration standards for all types of
system components and verify the system configuration standards are
consistent with industry-accepted hardening standards.
2.2.b Examine policies and interview personnel to verify that system

configuration standards are updated as new vulnerability issues are identified,
as defined in Requirement 6.1.
2.2.c Examine policies and interview personnel to verify that system

configuration standards are applied when new systems are configured and
verified as being in place before a system is installed on the network.
2.2.d Verify that system configuration standards include the following

procedures for all types of system components:
▪ Changing of all vendor-supplied defaults and elimination of unnecessary

default accounts
▪ Implementing only one primary function per server to prevent functions that
require different security levels from co-existing on the same server
▪ Enabling only necessary services, protocols, daemons, etc., as required for
the function of the system
▪ Implementing additional security features for any required services, protocols
or daemons that are considered to be insecure
▪ Configuring system security parameters to prevent misuse
▪ Removing all unnecessary functionality, such as scripts, drivers, features,
subsystems, file systems, and unnecessary web servers.
2.2.1.a Select a sample of system components and inspect the system

configurations to verify that only one primary function is implemented per server.
2.2.1.b If virtualization technologies are used, inspect the system configurations

to verify that only one primary function is implemented per virtual system
component or device.
2.2.2.a Select a sample of system components and inspect enabled system

services, daemons, and protocols to verify that only necessary services or
protocols are enabled.
2.2.2.b Identify any enabled insecure services, daemons, or protocols and
interview personnel to verify they are justified per documented configuration
standards
2.2.3.a Inspect configuration settings to verify that security features are
documented and implemented for all insecure services, daemons, or protocols.
2.2.3.b If SSL/early TLS is used, perform testing procedures in Appendix A2:

Additional PCI DSS Requirements for Entities using SSL/Early TLS.
2.2.4.a Interview system administrators and/or security managers to verify that

they have knowledge of common security parameter settings for system
components.
2.2.4.b Examine the system configuration standards to verify that common

security parameter settings are
2.2.4.c Select a sample of system components and inspect the common

security parameters to verify that they are set appropriately and in accordance
with the configuration standards.
2.2.5.a Select a sample of system components and inspect the configurations to

verify that all unnecessary functionality (for example, scripts, drivers, features,
subsystems, file systems, etc.) is removed.
2.2.5.b. Examine the documentation and security parameters to verify enabled

functions are documented and support secure configuration.
2.2.5.c. Examine the documentation and security parameters to verify that only
documented functionality is present on the sampled system components.
2.3 Select a sample of system components and verify that non-console
administrative access is encrypted by performing the following:
2.3.a Observe an administrator log on to each system and examine system

configurations to verify that a strong encryption method is invoked before the
administrator’s password is requested.
2.3.b Review services and parameter files on systems to determine that Telnet
and other insecure remote-login commands are not available for non-console
access.
2.3.c Observe an administrator log on to each system to verify that administrator

access to any web-based management interfaces is encrypted with strong
cryptography.
2.3.d Examine vendor documentation and interview personnel to verify that

strong cryptography for the technology in use is implemented according to
industry best practices and/or vendor recommendations.
2.3.e If SSL/early TLS is used, perform testing procedures in Appendix A2:

Additional PCI DSS Requirements for Entities using SSL/Early TLS.
2.4.a Examine system inventory to verify that a list of hardware and software
components is maintained and includes a description of function/use for each
.
2.4.b Interview personnel to verify the documented inventory is kept current.

policies and operational procedures for managing vendor defaults and other
security parameters are:
▪ Documented,
▪ In use, and
2.6 Perform testing procedures A1.1 through A1.4 detailed in Appendix A1:
Additional PCI DSS Requirements for Shared Hosting Providers for PCI DSS
assessments of shared hosting providers, to verify that shared hosting providers
protect their entities’ (merchants and service providers) hosted environment and
data.
3.1.a Examine the data retention and disposal policies, procedures and
processes to verify they include the following for all cardholder data (CHD)
storage:
▪ Limiting data storage amount and retention time to that which is required for
legal, regulatory, and/or business requirements.
▪ Specific requirements for retention of cardholder data (for example, cardholder
data needs to be held for X period for Y business reasons).
▪ Processes for secure deletion of cardholder data when no longer needed for
legal, regulatory, or business reasons.
▪ A quarterly process for identifying and securely deleting stored cardholder data
that exceeds defined retention requirements.
3.1.b Interview personnel to verify that:
▪ All locations of stored cardholder data are included in the data retention and
disposal processes.
▪ Either a quarterly automatic or manual process is in place to identify and
securely delete stored cardholder data.
▪ The quarterly automatic or manual process is performed for all locations of
cardholder data.
3.1.c For a sample of system components that store cardholder data:
▪ Examine files and system records to verify that the data s tored does not
exceed the requirements defined in the data retention policy
▪ Observe the deletion mechanism to verify data is deleted securely.
3.2.a For issuers and/or companies that support issuing services and store
sensitive authentication data, review policies and interview personnel to verify
there is a documented business justification for the storage of sensitive
authentication data.
3.2.b For issuers and/or companies that support issuing services and store
sensitive authentication data, examine data stores and system configurations to
verify that the sensitive authentication data is secured.
3.2.c For all other entities, if sensitive authentication data is received, review
policies and procedures, and examine system configurations to verify the data is
not retained after authorization.
3.2.d For all other entities, if sensitive authentication data is received, review
procedures and examine the processes for securely deleting the data to verify
that the data is unrecoverable.
3.2.1 For a sample of system components, examine data sources including but
not limited to the following, and verify that the full contents of any track from the
magnetic stripe on the back of card or equivalent data on a chip are not stored
after authorization:
▪ Incoming transaction data

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

▪ History files
▪ Trace files
3.2.3 For a sample of system components, examine data sources, including but
not limited to the following and verify that PINs and encrypted PIN blocks are
not stored after authorization:

▪ History files
▪ Trace files
3.3.a Examine written policies and procedures for masking the display of PANs
to verify:
▪ A list of roles that need access to displays of more than the first six/last four
(includes full PAN) is documented, together with a legitimate business need for
each role to have such access.
▪ PAN must be masked when displayed such that only personnel with a
legitimate business need can see more than the first six/last four digits of the
PAN.
▪ All roles not specifically authorized to see the full PAN must only see masked
PANs.
3.3.b Examine system configurations to verify that full PAN is only displayed for
users/roles with a documented business need, and that PAN is masked for all
other requests.
3.3.c Examine displays of PAN (for example, on screen, on paper receipts) to

verify that PANs are masked when displaying cardholder data, and that only
those with a legitimate business need are able to see more than the first six/last
four digits of the PAN.
3.4.a Examine documentation about the system used to protect the PAN,
including the vendor, type of system/process, and the encryption algorithms (if
applicable) to verify that the PAN is rendered unreadable using any of the
following methods:
▪ One-way hashes based on strong cryptography,

▪ Truncation
▪ Index tokens and pads, with the pads being securely stored
▪ Strong cryptography, with associated key-management processes and
procedures.
3.4.b Examine several tables or files from a sample of data repositories to verify
the PAN is rendered unreadable (that is, not stored in plain-text).
3.4.c Examine a sample of removable media (for example, back-up tapes) to

confirm that the PAN is rendered unreadable.
3.4.d Examine a sample of audit logs, including payment application logs, to

confirm that PAN is rendered unreadable or is not present in the logs.
3.4.e If hashed and truncated versions of the same PAN are present in the
environment, examine implemented controls to verify that the hashed and
truncated versions cannot be correlated to reconstruct the original PAN.
3.4.1.a If disk encryption is used, inspect the configuration and observe the
authentication process to verify that logical access to encrypted file systems is
implemented via a mechanism that is separate from the native operating
system’s authentication mechanism (for example, not using local user account
databases or general network login credentials).
3.4.1.b Observe processes and interview personnel to verify that cryptographic

keys are stored securely (for example, stored on removable media that is
adequately protected with strong access controls).
3.4.1.c Examine the configurations and observe the processes to verify that
cardholder data on removable media is encrypted wherever stored. 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 Examine key-management policies and procedures to verify processes are

specified to protect keys used for encryption of cardholder data against
disclosure and misuse and include at least the following:
▪ Access to keys is restricted to the fewest number of custodians necessary.

▪ Key-encrypting keys are at least as strong as the data-encrypting keys they
protect.
▪ Key-encrypting keys are stored separately from data-encrypting keys.
▪ Keys are stored securely in the fewest possible locations and forms.
3.5.1 Interview responsible personnel and review documentation to verify that a

document exists to describe the cryptographic architecture, including:
▪ Details of all algorithms, protocols, and keys used for the protection of
cardholder data, including key strength and expiry date
▪ Description of the key usage for each key
▪ Inventory of any HSMs and other SCDs used for key management
3.5.2 Examine user access lists to verify that access to keys is restricted to the
fewest number of custodians necessary
3.5.3.a Examine documented procedures to verify that cryptographic keys used

to encrypt/decrypt cardholder data must only exist in one (or more) of the
following forms at all times.
▪ Encrypted with a key-encrypting key that is at least as strong as the data-

encrypting key, and that is stored separately from the data-encrypting key
▪ Within a secure cryptographic device (such as a hardware (host) security
module (HSM) or PTS-approved point-of-interaction device)
▪ As key components or key shares, in accordance with an industry-accepted
method
3.5.3.b Examine system configurations and key storage locations to verify that
cryptographic keys used to encrypt/decrypt cardholder data exist in one (or
more) of the following form at all times.
▪ Encrypted with a key-encrypting key

▪ Within a secure cryptographic device (such as a hardware (host) security
module (HSM) or PTS-approved point-of-interaction device)
▪ As key components or key shares, in accordance with an industry-accepted
method
3.5.3.c Wherever key-encrypting keys are used, examine system configurations

and key storage locations to verify:
▪ Key-encrypting keys are at least as strong as the data-encrypting keys they

protect
▪ Key-encrypting keys are stored separately from data-encrypting keys.
3.5.4 Examine key storage locations and observe processes to verify that keys
are stored in the fewest possible locations.
3.6.a Additional testing procedure for service provider assessments only: If the
service provider shares keys with their customers for transmission or storage of
cardholder data, examine the documentation that the service provider provides
to their customers to verify that it includes guidance on how to securely transmit,
store, and update customers’ keys, in accordance with Requirements 3.6.1
through 3.6.8 below.
3.6.b Examine the key-management procedures and processes for keys used
for encryption of cardholder data and perform the following:
3.6.1.a Verify that key-management procedures specify how to generate strong

keys.
3.6.1.b Observe the procedures for generating keys to verify that strong keys
are generated.
3.6.2.a Verify that key-management procedures specify how to securely

distribute keys.
3.6.2.b Observe the method for distributing keys to verify that keys are
distributed securely.
3.6.3.a Verify that key-management procedures specify how to securely store

keys.
3.6.3.b Observe the method for storing keys to verify that keys are stored
securely.
3.6.4.a Verify that key-management procedures include a defined cryptoperiod
for each key type in use and define a process for key changes at the end of the
defined cryptoperiod(s).
3.6.4.b Interview personnel to verify that keys are changed at the end of the
defined cryptoperiod(s).
3.6.5.a Verify that key-management procedures specify processes for the

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

processes for the use of the following:
▪ Split knowledge of keys, such that key components are under the control of at
least two people who only have knowledge of their own key components; AND
▪ Dual control of keys, such that at least two people are required to perform any
key-management operations and no one person has access to the
authentication materials (for example, passwords or keys) of another.
3.6.6 b Interview personnel and/or observe processes to verify that manual

clear-text keys are managed with:
▪ Split knowledge, AND

▪ Dual control
3.6.7.a Verify that key-management procedures specify processes to prevent
unauthorized substitution of keys.
3.6.7.b Interview personnel and/or observe processes to verify that

unauthorized substitution of keys is prevented.
3.6.8.a Verify that key-management procedures specify processes for key

custodians to acknowledge (in writing or electronically) that they understand and
accept their key-custodian responsibilities.
3.6.8.b Observe documentation or other evidence showing that key custodians

have acknowledged (in writing or electronically) that they understand and
accept their key-custodian responsibilities.

policies and operational procedures for protecting stored cardholder data are:
▪ Documented,
▪ In use, and
oss open, public networks

4.1.a Identify all locations where cardholder data is transmitted or received over
open, public networks. Examine documented standards and compare to system
configurations to verify the use of security protocols and strong cryptography for
all locations.
4.1.b Review documented policies and procedures to verify processes are

specified for the following:
▪ For acceptance of only trusted keys and/or certificates

▪ For the protocol in use to only support secure versions and configurations (that
insecure versions or configurations are not supported)
▪ For implementation of proper encryption strength per the encryption
methodology in use
4.1.c Select and observe a sample of inbound and outbound transmissions as

they occur (for example, by observing system processes or network traffic) to
verify that all cardholder data is encrypted with strong cryptography during
transit.
4.1.d Examine keys and certificates to verify that only trusted keys and/or
certificates are accepted.
4.1.e Examine system configurations to verify that the protocol is implemented

to use only secure configurations and does not support insecure versions or
configurations.
4.1.f Examine system configurations to verify that the proper encryption strength
is implemented for the encryption methodology in use. (Check vendor
recommendations/best practices.)
4.1.g For TLS implementations, examine system configurations to verify that

TLS is enabled whenever cardholder data is transmitted or received.
For example, for browser-based implementations:
 “HTTPS” appears as the browser Universal Record Locator (URL) protocol,
and
 Cardholder data is only requested if “HTTPS” appears as part of the URL.
4.1.h If SSL/early TLS is used, perform testing procedures in Appendix A2:
4.1.1 Identify all wireless networks transmitting cardholder data or connected to
the cardholder data environment. Examine documented standards and compare
to system configuration settings to verify the following for all wireless networks
identified:
▪ Industry best practices are used to implement strong encryption for

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

policies and operational procedures for encrypting transmissions of cardholder
data are:
▪ Documented,
▪ In use, and
m
5.1 For a sample of system components including all operating system types
commonly affected by malicious software, verify that anti-virus software is
deployed if applicable anti-virus technology exists.
5.1.1 Review vendor documentation and examine anti-virus configurations to
verify that anti-virus programs:
▪ Detect all known types of malicious software,

▪ Remove all known types of malicious software, and
▪ Protect against all known types of malicious software. Examples of types of
malicious software include viruses, Trojans, worms, spyware, adware, and
rootkits.
5.1.2 Interview personnel to verify that evolving malware threats are monitored
and evaluated for systems not currently considered to be commonly affected by
malicious software, in order to confirm whether such systems continue to not
require anti-virus software.
5.2.a Examine policies and procedures to verify that anti-virus software and
definitions are required to be kept up to date.
5.2.b Examine anti-virus configurations, including the master installation of the

software to verify anti-virus mechanisms are:
▪ Configured to perform automatic updates, and

▪ Configured to perform periodic scans.
5.2.c Examine a sample of system components, including all operating system

types commonly affected by malicious software, to verify that:
▪ The anti-virus software and definitions are current.

▪ Periodic scans are performed.
5.2.d Examine anti-virus configurations, including the master installation of the

software and a sample of system components, to verify that:
▪ Anti-virus software log generation is enabled, and

▪ Logs are retained in accordance with PCI DSS Requirement 10.7.
installation of the software and a sample of system components, to verify the
anti-virus software is actively running.
5.3.b Examine anti-virus configurations, including the master installation of the
software and a sample of system components, to verify that the anti-virus
software cannot be disabled or altered by users.
5.3.c Interview responsible personnel and observe processes to verify that anti-
virus software cannot be disabled or altered by users, unless specifically
authorized by management on a case-by-case basis for a limited time period.

policies and operational procedures for protecting systems against malware are:
▪ Documented,
▪ In use, and
pplications
6.1.a Examine policies and procedures to verify that processes are defined for
the following:
▪ To identify new security vulnerabilities

▪ To assign a risk ranking to vulnerabilities that includes identification of all “high
risk” and “critical” vulnerabilities.
▪ To use reputable outside sources for security vulnerability information.
6.1.b Interview responsible personnel and observe processes to verify that:
▪ New security vulnerabilities are identified.

▪ A risk ranking is assigned to vulnerabilities that includes identification of all
“high risk” and “critical” vulnerabilities.
▪ Processes to identify new security vulnerabilities include using reputable
outside sources for security vulnerability information.
6.2.a Examine policies and procedures related to security-patch installation to
verify processes are defined for:
▪Installation of applicable critical vendor-supplied security patches within one

month of release.
▪ Installation of all applicable vendor-supplied security patches within an
appropriate time frame (for example, within three months).
6.2.b For a sample of system components and related software, compare the
list of security patches installed on each system to the most recent vendor
security-patch list, to verify the following:
 That applicable critical vendor-supplied security patches are installed within
one month of release.
 All applicable vendor-supplied security patches are installed within an
appropriate time frame (for example, within three months).
6.3.a Examine written software-development processes to verify that the

processes are based on industry standards and/or best practices.
6.3.b Examine written software-development processes to verify that information

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

applications are developed in accordance with PCI DSS.
6.3.d Interview software developers to verify that written software-development

processes are implemented.
6.3.1 Examine written software-development procedures and interview

responsible personnel to verify 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.
6.3.2.a Examine written software-development procedures and interview
responsible personnel to verify that all custom application code changes must
be reviewed (using either manual or automated processes) as follows:
▪ Code changes are reviewed by individuals other than the originating code
author, and by individuals who are knowledgeable in code-review techniques
and secure coding practices.
▪ Code reviews ensure code is developed according to secure coding guidelines
(see PCI DSS Requirement 6.5).
▪ Appropriate corrections are implemented prior to release.
▪ Code-review results are reviewed and approved by management prior to
release.
6.4 Examine policies and procedures to verify the following are defined:
 Development/test environments are separate from production environments
with access control in place to enforce separation.
 A separation of duties between personnel assigned to the development/test
environments and those assigned to the production environment.
 Production data (live PANs) are not used for testing or development.
 Test data and accounts are removed before a production system becomes
active.
 Change control procedures related to implementing security patches and
software modifications are documented.
6.4.1.a Examine network documentation and network device configurations to
verify that the development/test environments are separate from the production
environment(s).
6.4.1.b Examine access controls settings to verify that access controls are in
place to enforce separation between the development/test environments and
the production environment(s).
6.4.2 Observe processes and interview personnel assigned to development/test

environments and personnel assigned to production environments to verify that
separation of duties is in place between development/test environments and the
production environment.
6.4.3.a Observe testing processes and interview personnel to verify procedures

are in place to ensure production data (live PANs) are not used for testing or
development.
6.4.3.b Examine a sample of test data to verify production data (live PANs) is
not used for testing or development.
6.4.4.a Observe testing processes and interview personnel to verify test data
and accounts are removed before a production system becomes active.
6.4.4.b Examine a sample of data and accounts from production systems

recently installed or updated to verify test data and accounts are removed
before the system becomes active.
6.4.5.a Examine documented change control procedures and verify procedures
are defined for:
▪ Documentation of impact
▪ Documented change approval by authorized parties
▪ Functionality testing to verify that the change does not adversely impact the
security of the system
▪ Back-out procedures
6.4.5.b For a sample of system components, interview responsible personnel to

determine recent changes. Trace those changes back to related change control
documentation. For each change examined, perform the following:
6.4.5.1 Verify that documentation of impact is included in the change control

documentation for each sampled change.
6.4.5.2 Verify that documented approval by authorized parties is present for

each sampled change.
6.4.5.3.a For each sampled change, verify that functionality testing is performed
to verify that the change does not adversely impact the security of the system.
6.4.5.3.b For custom code changes, verify that all updates are tested for
compliance with PCI DSS Requirement 6.5 before being deployed into
production.
6.4.5.4 Verify that back-out procedures are prepared for each sampled change.
6.4.6 For a sample of significant changes, examine change records, interview

personnel, and observe the affected systems/networks to verify that applicable
PCI DSS requirements were implemented and documentation updated as part
of the change.
6.5.a Examine software-development policies and procedures to verify that up-
to-date training in secure coding techniques is required for developers at least
annually, based on industry best practices and guidance.
6.5.b Examine records of training to verify that software developers receive up-
to-date training on secure coding techniques at least annually, including how to
avoid common coding vulnerabilities.
6.5.c Verify that processes are in place to protect applications from, at a

minimum, the following vulnerabilities:
to all applications (internal or external).

6.5.1 Examine software-development policies and procedures and interview
responsible personnel to verify that injection flaws are addressed by coding
techniques that include:
▪ Validating input to verify user data cannot modify meaning of commands and
queries.
▪ Utilizing parameterized queries.
responsible personnel to verify that buffer overflows are addressed by coding
techniques that include:
▪ Validating buffer boundaries.

▪ Truncating input strings.
responsible personnel to verify that insecure cryptographic storage is addressed
by coding techniques that:
▪ Prevent cryptographic flaws.

▪ Use strong cryptographic algorithms and keys.
responsible personnel to verify that insecure communications are addressed by
coding techniques that properly authenticate and encrypt all sensitive
communications.
responsible personnel to verify that improper error handling is addressed by
coding techniques that do not leak information via error messages (for example,
by returning generic rather than specific error details).
responsible personnel to verify that coding techniques address any “high risk”
vulnerabilities that could affect the application, as identified in PCI DSS
Requirement 6.1.
pply to web applications and application interfaces (internal or external).

responsible personnel to verify that cross-site scripting (XSS) is addressed by
coding techniques that include:
▪ Validating all parameters before inclusion

▪ Utilizing context-sensitive escaping.
responsible personnel to verify that improper access control—such as insecure
direct object references, failure to restrict URL access, and directory traversal—
is addressed by coding technique that includes:
▪ 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 Examine software development policies and procedures and interview
responsible personnel to verify that cross-site request forgery (CSRF) is
addressed by coding techniques that ensure applications do not rely on
authorization credentials and tokens automatically submitted by browsers.
6.5.10 Examine software development policies and procedures and interview
responsible personnel to verify that broken authentication and session
management are addressed via coding techniques that commonly include:
▪ Flagging session tokens (for example cookies) as “secure”

▪ Not exposing session IDs in the URL
▪ Incorporating appropriate time-outs and rotation of session IDs after a
successful login.
6.6 For public-facing web applications, ensure that either one of the following
methods is in place as follows:
▪ Examine documented processes, interview personnel, and examine records of

application security assessments to verify that public-facing web applications
are reviewed—using either manual or automated vulnerability security
assessment tools or methods—as follows:
▪ At least annually
▪ After any changes
▪ By an organization that specializes in application security
▪ That, at a minimum, all vulnerabilities in Requirement 6.5 are included in the
assessment
▪ That all vulnerabilities are corrected
▪ That the application is re-evaluated after the corrections.
▪ Examine the system configuration settings and interview responsible

personnel to verify that an automated technical solution that detects and
prevents web-based attacks (for example, a web-application firewall) 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.

policies and operational procedures for developing and maintaining secure
systems and applications are:
▪ Documented,
▪ In use, and
7.1 Examine written policy for access control, and verify that the policy
incorporates 7.1.1 through 7.1.4 as follows:
▪ Defining access needs and privilege assignments for each role

▪ Restriction of access to privileged user IDs to least privileges necessary to
perform job responsibilities
▪ Assignment of access based on individual personnel’s job classification and
function
▪ Documented approval (electronically or in writing) by authorized parties for all
access, including listing of specific privileges approved.
7.1.1 Select a sample of roles and verify access needs for each role are defined
and include:
▪ System components and data resources that each role needs to access for
their job function
▪ Identification of privilege necessary for each role to perform their job function.
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.
7.1.2.b Select a sample of user IDs with privileged access and interview
responsible management personnel to verify that privileges assigned are:
▪ Necessary for that individual’s job function
▪ Restricted to least privileges necessary to perform job responsibilities.
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
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.
7.2 Examine system settings and vendor documentation to verify that an access
control system(s) is implemented as follows:
7.2.1 Confirm that access control systems are in place on all system
components.
7.2.2 Confirm that access control systems are configured to enforce privileges
assigned to individuals based on job classification and function.
7.2.3 Confirm that the access control systems have a default “deny-all” setting.

policies and operational procedures for restricting access to cardholder data
are:
▪ Documented,
▪ In use, and
omponents
8.1.a Review procedures and confirm they define processes for each of the
items below at 8.1.1 through 8.1.8
8.1.b Verify that procedures are implemented for user identification

management, by performing the following:
8.1.1 Interview administrative personnel to confirm that all users are assigned a
unique ID for access to system components or cardholder data.
8.1.2 For a sample of privileged user IDs and general user IDs, examine
associated authorizations and observe system settings to verify each user ID
and privileged user ID has been implemented with only the privileges specified
on the documented approval.
8.1.3.a Select a sample of users terminated in the past six months, and review
current user access lists—for both local and remote access—to verify that their
IDs have been deactivated or removed from the access lists.
8.1.3.b Verify all physical authentication methods—such as, smart cards,

tokens, etc.—have been returned or deactivated.
8.1.4 Observe user accounts to verify that any inactive accounts over 90 days
old are either removed or disabled.
8.1.5.a Interview personnel and observe processes for managing accounts used
by third parties to access, support, or maintain system components to verify that
accounts used for remote access are:
▪ Disabled when not in use

▪ Enabled only when needed by the third party, and disabled when not in use.
Allowing vendors to have 24/7 access into your network
8.1.5.b Interview personnel and observe processes to verify that third-party

remote access accounts are monitored while being used.
8.1.6.a For a sample of system components, inspect system configuration
settings to verify that authentication parameters are set to require that user
accounts be locked out after not more than six invalid logon attempts.
8.1.6.b Additional testing procedure for service provider assessments only:

Review internal processes and customer/user documentation, and observe
implemented processes to verify that non-consumer customer user accounts
are temporarily locked-out after not more than six invalid access attempts.
8.1.7 For a sample of system components, inspect system configuration

settings to verify that password parameters are set to require that once a user
account is locked out, it remains locked for a minimum of 30 minutes or until a
system administrator resets the account.
8.1.8 For a sample of system components, inspect system configuration

settings to verify that system/session idle time out features have been set to 15
minutes or less.
8.2 To verify that users are authenticated using unique ID and additional
authentication (for example, a password/phrase) for access to the cardholder
data environment, perform the following:
▪ Examine documentation describing the authentication method(s) used.

▪ For each type of authentication method used and for each type of system
component, observe an authentication to verify authentication is functioning
consistent with documented authentication method(s).
8.2.1.a Examine vendor documentation and system configuration settings to

verify that passwords are protected with strong cryptography during
transmission and storage.
8.2.1.b For a sample of system components, examine password files to verify

that passwords are unreadable during storage.
8.2.1.c For a sample of system components, examine data transmissions to

verify that passwords are unreadable during transmission.
8.2.1.d Additional testing procedure for service provider assessments only:

Observe password files to verify that non-consumer customer passwords are
unreadable during storage.
8.2.1.e Additional testing procedure for service provider assessments only:

Observe data transmissions to verify that non-consumer customer passwords
are unreadable during transmission.
8.2.2 Examine authentication procedures for modifying authentication

credentials and observe security personnel to verify that, if a user requests a
reset of an authentication credential by phone, e-mail, web, or other non-face-
to-face method, the user’s identity is verified before the authentication credential
is modified.
8.2.3a For a sample of system components, inspect system configuration
settings to verify that user password/passphrase parameters are set to require
at least the following strength/complexity:


Review internal processes and customer/user documentation to verify that non-
consumer customer passwords/passphrases are required to meet at least the
following strength/complexity:

8.2.4.a For a sample of system components, inspect system configuration

settings to verify that user password/passphrase parameters are set to require
users to change passwords at least once every 90 days.

Review internal processes and customer/user documentation to verify that:
▪ Non-consumer customer user passwords/passphrases are required to change

periodically; and
▪ Non-consumer customer users are given guidance as to when, and under
what circumstances, passwords/passphrases must change.
8.2.5.a For a sample of system components, obtain and inspect system

configuration settings to verify that password parameters are set to require that
new passwords/passphrases cannot be the same as the four previously used
passwords/passphrases.

Review internal processes and customer/user documentation to verify that new
non-consumer customer user passwords/passphrase cannot be the same as
the previous four passwords.
8.2.6 Examine password procedures and observe security personnel to verify
that first-time passwords/passphrases for new users, and reset
passwords/passphrases for existing users, are set to a unique value for each
user and changed after first use.
8.3.1.a Examine network and/or system configurations, as applicable, to verify
multi-factor authentication is required for all non-console administrative access
into the CDE.
8.3.1.b Observe a sample of administrator personnel login to the CDE and verify
that at least two of the three authentication methods are used.
8.3.2.a Examine system configurations for remote access servers and systems
to verify multi-factor authentication is required for:
▪ All remote access by personnel, both user and administrator, and

▪ All third-party/vendor remote access (including access to applications and
system components for support or maintenance purposes).
8.3.2.b Observe a sample of personnel (for example, users and administrators)

connecting remotely to the network and verify that at least two of the three
authentication methods are used.
8.4.a Examine procedures and interview personnel to verify that authentication
policies and procedures are distributed to all users.
8.4.b Review authentication policies and procedures that are distributed to

users and verify they include:
▪ Guidance on selecting strong authentication credentials

▪ Guidance for how users should protect their authentication credentials.
▪ Instructions for users not to reuse previously used passwords
▪ Instructions to change passwords if there is any suspicion the password could
be compromised.
8.4.c Interview a sample of users to verify that they are familiar with
authentication policies and procedures.
8.5.a For a sample of system components, examine user ID lists to verify the
following:

▪ Shared user IDs for system administration activities and other critical functions
do not exist.
▪ Shared and generic user IDs are not used to administer any system
components.
8.5.b Examine authentication policies and procedures to verify that use of group
and shared IDs and/or passwords or other authentication methods are explicitly
prohibited.
8.5.c Interview system administrators to verify that group and shared IDs and/or
passwords or other authentication methods are not distributed, even if
requested.
8.5.1 Additional testing procedure for service provider assessments only:

Examine authentication policies and procedures and interview personnel to
verify that different authentication credentials are used for access to each
customer.
8.6.a Examine authentication policies and procedures to verify that procedures
for using authentication mechanisms such as physical security tokens, smart
cards, and certificates are defined and include:
▪ Authentication mechanisms are assigned to an individual account and not

shared among multiple accounts.
▪ Physical and/or logical controls are defined to ensure only the intended
account can use that mechanism to gain access.
8.6.b Interview security personnel to verify authentication mechanisms are

assigned to an account and not shared among multiple accounts.
8.6.c Examine system configuration settings and/or physical controls, as

applicable, to verify that controls are implemented to ensure only the intended
account can use that mechanism to gain access.
8.7.a Review database and application configuration settings and verify that all
users are authenticated prior to access.
Without user authentication for access to databases and applications, the
potential for unauthorized or malicious access increases, and such access
cannot be logged since the user has not been authenticated and is therefore not
known to the system. Also, database access should be granted through
programmatic methods only (for example, through stored procedures), rather
than via direct access to the database by end users (except for DBAs, who may
need direct access to the database for their administrative duties).
8.7.b Examine database and application configuration settings to verify that all
user access to, user queries of, and user actions on (for example, move, copy,
delete), the database are through programmatic methods only (for example,
through stored procedures).
8.7.c Examine database access control settings and database application

configuration settings to verify that user direct access to or queries of databases
are restricted to database administrators.
8.7.d Examine database access control settings, database application

configuration settings, and the related application IDs to verify that application
IDs can only be used by the applications (and not by individual users or other
processes).
policies and operational procedures for identification and authentication are:
 Documented,
 In use, and
 Known to all affected parties.
.
9.1 Verify the existence of physical security controls for each computer room,
data center, and other physical areas with systems in the cardholder data
environment.
▪ Verify that access is controlled with badge readers or other devices including
authorized badges and lock and key.
▪ Observe a system administrator’s attempt to log into consoles for randomly
selected systems in the cardholder data environment and verify that they are
“locked” to prevent unauthorized use.
9.1.1.a Verify that either video cameras or access control mechanisms (or both)
are in place to monitor the entry/exit points to sensitive areas.
9.1.1.b Verify that either video cameras or access control mechanisms (or both)
are protected from tampering or disabling.
9.1.1.c Verify that data from video cameras and/or access control mechanisms
is reviewed, and that data is stored for at least three months.
9.1.2 Interview responsible personnel and observe locations of publicly
accessible network jacks to verify that physical and/or logical controls are in
place to restrict access to publicly accessible network jacks.
Restricting access to network jacks (or network ports) will prevent malicious
individuals from plugging into readily available network jacks and gain access
into internal network resources.
Whether logical or physical controls, or a combination of both, are used, they
should be sufficient to prevent an individual or device that is not explicitly
authorized from being able to connect to the network.
9.1.3 Verify that physical access to wireless access points, gateways, handheld
devices, networking/communications hardware, and telecommunication lines is
appropriately restricted.
9.2.a Review documented processes to verify that procedures are defined for
identifying and distinguishing between onsite personnel and visitors.
▪ Verify procedures include the following:

▪ Identifying onsite personnel and visitors (for example, assigning badges),
▪ Changing access requirements, and
▪ Revoking terminated onsite personnel and expired visitor identification (such
as ID badges)
9.2.b Examine identification methods (such as ID badges) and observe

processes for identifying and distinguishing between onsite personnel and
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 identification process (such as a badge system) is
limited to authorized personnel.
9.3.a For a sample of onsite personnel with physical access to sensitive areas,
interview responsible personnel and observe access control lists to verify that:
▪ Access to the sensitive area is authorized.

▪ Access is required for the individual’s job function.
9.3.b Observe personnel accessing sensitive areas to verify that all personnel
are authorized before being granted access.
9.3.c Select a sample of recently terminated employees and review access

control lists to verify the personnel do not have physical access to sensitive
areas.
9.4 Verify that visitor authorization and access controls are in place as follows:
9.4.1.a Observe procedures and interview personnel to verify that visitors must
be authorized before they are granted access to, and escorted at all times
within, areas where cardholder data is processed or maintained.
9.4.1.b Observe the use of visitor badges or other identification to verify that a
physical token badge does not permit unescorted access to physical areas
where cardholder data is processed or maintained.
9.4.2.a Observe people within the facility to verify the use of visitor badges or
other identification, and that visitors are easily distinguishable from onsite
personnel.
9.4.2.b Verify that visitor badges or other identification expire.
9.4.3 Observe visitors leaving the facility to verify visitors are asked to surrender
their badge or other identification upon departure or expiration.
9.4.4.a Verify that a visitor log is in use to record physical access to the facility
as well as computer rooms and data centers where cardholder data is stored or
transmitted.
9.4.4.b Verify that the log contains:
▪ The visitor’s name,

▪ The firm represented, and
▪ The onsite personnel authorizing physical access.
9.4.4.c Verify that the log is retained for at least three months.
9.5 Verify that procedures for protecting cardholder data include controls for
physically securing all media (including but not limited to computers, removable
electronic media, paper receipts, paper reports, and faxes).
9.5.1 Verify that the storage location security is reviewed at least annually to
confirm that backup media storage is secure.
9.6 Verify that a policy exists to control distribution of media, and that the policy
covers all distributed media including that distributed to individuals.
9.6.1 Verify that all media is classified so the sensitivity of the data can be
determined.
9.6.2.a Interview personnel and examine records to verify that all media sent
outside the facility is logged and sent via secured courier or other delivery
method that can be tracked.
9.6.2.b Select a recent sample of several days of offsite tracking logs for all
media, and verify tracking details are documented.
9.6.3 Select a recent sample of several days of offsite tracking logs for all
media. From examination of the logs and interviews with responsible personnel,
verify proper management authorization is obtained whenever media is moved
from a secured area (including when media is distributed to individuals).
9.7 Obtain and examine the policy for controlling storage and maintenance of all
media and verify that the policy requires periodic media inventories.
9.7.1 Review media inventory logs to verify that logs are maintained and media
inventories are performed at least annually.
9.8 Examine the periodic media destruction policy and verify that it covers all
media and defines requirements for the following:
▪ Hard-copy materials must be crosscut shredded, incinerated, or pulped such

that there is reasonable assurance the hard-copy materials cannot be
reconstructed.
▪ Storage containers used for materials that are to be destroyed must be
secured.
▪ Cardholder data on electronic media must be rendered unrecoverable (e.g.,
via a secure wipe program in accordance with industry-accepted standards for
secure deletion, or by physically destroying the media).
9.8.1.a Interview personnel and examine procedures to verify that hard-copy

materials are crosscut shredded, incinerated, or pulped such that there is
reasonable assurance the hard-copy materials cannot be reconstructed.
9.8.1.b Examine storage containers used for materials that contain information
to be destroyed to verify that the containers are secured.
9.8.2 Verify that cardholder data on electronic media is rendered unrecoverable
(e.g., via a secure wipe program in accordance with industry-accepted
standards for secure deletion, or by physically destroying the media).
9.9 Examine documented policies and procedures to verify they include:
▪ Maintaining a list of devices

▪ Periodically inspecting devices to look for tampering or substitution
▪ Training personnel to be aware of suspicious behavior and to report tampering
or substitution of devices.
9.9.1.a Examine the list of devices to verify it includes:
▪ Make, model of device

▪ Location of device (for example, the address of the site or facility where the
device is located)
▪ Device serial number or other method of unique identification.
9.9.1.b Select a sample of devices from the list and observe devices and device
locations to verify that the list is accurate and up to date.
9.9.1.c Interview personnel to verify the list of devices is updated when devices
are added, relocated, decommissioned, etc.
9.9.2.a Examine documented procedures to verify processes are defined to
▪ Procedures for inspecting devices

▪ Frequency of inspections.
9.9.2.b Interview responsible personnel and observe inspection processes to

verify:
▪ Personnel are aware of procedures for inspecting devices.

▪ All devices are periodically inspected for evidence of tampering and
substitution.
9.9.3.a Review training materials for personnel at point-of-sale locations to verify

they include training in the following:
▪ Verifying the identity of any third-party persons claiming to be repair or

maintenance personnel, prior to granting them access to modify or troubleshoot
devices
▪ Not to install, replace, or return devices without verification
▪ Being aware of suspicious behavior around devices (for example, attempts by
unknown persons to unplug or open devices)
▪ Reporting suspicious behavior and indications of device tampering or
substitution to appropriate personnel (for example, to a manager or security
officer).
9.9.3.b Interview a sample of personnel at point-of-sale locations to verify they

have received training and are aware of the procedures for the following:
▪ Verifying the identity of any third-party persons claiming to be repair or

maintenance personnel, prior to granting them access to modify or troubleshoot
devices
▪ Being aware of suspicious behavior around devices (for example, attempts by
unknown persons to unplug or open devices)
▪ Reporting suspicious behavior and indications of device tampering or
substitution to appropriate personnel (for example, to a manager or security
officer).
policies and operational procedures for restricting physical access to cardholder
data are:
▪ Documented,
▪ In use, and
Verify, through observation and interviewing the system administrator, that:
▪ Audit trails are enabled and active for system components.

▪ Access to system components is linked to individual users.
It is critical to have a process or system that links user access to system
components accessed. This system generates audit logs and provides the
ability to trace back suspicious activity to a
Through interviews of responsible personnel, observation of audit logs, and

examination of audit log settings, perform the following:
▪ Verify all individual access to cardholder data is logged.

▪ Verify all actions taken by any individual with root or administrative privileges
are logged.
▪ Verify access to all audit trails is logged. 4) Verify invalid logical access
attempts are logged.
See Testing Procedure 10.2

Verify use of identification and authentication mechanisms is logged.
Verify all elevation of privileges is logged. 3) Verify all changes, additions, or

deletions to any account with root or administrative privileges are logged.
Verify the following are logged:
▪ Initialization of audit logs

▪ Stopping or pausing of audit logs.
Verify creation and deletion of system level objects are logged.
Through interviews and observation of audit logs, for each auditable event (from
10.2), perform the following tests outlined below for requirements 10.3.1 through
10.3.6:
Verify user identification is included in log entries.
Verify type of event is included in log entries.
Verify date and time stamp is included in log entries.
Verify success or failure indication is included in log entries.

Verify origination of event is included in log entries.
Verify identity or name of affected data, system component, or resources is

included in log entries.
Examine configuration standards and processes to verify that time-

synchronization technology is implemented and kept current per PCI DSS
Requirements 6.1 and 6.2.
Examine the process for acquiring, distributing and storing the correct time
within the organization to verify that:
▪ Only the designated central time server(s) receives time signals from external
sources, and time signals from external sources are based on International
Atomic Time or UTC.
▪ Where there is more than one designated time server, the time servers peer
with one another to keep accurate time,
▪ Systems receive time information only from designated central time server(s).
Observe the time-related system-parameter settings for a sample of system

components to verify:
▪ Only the designated central time server(s) receives time signals from external
sources, and time signals from external sources are based on International
Atomic Time or UTC.
▪ Where there is more than one designated time server, the designated central
time server(s) peer with one another to keep accurate time.
▪ Systems receive time only from designated central time server(s).
Examine system configurations and time-synchronization settings to verify that

access to time data is restricted to only personnel with a business need to
access time data.
Examine system configurations, time synchronization settings and logs, and

processes to verify that any changes to time settings on critical systems are
logged, monitored, and reviewed.
Examine systems configurations to verify that the time server(s) accept time
updates from specific, industry-accepted external sources (to prevent a
malicious individual from changing the clock). Optionally, those updates can be
encrypted with a symmetric key, and access control lists can be created that
specify the IP addresses of client machines that will be provided with the time
updates (to prevent unauthorized use of internal time servers).
Interview system administrators and examine system configurations and
permissions to verify that audit trails are secured so that they cannot be altered
as follows:
Only individuals who have a job-related need can view audit trail files.
Current audit trail files are protected from unauthorized modifications via access
control mechanisms, physical segregation, and/or network segregation.
Current audit trail files are promptly backed up to a centralized log server or
media that is difficult to alter.
Logs for external-facing technologies (for example, wireless, firewalls, DNS,
mail) are written onto a secure, centralized, internal log server or media.
Examine system settings, monitored files, and results from monitoring activities
to verify the use of file-integrity monitoring or change-detection software on logs.
The following solution description applies to requirements 10.6 through sub-

requirement 10.6.3:
Examine security policies and procedures to verify that procedures are defined
for reviewing the following at least daily, either manually or via log tools:
▪ All security events

▪ Logs of all system components that store, process, or transmit CHD and/or
SAD
▪ 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.)
Observe processes and interview personnel to verify that the following are
reviewed at least daily:
▪ All security events

▪ Logs of all system components that store, process, or transmit CHD and/or
SAD
▪ 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.).
for reviewing logs of all other system components periodically—either manually
or via log tools—based on the organization’s policies and risk management
strategy.
Examine the organization’s risk-assessment documentation and interview

personnel to verify that reviews are performed in accordance with organization’s
policies and risk management strategy.
for following up on exceptions and anomalies identified during the review
process.
Observe processes and interview personnel to verify that follow-up to

exceptions and anomalies is performed.
Examine security policies and procedures to verify that they define the following:
▪ Audit log retention policies.

▪ Procedures for retaining audit logs for at least one year, with a minimum of
three months immediately available online.
Interview personnel and examine audit logs to verify that audit logs are retained
for at least one year.
Interview personnel and observe processes to verify that at least the last three
months’ logs are immediately available for analysis.
Examine documented policies and procedures to verify that processes are

defined for the timely detection and reporting of failures of critical security
control systems, including but not limited to failure of: Firewalls, IDS/IPS, FIM,
Anti-virus, Physical, Access controls, Logical access controls, Audit logging,
Mechanisms, Segmentation controls (if used).
Examine detection and alerting processes and interview personnel to verify that
processes are implemented for all critical security controls, and that failure of a
critical security control results in the generation of an alert.
Examine documented policies and procedures and interview personnel to verify
processes are defined and implemented to respond to a security control failure,
and include: Restoring security functions. Identifying and documenting the
duration (date and time start to end) of the security failure. Identifying and
documenting cause(s) of failure, including root cause, and documenting
remediation required to address root cause. Identifying and addressing any
security issues that arose during the failure. Performing a risk assessment to
determine whether further actions are required as a result of the security failure.
Implementing controls to prevent cause of failure from reoccurring. Resuming
monitoring of security controls
Examine records to verify that security control failures are documented to

include: Identification of cause(s) of the failure, including root cause. Duration
(date and time start and end) of the security failure. Details of the remediation
required to address the root cause
Examine documentation and interview personnel to verify that security policies

and operational procedures for monitoring all access to network resources and
cardholder data are: Documented, In use, and Known to all affected parties.
es.
11.1.a Examine policies and procedures to verify processes are defined for
detection and identification of both authorized and unauthorized wireless access
points on a quarterly basis.
11.1.b Verify that the methodology is adequate to detect and identify any
unauthorized wireless access points, including at least the following:
 WLAN cards inserted into system components
 Portable or mobile devices attached to system 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 utilized, examine output from recent wireless
scans to verify that:
 Authorized and unauthorized wireless access points are identified, and
 The scan is performed at least quarterly for all system components and
facilities.
11.1.d If automated monitoring is utilized (for example, wireless IDS/IPS, NAC,
etc.), verify the configuration will generate alerts to notify personnel.
11.1.1 Examine documented records to verify that an inventory of authorized
wireless access points is maintained and a business justification is documented
for all authorized wireless access points.
11.1.2.a Examine the organization’s incident response plan (Requirement

12.10) to verify it defines and requires a response in the event that an
unauthorized wireless access point is detected.
11.1.2.b Interview responsible personnel and/or inspect recent wireless scans
and related responses to verify action is taken when unauthorized wireless
access points are found.
11.2 Examine scan reports and supporting documentation to verify that internal
and external vulnerability scans are performed as follows:
11.2.1.a Review the scan reports and verify that four quarterly internal scans
occurred in the most recent 12-month period.
11.2.1.b Review the scan reports and verify that all “high risk” vulnerabilities are
addressed and the scan process includes rescans to verify that the “high risk”
vulnerabilities (as defined in PCI DSS Requirement 6.1) are resolved.
11.2.1.c Interview personnel to verify that the scan was performed by a qualified
internal resource(s) or qualified external third party and, if applicable,
organizational independence of the tester exists (not required to be a QSA or
ASV).
11.2.2.a Review output from the four most recent quarters of external
vulnerability scans and verify that four quarterly external vulnerability scans
occurred in the most recent 12-month period.
11.2.2.b Review the results of each quarterly scan and rescan to verify that the
ASV Program Guide requirements for a passing scan have been met (for
example, no vulnerabilities rated 4.0 or higher by the CVSS, and no automatic
failures).
11.2.2.c Review the scan reports to verify that the scans were completed by a
PCI SSC Approved Scanning Vendor (ASV).
11.2.3.a Inspect and correlate change control documentation and scan reports
to verify that system components subject to any significant change were
scanned.
11.2.3.b Review scan reports and verify that the scan process includes rescans
until:
 For external scans, no vulnerabilities exist that are scored 4.0 or higher by the
CVSS.
 For internal scans, all “high risk” vulnerabilities as defined in PCI DSS
Requirement 6.1 are resolved.
11.2.3.c Validate that the scan was performed by a qualified internal resource(s)
or qualified external third party and, if applicable, organizational independence
of the tester exists (not required to be a QSA or ASV).
11.3 Examine penetration-testing methodology and interview responsible
personnel to verify a methodology is implemented that includes 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
* Testing from both inside and outside the network
* Includes testing to validate any segmentation and scope-reduction controls
* Defines application-layer penetration tests to include, at a minimum, the
vulnerabilities listed in Requirement 6.5
* Defines network-layer penetration tests to include components that support
network functions as well as operating systems
* Includes review and consideration of threats and vulnerabilities experienced in
the last 12 months
* Specifies retention of penetration testing results and remediation activities
results.
11.3.1.a Examine the scope of work and results from the most recent external
penetration test to verify that penetration testing is performed as follows:
 Per the defined methodology
 At least annually
 After any significant changes to the environment.
11.3.1.b Verify that the test was performed by a qualified internal resource or
qualified external third party and, if applicable, organizational independence of
the tester exists (not required to be a QSA or ASV).
11.3.2.a Examine the scope of work and results from the most recent internal
penetration test to verify that penetration testing is performed as follows.
11.3.2.b Verify that the test was performed by a qualified internal resource or
11.3.3 Examine penetration testing results to verify that noted exploitable
vulnerabilities were corrected and that repeated testing confirmed the
vulnerability was corrected.
11.3.4.a Examine segmentation controls and review penetration-testing

methodology to verify that penetration-testing procedures are defined to test all
segmentation methods to confirm they are operational and effective, and isolate
all out-of-scope systems from systems in the CDE.
11.3.4.b Examine the results from the most recent penetration test to verify that:
 Penetration testing to verify segmentation controls is performed at least
annually and after any changes to segmentation controls/methods.
 The penetration testing covers all segmentation controls/methods in use.
 The penetration testing verifies that segmentation controls/methods are
operational and effective, and isolate all out-of-scope systems from systems in
the CDE.
11.3.4.c Verify that the test was performed by a qualified internal resource or
11.3.4.1.a Examine the results from the most recent penetration test to verify
that:
 Penetration testing is performed to verify segmentation controls at least every
six months and after any changes to segmentation controls/methods.
 The penetration testing covers all segmentation controls/methods in use.
 The penetration testing verifies that segmentation controls/methods are
operational and effective, and isolate all out-of-scope systems from systems in
the CDE.
11.3.4.1.b Verify that the test was performed by a qualified internal resource or
11.4.a Examine system configurations and network diagrams to verify that

techniques (such as intrusion-detection systems and/or intrusion-prevention
systems) are in place to monitor all traffic:
 At the perimeter of the cardholder data environment
 At critical points in the cardholder data environment.
11.4.b Examine system configurations and interview responsible personnel to

confirm intrusion-detection and/or intrusion-prevention techniques alert
personnel of suspected compromises.
11.4.c Examine IDS/IPS configurations and vendor documentation to verify

intrusion-detection and/or intrusion-prevention techniques are configured,
maintained, and updated per vendor instructions to ensure optimal protection.
11.5.a Verify the use of a change-detection mechanism by observing system
settings and monitored files, as well as reviewing results from monitoring
activities.
Examples of files that should be monitored:
 System executables
 Application executables
 Configuration and parameter files
 Centrally stored, historical or archived, log and audit files
 Additional critical files determined by entity (for example, through risk
assessment or other means).
11.5.b Verify the mechanism is configured to alert personnel to unauthorized

modification (including changes, additions, and deletions) of critical files, and to
perform critical file comparisons at least weekly.
11.5.1 Interview personnel to verify that all alerts are investigated and resolved.

policies and operational procedures for security monitoring and testing are:
 Documented,
 In use, and
 Known to all affected parties.
sting Providers
Guidance
Firewalls and routers are key components of the architecture that controls
entry to and exit from the network. These devices are software or
hardware devices that block unwanted access and manage authorized
access into and out of the network.
Configuration standards and procedures will help to ensure that the
organization’s first line of defense in the protection of its data remains
strong.
A documented and implemented process for approving and testing all

connections and changes to the firewalls and routers will help prevent
security problems caused by misconfiguration of the network, router, or
firewall.
Without formal approval and testing of changes, records of the changes
might not be updated, which could lead to inconsistencies between
network documentation and the actual configuration.
Network diagrams describe how networks are configured, and identify the
location of all network devices.
Without current network diagrams, devices could be overlooked and be
unknowingly left out of the security controls implemented for PCI DSS and
thus be vulnerable to compromise.
Cardholder data-flow diagrams identify the location of all cardholder data

that is stored, processed, or transmitted within the network.
Network and cardholder data-flow diagrams help an organization to
understand and keep track of the scope of their environment, by showing
how cardholder data flows across networks and between individual
systems and devices.
Using a firewall on every Internet connection coming into (and out of) the
network, and between any DMZ and the internal network, allows the
organization to monitor and control access and minimizes the chances of a
malicious individual obtaining access to the internal network via an
unprotected connection.
This description of roles and assignment of responsibilities ensures that

personnel are aware of who is responsible for the security of all network
components, and that those assigned to manage components are aware
of their responsibilities. If roles and responsibilities are not formally
assigned, devices could be left unmanaged.
Compromises often happen due to unused or insecure service and ports,
since these often have known vulnerabilities and many organizations don’t
patch vulnerabilities for the services, protocols, and ports they don't use
(even though the vulnerabilities are still present). By clearly defining and
documenting the services, protocols, and ports that are necessary for
business, organizations can ensure that all other services, protocols, and
ports are disabled or removed.
Approvals should be granted by personnel independent of the personnel
managing the configuration.
If insecure services, protocols, or ports are necessary for business, the risk
posed by use of these protocols should be clearly understood and
accepted by the organization, the use of the protocol should be justified,
and the security features that allow these protocols to be used securely
should be documented and implemented. If these insecure services,
protocols, or ports are not necessary for business, they should be disabled
or removed.
For guidance on services, protocols, or ports considered to be insecure,
refer to industry standards and guidance (e.g., NIST, ENISA, OWASP,
etc.).
This review gives the organization an opportunity at least every six months
to clean up any unneeded, outdated, or incorrect rules, and ensure that all
rule sets allow only authorized services and ports that match the
documented business justifications.
Organizations with a high volume of changes to firewall and router rule
sets may wish to consider performing reviews more frequently, to ensure
that the rule sets continue to meet the needs of the business.
It is essential to install network protection between the internal, trusted

network and any untrusted network that is external and/or out of the
entity’s ability to control or manage. Failure to implement this measure
correctly results in the entity being vulnerable to unauthorized access by
malicious individuals or software.
For firewall functionality to be effective, it must be properly configured to
control and/or limit traffic into and out of the entity’s network.
Examination of all inbound and outbound connections allows for inspection
and restriction of traffic based on the source and/or destination address,
thus preventing unfiltered access between untrusted and trusted
environments. This prevents malicious individuals from accessing the
entity’s network via unauthorized IP addresses or from using services,
protocols, or ports in an unauthorized manner (for example, to send data
they've obtained from within the entity’s network out to an untrusted
server).
Implementing a rule that denies all inbound and outbound traffic that is not
specifically needed helps to prevent inadvertent holes that would allow
unintended and potentially harmful traffic in or out.
While the running (or active) router configuration files include the current,
secure settings, the start-up files (which are used when routers are re-
started or booted) must be updated with the same secure settings to
ensure these settings are applied when the start-up configuration is run.
Because they only run occasionally, start-up configuration files are often
forgotten and are not updated. When a router re-starts and loads a start-up
configuration that has not been updated with the same secure settings as
those in the running configuration, it may result in weaker rules that allow
malicious individuals into the network.
The known (or unknown) implementation and exploitation of wireless

technology within a network is a common path for malicious individuals to
gain access to the network and cardholder data. If a wireless device or
network is installed without the entity’s knowledge, a malicious individual
could easily and “invisibly” enter the network. If firewalls do not restrict
access from wireless networks into the CDE, malicious individuals that
gain unauthorized access to the wireless network can easily connect to the
CDE and compromise account information.
Firewalls must be installed between all wireless networks and the CDE,
regardless of the purpose of the environment to which the wireless network
is connected. This may include, but is not limited to, corporate networks,
retail stores, guest networks, warehouse environments, etc.
While there may be legitimate reasons for untrusted connections to be
permitted to DMZ systems (e.g., to allow public access to a web server),
such connections should never be granted to systems in the internal
network. A firewall's intent is to manage and control all connections
between public systems and internal systems, especially those that store,
process or transmit cardholder data. If direct access is allowed between
public systems and the CDE, the protections offered by the firewall are
bypassed, and system components storing cardholder data may be
exposed to compromise.
Normally a packet contains the IP address of the computer that originally
sent it so other computers in the network know where the packet came
from. Malicious individuals will often try to spoof (or imitate) the sending IP
address so that the target system believes the packet is from a trusted
source. Filtering packets coming into the network helps to, among other
things, ensure packets are not “spoofed” to look like they are coming from
an organization’s own internal network.
All traffic outbound from the cardholder data environment should be

evaluated to ensure that it follows established, authorized rules.
Connections should be inspected to restrict traffic to only authorized
communications (for example by restricting source/destination
addresses/ports, and/or blocking of content).
A firewall that maintains the "state" (or the status) for each connection
through the firewall knows whether an apparent response to a previous
connection is actually a valid, authorized response (since it retains each
connection’s status) or is malicious traffic trying to trick the firewall into
allowing the connection.
If cardholder data is located within the DMZ, it is easier for an external

attacker to access this information, since there are fewer layers to
penetrate. Securing system components that store cardholder data in an
internal network zone that is segregated from the DMZ and other untrusted
networks by a firewall can prevent unauthorized network traffic from
reaching the system component. Note: This requirement is not intended to
apply to temporary storage of cardholder data in volatile memory.
Restricting the disclosure of internal or private IP addresses is essential to
prevent a hacker “learning” the IP addresses of the internal network, and
using that information to access the network.
Methods used to meet the intent of this requirement may vary depending
on the specific networking technology being used. For example, the
controls used to meet this requirement may be different for IPv4 networks
than for IPv6 networks.
Portable computing devices that are allowed to connect to the Internet

from outside the corporate firewall are more vulnerable to Internet-based
threats. Use of firewall functionality (e.g., personal firewall software or
hardware) helps to protect devices from Internet-based attacks, which
could use the device to gain access the organization’s systems and data
once the device is re-connected to the network.
The specific firewall configuration settings are determined by the
organization.
Note: This requirement applies to employee-owned and company-owned

portable computing devices. Systems that cannot be managed by
corporate policy introduce weaknesses and provide opportunities that
malicious individuals may exploit. Allowing untrusted systems to connect to
an organization’s CDE could result in access being granted to attackers
and other malicious users.
operational procedures to ensure firewalls and routers are continuously
managed to prevent unauthorized access to the network.
Malicious individuals (external and internal to an organization) often use

vendor default settings, account names, and passwords to compromise
operating system software, applications, and the systems on which they
are installed. Because these default settings are often published and are
well known in hacker communities, changing these settings will leave
systems less vulnerable to attack.
Even if a default account is not intended to be used, changing the default
password to a strong unique password and then disabling the account will
prevent a malicious individual from re-enabling the account and gaining
access with the default password.
If wireless networks are not implemented with sufficient security
configurations (including changing default settings), wireless sniffers can
eavesdrop on the traffic, easily capture data and passwords, and easily
enter and attack the network.
In addition, the key-exchange protocol for older versions of 802.11x
encryption (Wired Equivalent Privacy, or WEP) has been broken and can
render the encryption useless. Firmware for devices should be updated to
support more secure protocols.
There are known weaknesses with many operating systems, databases,
and enterprise applications, and there are also known ways to configure
these systems to fix security vulnerabilities. To help those that are not
security experts, a number of security organizations have established
system-hardening guidelines and recommendations, which advise how to
correct these weaknesses.
Examples of sources for guidance on configuration standards include, but
are not limited to: www.nist.gov, www.sans.org, and www.cisecurity.org,
www.iso.org, and product vendors.
System configuration standards must be kept up to date to ensure that
newly identified weaknesses are corrected prior to a system being installed
on the network.
If server functions that need different security levels are located on the
same server, the security level of the functions with higher security needs
would be reduced due to the presence of the lower-security functions.
Additionally, the server functions with a lower security level may introduce
security weaknesses to other functions on the same server. By considering
the security needs of different server functions as part of the system
configuration standards and related processes, organizations can ensure
that functions requiring different security levels don’t co-exist on the same
server.
As stated in Requirement 1.1.6, there are many protocols that a business

may need (or have enabled by default) that are commonly used by
malicious individuals to compromise a network. Including this requirement
as part of an organization's configuration standards and related processes
ensures that only the necessary services and protocols are enabled.
Enabling security features before new servers are deployed will prevent
servers being installed into the environment with insecure configurations.
Ensuring that all insecure services, protocols, and daemons are
adequately secured with appropriate security features makes it more
difficult for malicious individuals to take advantage of commonly used
points of compromise within a network.
cryptography and secure protocols (e.g., NIST SP 800-52 and SP 800-57,
OWASP, etc.).
System configuration standards and related processes should specifically

address security settings and parameters that have known security
implications for each type of system in use.
In order for systems to be configured securely, personnel responsible for
configuration and/or administering systems must be knowledgeable in the
specific security parameters and settings that apply to the system.
Unnecessary functions can provide additional opportunities for malicious

individuals to gain access to a system. By removing unnecessary
functionality, organizations can focus on securing the functions that are
required and reduce the risk that unknown functions will be exploited.
Including this in server-hardening standards and processes addresses the
specific security implications associated with unnecessary functions (for
example, by removing/disabling FTP or the web server if the server will not
be performing those functions).
If non-console (including remote) administration does not use secure
authentication and encrypted communications, sensitive administrative or
operational level information (like administrator’s IDs and passwords) can
be revealed to an eavesdropper. A malicious individual could use this
information to access the network, become administrator, and steal data.
Clear-text protocols (such as HTTP, telnet, etc.) do not encrypt traffic or
logon details, making it easy for an eavesdropper to intercept this
information.
To be considered “strong cryptography,” industry-recognized protocols with
appropriate key strengths and key management should be in place as
applicable for the type of technology in use. (Refer to "strong
cryptography” in the PCI DSS and PA-DSS Glossary of Terms,
Abbreviations, and Acronyms, and industry standards and best practices
such as NIST SP 800-52 and SP 800-57, OWASP, etc.)
Maintaining a current list of all system components will enable an

organization to accurately and efficiently define the scope of their
environment for implementing PCI DSS controls. Without an inventory,
some system components could be forgotten, and be inadvertently
excluded from the organization’s configuration standards.
Personnel need to be aware of and following security policies and daily

operational procedures to ensure vendor defaults and other security
parameters are continuously managed to prevent insecure configurations.
This is intended for hosting providers that provide shared hosting

environments for multiple clients on the same server. When all data is on
the same server and under control of a single environment, often the
settings on these shared servers are not manageable by individual clients.
This allows clients to add insecure functions and scripts that impact the
security of all other client environments; and thereby make it easy for a
malicious individual to compromise one client's data and thereby gain
access to all other clients' data. See Appendix A1 for details of
requirements
A formal data retention policy identifies what data needs to be retained,
and where that data resides so it can be securely destroyed or deleted as
soon as it is no longer needed.
The only cardholder data that may be stored after authorization is the
primary account number or PAN (rendered unreadable), expiration date,
cardholder name, and service code.
Understanding where cardholder data is located is necessary so it can be
properly retained or disposed of when no longer needed. In order to define
appropriate retention requirements, an entity first needs to understand
their own business needs as well as any legal or regulatory obligations that
apply to their industry, and/or that apply to the type of data being retained.
Identifying and deleting stored data that has exceeded its specified
retention period prevents unnecessary retention of data that is no longer
needed. This process may be automated or manual or a combination of
both. For example, a programmatic procedure (automatic or manual) to
locate and remove data and/or a manual review of data storage areas
could be performed.
Implementing secure deletion methods ensure that the data cannot be
retrieved when it is no longer needed. Remember, if you don't need it,
don't store it!
Sensitive authentication data consists of full track data, card validation

code or value, and PIN data. Storage of sensitive authentication data after
authorization is prohibited! This data is very valuable to malicious
individuals as it allows them to generate counterfeit payment cards and
Entities that issue payment cards or that perform or support issuing
services will often create and control sensitive authentication data as part
of the issuing function. It is allowable for companies that perform, facilitate,
or support issuing services to store sensitive authentication data ONLY IF
they have a legitimate business need to store such data.
It should be noted that all PCI DSS requirements apply to issuers, and the
only exception for issuers and issuer processors is that sensitive
authentication data may be retained if there is a legitimate reason to do so.
A legitimate reason is one that is necessary for the performance of the
function being provided for the issuer and not one of convenience. Any
such data must be stored securely and in accordance with all PCI DSS
and specific payment brand requirements.
For non-issuing entities, retaining sensitive authentication data post-
authorization is not permitted.
If full track data is stored, malicious individuals who obtain that data can
use it to reproduce payment cards and complete fraudulent transactions.
The purpose of the card validation code is to protect "card-not-present"

transactions—Internet or mail order/telephone order (MO/TO) transactions
—where the consumer and the card are not present.
If this data is stolen, malicious individuals can execute fraudulent Internet
and MO/TO transactions.
These values should be known only to the card owner or bank that issued
the card. If this data is stolen, malicious individuals can execute fraudulent
PIN-based debit transactions (for example, ATM withdrawals).
The display of full PAN on items such as computer screens, payment card
receipts, faxes, or paper reports can result in this data being obtained by
unauthorized individuals and used fraudulently. Ensuring that full PAN is
only displayed for those with a legitimate business need to see the full PAN
minimizes the risk of unauthorized persons gaining access to PAN data.
The masking approach should always ensure that only the minimum
number of digits is displayed as necessary to perform a specific business
function. For example, if only the last four digits are needed to perform a
business function, mask the PAN so that individuals performing that
function can view only the last four digits. As another example, if a function
needs access to the bank identification number (BIN) for routing purposes,
unmask only the BIN digits (traditionally the first six digits) during that
function.
This requirement relates to protection of PAN displayed on screens, paper
receipts, printouts, etc., and is not to be confused with Requirement 3.4 for
protection of PAN when stored in files, databases, etc.
PANs stored in primary storage (databases, or flat files such as text files
spreadsheets) as well as non-primary storage (backup, audit logs,
exception or troubleshooting logs) must all be protected.
One-way hash functions based on strong cryptography can be used to
render cardholder data unreadable. Hash functions are appropriate when
there is no need to retrieve the original number (one-way hashes are
irreversible). It is recommended, but not currently a requirement, that an
additional, random input value be added to the cardholder data prior to
hashing to reduce the feasibility of an attacker comparing the data against
(and deriving the PAN from) tables of pre-computed hash values.
The intent of truncation is to permanently remove a segment of PAN data
so that only a portion (generally not to exceed the first six and last four
digits) of the PAN is stored.
An index token is a cryptographic token that replaces the PAN based on a
given index for an unpredictable value. A one-time pad is a system in
which a randomly generated private key is used only once to encrypt a
message that is then decrypted using a matching one-time pad and key.
The intent of strong cryptography (as defined in the PCI DSS and PA-DSS
Glossary of Terms, Abbreviations, and Acronyms) is that the encryption be
based on an industry-tested and accepted algorithm (not a proprietary or
"home-grown" algorithm) with strong cryptographic keys.
By correlating hashed and truncated versions of a given PAN, a malicious
individual may easily derive the original PAN value. Controls that prevent
the correlation of this data will help ensure that the original PAN remains
unreadable.
The intent of this requirement is to address the acceptability of disk-level
encryption for rendering cardholder data unreadable. Disk-level encryption
encrypts the entire disk/partition on a computer and automatically decrypts
the information when an authorized user requests it. Many disk-encryption
solutions intercept operating system read/write operations and carry out
the appropriate cryptographic transformations without any special action by
the user other than supplying a password or pass phrase upon system
startup or at the beginning of a session. Based on these characteristics of
disk-level encryption, to be compliant with this requirement, the method
cannot:
1) Use the same user account authenticator as the operating system, or
2) Use a decryption key that is associated with or derived from the
system’s local user account database or general network login credentials.
Full disk encryption helps to protect data in the event of physical loss of a
disk and therefore may be appropriate for portable devices that store
cardholder data.
Cryptographic keys must be strongly protected because those who obtain

access will be able to decrypt data. Key-encrypting keys, if used, must be
at least as strong as the data-encrypting key in order to ensure proper
protection of the key that encrypts the data as well as the data encrypted
with that key.
The requirement to protect keys from disclosure and misuse applies to
both data-encrypting keys and key-encrypting keys. Because one key-
encrypting key may grant access to many data-encrypting keys, the key-
encrypting keys require strong protection measures.
Entity being assessed is a service provider.

Maintaining current documentation of the cryptographic architecture
enables an entity to understand the algorithms, protocols, and
cryptographic keys used to protect cardholder data, as well as the devices
that generate, use and protect the keys. This allows an entity to keep pace
with evolving threats to their architecture, enabling them to plan for
updates as the assurance levels provided by different algorithms/key
strengths changes. Maintaining such documentation also allows an entity
to detect lost or missing keys or key-management devices, and identify
unauthorized additions to their cryptographic architecture.
There should be very few who have access to cryptographic keys
(reducing the potential for rending cardholder data visible by unauthorized
parties), usually only those who have key custodian responsibilities.
Cryptographic keys must be stored securely to prevent unauthorized or

unnecessary access that could result in the exposure of cardholder data.
It is not intended that the key-encrypting keys be encrypted, however they
are to be protected against disclosure and misuse as defined in
Requirement 3.5. If key-encrypting keys are used, storing the key-
encrypting keys in physically and/or logically separate locations from the
data-encrypting keys reduces the risk of unauthorized access to both keys
Storing cryptographic keys in the fewest locations helps an organization to

keep track and monitor all key locations, and minimizes the potential for
keys to be exposed to unauthorized parties
The manner in which cryptographic keys are managed is a critical part of
the continued security of the encryption solution. A good key-management
process, whether it is manual or automated as part of the encryption
product, is based on industry standards and addresses all key elements at
3.6.1 through 3.6.8.
Providing guidance to customers on how to securely transmit, store and
update cryptographic keys can help prevent keys from being mismanaged
or disclosed to unauthorized entities.
This requirement applies to keys used to encrypt stored cardholder data,
and any respective key-encrypting keys. Note: Testing Procedure 3.6.a is
an additional procedure that only applies if the entity being assessed is a
service provider.
The encryption solution must generate strong keys, as defined in the PCI
DSS and PA-DSS Glossary of Terms, Abbreviations, and Acronyms under
"Cryptographic Key Generation." Use of strong cryptographic keys
significantly increases the level of security of encrypted cardholder data.
The encryption solution must distribute keys securely, meaning the keys
are distributed only to custodians identified in 3.5.1, and are never
distributed in the clear.
The encryption solution must store keys securely, for example, by

encrypting them with a key-encrypting key. Storing keys without proper
protection could provide access to attackers, resulting in the decryption
and exposure of cardholder data.
A cryptoperiod is the time span during which a particular cryptographic key
can be used for its defined purpose. Considerations for defining the
cryptoperiod include, but are not limited to, the strength of the underlying
algorithm, size or length of the key, risk of key compromise, and the
sensitivity of the data being encrypted.
Periodic changing of encryption keys when the keys have reached the end
of their cryptoperiod is imperative to minimize the risk of someone’s
obtaining the encryption keys, and using them to decrypt data
Keys that are no longer used or needed, or keys that are known or
suspected to be compromised, should be revoked and/or destroyed to
ensure that the keys can no longer be used. If such keys need to be kept
(for example, to support archived, encrypted data) they should be strongly
protected.
The encryption solution should provide for and facilitate a process to
replace keys that are due for replacement or that are known to be, or
suspected of being, compromised.
Split knowledge and dual control of keys are used to eliminate the
possibility of one person having access to the whole key. This control is
applicable for manual key-management operations, or where key
management is not implemented by the encryption product.
Split knowledge is a method in which two or more people separately have
key components, where each person knows only their own key
component, and the individual key components convey no knowledge of
the original cryptographic key.
Dual control requires two or more people to perform a function, and no
single person can access or use the authentication materials of another.
The encryption solution should not allow for or accept substitution of keys
coming from unauthorized sources or unexpected processes.
This process will help ensure individuals that act as key custodians commit
to the key-custodian role and understand and accept the responsibilities.

documented operational procedures for managing the secure storage of
cardholder data on a continuous basis.
Sensitive information must be encrypted during transmission over public
networks, because it is easy and common for a malicious individual to
intercept and/or divert data while in transit.
Secure transmission of cardholder data requires using trusted
keys/certificates, a secure protocol for transport, and proper encryption
strength to encrypt cardholder data. Connection requests from systems
that do not support the required encryption strength, and that would result
in an insecure connection, should not be accepted.
Note that some protocol implementations (such as SSL, SSH v1.0, and
early TLS) have known vulnerabilities that an attacker can use to gain
control of the affected system. Whichever security protocol is used, ensure
it is configured to use only secure versions and configurations to prevent
use of an insecure connection—for example, by using only trusted
certificates and supporting only strong encryption (not supporting weaker,
insecure protocols or methods).
Verifying that certificates are trusted (for example, have not expired and
are issued from a trusted source) helps ensure the integrity of the secure
connection.
Generally, the web page URL should begin with "HTTPS" and/or the web
browser display a padlock icon somewhere in the window of the browser.
Many TLS certificate vendors also provide a highly visible verification seal
—sometimes referred to as a “security seal,” "secure site seal," or “secure
trust seal”)—which may provide the ability to click on the seal to reveal
information about the website.
cryptography and secure protocols (e.g., NIST SP 800-52 and SP 800-57,
OWASP, etc.)
Malicious users use free and widely available tools to eavesdrop on

wireless communications. Use of strong cryptography can help limit
disclosure of sensitive information across wireless networks.
Strong cryptography for authentication and transmission of cardholder data
is required to prevent malicious users from gaining access to the wireless
network or utilizing wireless networks to access other internal networks or
data.
E-mail, instant messaging, SMS, and chat can be easily intercepted by
packet-sniffing during delivery across internal and public networks. Do not
utilize these messaging tools to send PAN unless they are configured to
provide strong encryption.
Additionally, if an entity requests PAN via end-user messaging
technologies, the entity should provide a tool or method to protect these
PANs using strong cryptography or render PANs unreadable before
transmission.

operational procedures for managing the secure transmission of
cardholder data on a continuous basis

vulnerability), against otherwise secured systems. Without an anti-virus
solution that is updated regularly, these new forms of malicious software
can attack systems, disable a network, or lead to compromise of data.
It is important to protect against ALL types and forms of malicious software.
Typically, mainframes, mid-range computers (such as AS/400) and similar

systems may not currently be commonly targeted or affected by malware.
However, industry trends for malicious software can change quickly, so it is
important for organizations to be aware of new malware that might affect
their systems—for example, by monitoring vendor security notices and
anti-virus news groups to determine whether their systems might be
coming under threat from new and evolving malware.
Trends in malicious software should be included in the identification of new
security vulnerabilities, and methods to address new trends should be
incorporated into the company's configuration standards and protection
mechanisms as needed
Even the best anti-virus solutions are limited in effectiveness if they are not
maintained and kept current with the latest security updates, signature
files, or malware protections.
Audit logs provide the ability to monitor virus and malware activity and anti-
malware reactions. Thus, it is imperative that anti-malware solutions be
configured to generate audit logs and that these logs be managed in
accordance with Requirement 10.
Anti-virus that continually runs and is unable to be altered will provide
persistent security against malware.
Use of policy-based controls on all systems to ensure anti-malware
protections cannot be altered or disabled will help prevent system
weaknesses from being exploited by malicious software.
Additional security measures may also need to be implemented for the
period of time during which anti-virus protection is not active—for example,
disconnecting the unprotected system from the Internet while the anti-virus
protection is disabled, and running a full scan after it is re-enabled.

operational procedures to ensure systems are protected from malware on
a continuous basis.
The intent of this requirement is that organizations keep up to date with

new vulnerabilities that may impact their environment.
Sources for vulnerability information should be trustworthy and often
include vendor websites, industry news groups, mailing list, or RSS feeds.
Once an organization identifies a vulnerability that could affect their
environment, the risk that the vulnerability poses must be evaluated and
ranked. The organization must therefore have a method in place to
evaluate vulnerabilities on an ongoing basis and assign risk rankings to
those vulnerabilities. This is not achieved by an ASV scan or internal
vulnerability scan, rather this requires a process to actively monitor
industry sources for vulnerability information.
Classifying the risks (for example, as “high,” “medium,” or “low”) allows
organizations to identify, prioritize, and address the highest risk items more
quickly and reduce the likelihood that vulnerabilities posing the greatest
risk will be exploited.
vulnerability), against otherwise secured systems. If the most recent
patches are not implemented on critical systems as soon as possible, a
malicious individual can use these exploits to attack or disable a system, or
gain access to sensitive data.
Prioritizing patches for critical infrastructure ensures that high-priority
systems and devices are protected from vulnerabilities as soon as possible
after a patch is released. Consider prioritizing patch installations such that
security patches for critical or at-risk systems are installed within 30 days,
and other lower-risk patches are installed within 2-3 months.
This requirement applies to applicable patches for all installed software,
including payment applications (both those that are PA-DSS validated and
those that are not).
Without the inclusion of security during the requirements definition, design,

analysis, and testing phases of software development, security
vulnerabilities can be inadvertently or maliciously introduced into the
Understanding how sensitive data is handled by the application—including
when stored, transmitted, and when in memory—can help identify where
data needs to be protected.
Development, test and/or custom application accounts, user IDs, and

passwords should be removed from production code before the application
becomes active or is released to customers, since these items may give
away information about the functioning of the application. Possession of
such information could facilitate compromise of the application and related
cardholder data.
Security vulnerabilities in custom code are commonly exploited by
malicious individuals to gain access to a network and compromise
cardholder data.
An individual knowledgeable and experienced in code-review techniques
should be involved in the review process. Code reviews should be
performed by someone other than the developer of the code to allow for an
independent, objective review. Automated tools or processes may also be
used in lieu of manual reviews, but keep in mind that it may be difficult or
even impossible for an automated tool to identify some coding issues.
Correcting coding errors before the code is deployed into a production
environment or released to customers prevents the code exposing the
environments to potential exploit. Faulty code is also far more difficult and
expensive to address after it has been deployed or released into
production environments.
Including a formal review and signoff by management prior to release
helps to ensure that code is approved and has been developed in
accordance with policies and procedures.
Without properly documented and implemented change controls, security

features could be inadvertently or deliberately omitted or rendered
inoperable, processing irregularities could occur, or malicious code could
be introduced.
Due to the constantly changing state of development and test
environments, they tend to be less secure than the production
environment. Without adequate separation between environments, it may
be possible for the production environment, and cardholder data, to be
compromised due to less-stringent security configurations and possible
vulnerabilities in a test or development environment.
Reducing the number of personnel with access to the production

environment and cardholder data minimizes risk and helps ensure that
access is limited to those individuals with a business need to know.
The intent of this requirement is to separate development and test
functions from production functions. For example, a developer may use an
administrator-level account with elevated privileges in the development
environment, and have a separate account with user-level access to the
Security controls are usually not as stringent in test or development

environments. Use of production data provides malicious individuals with
the opportunity to gain unauthorized access to production data (cardholder
data).
Test data and accounts should be removed before the system component
becomes active (in production), since these items may give away
information about the functioning of the application or system. Possession
of such information could facilitate compromise of the system and related
cardholder data.
If not properly managed, the impact of system changes—such as
hardware or software updates and installation of security patches—might
not be fully realized and could have unintended consequences.
The impact of the change should be documented so that all affected

parties can plan appropriately for any processing changes.
Approval by authorized parties indicates that the change is a legitimate

and approved change sanctioned by the organization.
Thorough testing should be performed to verify that the security of the
environment is not reduced by implementing a change. Testing should
validate that all existing security controls remain in place, are replaced with
equally strong controls, or are strengthened after any change to the
environment.
For each change, there should be documented back-out procedures in

case the change fails or adversely affects the security of an application or
system, to allow the system to be restored back to its previous state.
Having processes to analyze significant changes helps ensure that all

appropriate PCI DSS controls are applied to any systems or networks
added or changed within the in-scope environment.
Building this validation into change management processes helps ensure
that device inventories and configuration standards are kept up to date and
security controls are applied where needed.
A change management process should include supporting evidence that
PCI DSS requirements are implemented or preserved through the iterative
process. Examples of PCI DSS requirements that could be impacted
 Network diagram is updated to reflect changes.
 Systems are configured per configuration standards, with all default
passwords changed and unnecessary services disabled.
 Systems are protected with required controls—e.g., file-integrity
monitoring (FIM), anti-virus, patches, audit logging.
 Sensitive authentication data (SAD) is not stored and all cardholder data
(CHD) storage is documented and incorporated into data-retention policy
and procedures
 New systems are included in the quarterly vulnerability scanning
process.
The application layer is high-risk and may be targeted by both internal and
external threats.
Requirements 6.5.1 through 6.5.10 are the minimum controls that should
be in place, and organizations should incorporate the relevant secure
coding practices as applicable to the particular technology in their
environment.
Application developers should be properly trained to identify and resolve
issues related to these (and other) common coding vulnerabilities. Having
staff knowledgeable of secure coding guidelines should minimize the
number of security vulnerabilities introduced through poor coding
practices. Training for developers may be provided in-house or by third
parties and should be applicable for technology used.
As industry-accepted secure coding practices change, organizational
coding practices and developer training should likewise be updated to
address new threats—for example, memory scraping attacks.
The vulnerabilities identified in 6.5.1 through 6.5.10 provide a minimum
baseline. It is up to the organization to remain up to date with vulnerability
trends and incorporate appropriate measures into their secure coding
practices.
Injection flaws, particularly SQL injection, are a commonly used method for
compromising applications. Injection occurs when user-supplied data is
sent to an interpreter as part of a command or query. The attacker's hostile
data tricks the interpreter into executing unintended commands or
changing data, and allows the attacker to attack components inside the
network through the application, to initiate attacks such as buffer
overflows, or to reveal both confidential information and server application
functionality.
Information should be validated before being sent to the application—for
example, by checking for all alpha characters, mix of alpha and numeric
characters, etc.
Buffer overflows occur when an application does not have appropriate
bounds checking on its buffer space. This can cause the information in the
buffer to be pushed out of the buffer’s memory space and into executable
memory space. When this occurs, the attacker has the ability to insert
malicious code at the end of the buffer and then push that malicious code
into executable memory space by overflowing the buffer. The malicious
code is then executed and often enables the attacker remote access to the
application and/or infected system.
Applications that do not utilize strong cryptographic functions properly to
store data are at increased risk of being compromised, and exposing
authentication credentials and/or cardholder data. If an attacker is able to
exploit weak cryptographic processes, they may be able to gain clear-text
access to encrypted data.
Applications that fail to adequately encrypt network traffic using strong
cryptography are at increased risk of being compromised and exposing
cardholder data. If an attacker is able to exploit weak cryptographic
processes, they may be able to gain control of an application or even gain
clear-text access to encrypted data.
Applications can unintentionally leak information about their configuration
or internal workings, or expose privileged information through improper
error handling methods. Attackers use this weakness to steal sensitive
data or compromise the system altogether. If a malicious individual can
create errors that the application does not handle properly, they can gain
detailed system information, create denial-of-service interruptions, cause
security to fail, or crash the server. For example, the message "incorrect
password provided" tells an attacker the user ID provided was accurate
and that they should focus their efforts only on the password. Use more
generic error messages, like "data could not be verified."
All vulnerabilities identified by an organization’s vulnerability risk-ranking
process (defined in Requirement 6.1) to be “high risk” and that could affect
the application should be identified and addressed during application
development.
XSS flaws occur whenever an application takes user-supplied data and
sends it to a web browser without first validating or encoding that content.
XSS allows attackers to execute script in the victim's browser, which can
hijack user sessions, deface web sites, possibly introduce worms, etc.
A direct object reference occurs when a developer exposes a reference to
an internal implementation object, such as a file, directory, database
record, or key, as a URL or form parameter. Attackers can manipulate
those references to access other objects without authorization.
Consistently enforce access control in presentation layer and business
logic for all URLs. Frequently, the only way an application protects
sensitive functionality is by preventing the display of links or URLs to
unauthorized users. Attackers can use this weakness to access and
perform unauthorized operations by accessing those URLs directly.
An attacker may be able to enumerate and navigate the directory structure
of a website (directory traversal) thus gaining access to unauthorized
information as well as gaining further insight into the workings of the site
for later exploitation.
If user interfaces permit access to unauthorized functions, this access
could result in unauthorized individuals gaining access to privileged
credentials or cardholder data. Only authorized users should be permitted
to access direct object references to sensitive resources. Limiting access
to data resources will help prevent cardholder data from being presented
to unauthorized resources.
A CSRF attack forces a logged-on victim's browser to send a pre-
authenticated request to a vulnerable web application, which then enables
the attacker to perform any state-changing operations the victim is
authorized to perform (such as updating account details, making
purchases, or even authenticating to the application).
Secure authentication and session management prevents unauthorized
individuals from compromising legitimate account credentials, keys, or
session tokens that would otherwise enable the intruder to assume the
identity of an authorized user.
Public-facing web applications are primary targets for attackers, and poorly
coded web applications provide an easy path for attackers to gain access
to sensitive data and systems. The requirement for reviewing applications
or installing web-application firewalls is intended to reduce the number of
compromises on public-facing web applications due to poor coding or
application management practices.
 Manual or automated vulnerability security assessment tools or methods
review and/or test the application for vulnerabilities
 Web-application firewalls filter and block non-essential traffic at the
application layer. Used in conjunction with a network-based firewall, a
properly configured web-application firewall prevents application-layer
attacks if applications are improperly coded or configured. This can be
achieved through a combination of technology and process. Process-
based solutions must have mechanisms that facilitate timely responses to
alerts in order to meet the intent of this requirement, which is to prevent
attacks. Note: “An organization that specializes in application security” can
be either a third-party company or an internal organization, as long as the
reviewers specialize in application security and can demonstrate
independence from the development team.

operational procedures to ensure systems and applications are securely
developed and protected
The more people who have access to cardholder data, the more risk there
is that a user’s account will be used maliciously. Limiting access to those
with a legitimate business reason for the access helps an organization
prevent mishandling of cardholder data through inexperience or malice.
In order to limit access to cardholder data to only those individuals who
need such access, first it is necessary to define access needs for each role
(for example, system administrator, call center personnel, store clerk), the
systems/devices/data each role needs access to, and the level of privilege
each role needs to effectively perform assigned tasks. Once roles and
corresponding access needs are defined, individuals can be granted
access accordingly.
When assigning privileged IDs, it is important to assign individuals only the

privileges they need to perform their job (the “least privileges”). For
example, the database administrator or backup administrator should not
be assigned the same privileges as the overall systems administrator.
Assigning least privileges helps prevent users without sufficient knowledge
about the application from incorrectly or accidentally changing application
configuration or altering its security settings. Enforcing least privilege also
helps to minimize the scope of damage if an unauthorized person gains
access to a user ID.
Once needs are defined for user roles (per PCI DSS requirement 7.1.1), it
is easy to grant individuals access according to their job classification and
function by using the already-created roles.
Documented approval (for example, in writing or electronically) assures

that those with access and privileges are known and authorized by
management, and that their access is necessary for their job function
Without a mechanism to restrict access based on user’s need to know, a

Without a mechanism to restrict access based on user’s need to know, a

operational procedures to ensure that access is controlled and based on
need-to-know and least privilege, on a continuous basis.
By ensuring each user is uniquely identified—instead of using one ID for

several employees—an organization can maintain individual responsibility
for actions and an effective audit trail per employee. This will help speed
issue resolution and containment when misuse or malicious intent occurs.
To ensure that user accounts granted access to systems are all valid and
recognized users, strong processes must manage all changes to user IDs
and other authentication credentials, including adding new ones and
modifying or deleting existing ones.
If an employee has left the company and still has access to the network via
their user account, unnecessary or malicious access to cardholder data
could occur—either by the former employee or by a malicious user who
exploits the old and/or unused account. To prevent unauthorized access,
user credentials and other authentication methods therefore need to be
revoked promptly (as soon as possible) upon the employee’s departure.
Accounts that are not used regularly are often targets of attack since it is
less likely that any changes (such as a changed password) will be noticed.
As such, these accounts may be more easily exploited and used to access
cardholder data.
in case they need to support your systems increases the chances of

unauthorized access, either from a user in the vendor’s environment or
from a malicious individual who finds and uses this always-available
external entry point into your network. Enabling access only for the time
periods needed, and disabling it as soon as it is no longer needed, helps
prevent misuse of these connections.
Monitoring of vendor access provides assurance that vendors are
accessing only the systems necessary and only during approved time
frames.
Without account-lockout mechanisms in place, an attacker can continually
attempt to guess a password through manual or automated tools (for
example, password cracking), until they achieve success and gain access
to a user’s account. Note: Testing Procedure 8.1.6.b is an additional
procedure that only applies if the entity being assessed is a service
provider.
If an account is locked out due to someone continually trying to guess a

password, controls to delay reactivation of these locked accounts stops the
malicious individual from continually guessing the password (they will have
to stop for a minimum of 30 minutes until the account is reactivated).
Additionally, if reactivation must be requested, the admin or help desk can
validate that it is the actual account owner requesting reactivation.
When users walk away from an open machine with access to critical
system components or cardholder data, that machine may be used by
others in the user’s absence, resulting in unauthorized account access
and/or misuse.
The re-authentication can be applied either at the system level to protect
all sessions running on that machine, or at the application level.
These authentication methods, when used in addition to unique IDs, help
protect users’ IDs from being compromised, since the one attempting the
compromise needs to know both the unique ID and the password (or other
authentication used). Note that a digital certificate is a valid option for
“something you have” as long as it is unique for a particular user.
Since one of the first steps a malicious individual will take to compromise a
system is to exploit weak or nonexistent passwords, it is important to
implement good processes for authentication management.
Many network devices and applications transmit unencrypted, readable

passwords across the network and/or store passwords without encryption.
A malicious individual can easily intercept unencrypted passwords during
transmission using a “sniffer,” or directly access unencrypted passwords in
files where they are stored, and use this data to gain unauthorized access.
Note: Testing Procedures 8.2.1.d and 8.2.1.e are additional procedures
that only apply if the entity being assessed is a service provider.
Many malicious individuals use "social engineering”—for example, calling a

help desk and acting as a legitimate user—to have a password changed
so they can utilize a user ID. Consider use of a “secret question” that only
the proper user can answer to help administrators identify the user prior to
re-setting or modifying authentication credentials.
Strong passwords/passphrases are the first line of defense into a network
since a malicious individual will often first try to find accounts with weak or
non-existent passwords. If passwords are short or simple to guess, it is
relatively easy for a malicious individual to find these weak accounts and
compromise a network under the guise of a valid user ID.
This requirement specifies that a minimum of seven characters and both
numeric and alphabetic characters should be used for passwords/
passphrases. For cases where this minimum cannot be met due to
technical limitations, entities can use “equivalent strength” to evaluate their
alternative. For information on variability and equivalency of password
strength (also referred to as entropy) for passwords/passphrases of
different formats, refer to industry standards (e.g., the current version of
NIST SP 800-63.) Note: Testing Procedure 8.2.3.b is an additional
provider.
Passwords/passphrases that are valid for a long time without a change

provide malicious individuals with more time to work on breaking the
password/phrase. Note: Testing Procedure 8.2.4.b is an additional
provider.
If password history isn’t maintained, the effectiveness of changing

passwords is reduced, as previous passwords can be reused over and
over. Requiring that passwords cannot be reused for a period of time
reduces the likelihood that passwords that have been guessed or brute-
forced will be used in the future. Note: Testing Procedure 8.2.5.b is an
additional procedure that only applies if the entity being assessed is a
service provider
If the same password is used for every new user, an internal user, former
employee, or malicious individual may know or easily discover this
password, and use it to gain access to accounts.
Multi-factor authentication requires an individual to present a minimum of

two separate forms of authentication (as described in Requirement 8.2),
before access is granted.
Multi-factor authentication provides additional assurance that the individual
attempting to gain access is who they claim to be. With multi-factor
authentication, an attacker would need to compromise at least two different
authentication mechanisms, increasing the difficulty of compromise and
thus reducing the risk.
Multi-factor authentication is not required at both the system-level and
application-level for a particular system component. Multi-factor
authentication can be performed either upon authentication to the
particular network or to the system component.
Examples of multi-factor technologies include but are not limited to remote
authentication and dial-in service (RADIUS) with tokens; terminal access
controller access control system (TACACS) with tokens; and other
technologies that facilitate multi-factor authentication.
This requirement is intended to apply to all personnel with administrative
access to the CDE. This requirement applies only to personnel with
administrative access and only for non-console access to the CDE; it does
not apply to application or system accounts performing automated
functions.
If the entity does not use segmentation to separate the CDE from the rest
of their network, an administrator could use multi-factor authentication
either when logging onto the CDE network or when logging onto a system.
If the CDE is segmented from the rest of the entity’s network, an
administrator would need to use multi-factor authentication when
connecting to a CDE system from a non-CDE network. Multi-factor
authentication can be implemented at network level or at
system/application level; it does not have to be both. If the administrator
uses MFA when logging into the CDE network, they do not also need to
use MFA to log into a particular system or application within the CDE.
This requirement is intended to apply to all personnel—including general

users, administrators, and vendors (for support or maintenance) with
remote access to the network—where that remote access could lead to
access to the CDE. If remote access is to an entity’s network that has
appropriate segmentation, such that remote users cannot access or impact
the cardholder data environment, multi-factor authentication for remote
access to that network would not be required. However, multi-factor
authentication is required for any remote access to networks with access
to the cardholder data environment, and is recommended for all remote
access to the entity’s networks.
Communicating password/authentication policies and procedures to all
users helps those users understand and abide by the policies.
For example, guidance on selecting strong passwords may include
suggestions to help personnel select hard-to-guess passwords that don’t
contain dictionary words, and that don’t contain information about the user
(such as the user ID, names of family members, date of birth, etc.).
Guidance for protecting authentication credentials may include not writing
down passwords or saving them in insecure files, and being alert for
malicious individuals who may attempt to exploit their passwords (for
example, by calling an employee and asking for their password so the
caller can “troubleshoot a problem”).
Instructing users to change passwords if there is a chance the password is
no longer secure can prevent malicious users from using a legitimate
password to gain unauthorized access.
If multiple users share the same authentication credentials (for example,

user account and password), it becomes impossible to trace system
access and activities to an individual. This in turn prevents an entity from
assigning accountability for, or having effective logging of, an individual’s
actions, since a given action could have been performed by anyone in the
group that has knowledge of the authentication credentials.
Note: This requirement applies only when the entity being assessed is a
service provider.
To prevent the compromise of multiple customers through the use of a
single set of credentials, vendors with remote access accounts to customer
environments should use a different authentication credential for each
customer.
Technologies, such as multi-factor mechanisms, that provide a unique
credential for each connection (for example, via a single-use password)
could also meet the intent of this requirement.
If user authentication mechanisms such as tokens, smart cards, and
certificates can be used by multiple accounts, it may be impossible to
identify the individual using the authentication mechanism. Having physical
and/or logical controls (for example, a PIN, biometric data, or a password)
to uniquely identify the user of the account will prevent unauthorized users
from gaining access through use of a shared authentication mechanism.
Without user authentication for access to databases and applications, the

potential for unauthorized or malicious access increases, and such access
cannot be logged since the user has not been authenticated and is
therefore not known to the system. Also, database access should be
granted through programmatic methods only (for example, through stored
procedures), rather than via direct access to the database by end users
(except for DBAs, who may need direct access to the database for their
administrative duties).
operational procedures for managing identification and authorization on a
continuous basis
Without physical access controls, such as badge systems and door

controls, unauthorized persons could potentially gain access to the facility
to steal, disable, disrupt, or destroy critical systems and cardholder data.
Locking console login screens prevents unauthorized persons from gaining
access to sensitive information, altering system configurations, introducing
vulnerabilities into the network, or destroying records.
When investigating physical breaches, these controls can help identify the
individuals that physically accessed the sensitive areas, as well as when
they entered and exited.
Criminals attempting to gain physical access to sensitive areas will often
attempt to disable or bypass the monitoring controls. To protect these
controls from tampering, video cameras could be positioned so they are
out of reach and/or be monitored to detect tampering. Similarly, access
control mechanisms could be monitored or have physical protections
installed to prevent them being damaged or disabled by malicious
individuals.
Examples of sensitive areas include corporate database server rooms,
back-office rooms at retail locations that store cardholder data, and storage
areas for large quantities of cardholder data. Sensitive areas should be
identified by each organization to ensure the appropriate physical
monitoring controls are implemented.
Restricting access to network jacks (or network ports) will prevent
malicious individuals from plugging into readily available network jacks and
gain access into internal network resources.
Whether logical or physical controls, or a combination of both, are used,
they should be sufficient to prevent an individual or device that is not
explicitly authorized from being able to connect to the network.
Without security over access to wireless components and devices,

malicious users could use an organization’s unattended wireless devices
to access network resources, or even connect their own devices to the
wireless network to gain unauthorized access. Additionally, securing
networking and communications hardware prevents malicious users from
intercepting network traffic or physically connecting their own devices to
wired network resources.
Identifying authorized visitors so they are easily distinguished from onsite

personnel prevents unauthorized visitors from being granted access to
areas containing cardholder data.
Controlling physical access to sensitive areas helps ensure that only
authorized personnel with a legitimate business need are granted access.
When personnel leave the organization, all physical access mechanisms
should be returned or disabled promptly (as soon as possible) upon their
departure, to ensure personnel cannot gain physical access to sensitive
areas once their employment has ended.
Visitor controls are important to reduce the ability of unauthorized and

malicious persons to gain access to facilities (and potentially, to cardholder
data).
Visitor controls ensure visitors are identifiable as visitors so personnel can
monitor their activities, and that their access is restricted to just the
duration of their legitimate visit.
Ensuring that visitor badges are returned upon expiry or completion of the
visit prevents malicious persons from using a previously authorized pass to
gain physical access into the building after the visit has ended.
A visitor log documenting minimum information on the visitor is easy and
inexpensive to maintain and will assist in identifying physical access to a
building or room, and potential access to cardholder data.
Controls for physically securing media are intended to prevent
unauthorized persons from gaining access to cardholder data on any type
of media. Cardholder data is susceptible to unauthorized viewing, copying,
or scanning if it is unprotected while it is on removable or portable media,
printed out, or left on someone’s desk.
If stored in a non-secured facility, backups that contain cardholder data

may easily be lost, stolen, or copied for malicious intent.
Periodically reviewing the storage facility enables the organization to
address identified security issues in a timely manner, minimizing the
potential risk.
Procedures and processes help protect cardholder data on media

distributed to internal and/or external users. Without such procedures data
can be lost or stolen and used for fraudulent purposes.
It is important that media be identified such that its classification status can
be easily discernible. Media not identified as confidential may not be
adequately protected or may be lost or stolen. Note: This does not mean
the media needs to have a “Confidential” label attached; the intent is that
the organization has identified media that contains sensitive data so it can
protect it.
Media may be lost or stolen if sent via a non-trackable method such as

regular postal mail. Use of secure couriers to deliver any media that
contains cardholder data allows organizations to use their tracking systems
to maintain inventory and location of shipments.
Without a firm process for ensuring that all media movements are
approved before the media is removed from secure areas, the media
would not be tracked or appropriately protected, and its location would be
unknown, leading to lost or stolen media.
Without careful inventory methods and storage controls, stolen or missing

media could go unnoticed for an indefinite amount of time.
If media is not inventoried, stolen or lost media may not be noticed for a
long time or at all.
If steps are not taken to destroy information contained on hard disks,

portable drives, CD/DVDs, or paper prior to disposal, malicious individuals
may be able to retrieve information from the disposed media, leading to a
data compromise. For example, malicious individuals may use a technique
known as “dumpster diving,” where they search through trashcans and
recycle bins looking for information they can use to launch an attack.
Securing storage containers used for materials that are going to be
destroyed prevents sensitive information from being captured while the
materials are being collected. For example, “to-be-shredded” containers
could have a lock preventing access to its contents or physic ally prevent
access to the inside of the container.
Examples of methods for securely destroying electronic media include
secure wiping, degaussing, or physical destruction (such as grinding or
shredding hard disks).
Criminals attempt to steal cardholder data by stealing and/or manipulating
card-reading devices and terminals. For example, they will try to steal
devices so they can learn how to break into them, and they often try to
replace legitimate devices with fraudulent devices that send them payment
card information every time a card is entered. Criminals will also try to add
“skimming” components to the outside of devices, which are designed to
capture payment card details before they even enter the device—for
example, by attaching an additional card reader on top of the legitimate
card reader so that the payment card details are captured twice: once by
the criminal’s component and then by the device’s legitimate component.
In this way, transactions may still be completed without interruption while
the criminal is “skimming” the payment card information during the
process.
This requirement is recommended, but not required, for manual key-entry
components such as computer keyboards and POS keypads.
Additional best practices on skimming prevention are available on the PCI
SSC website.
Keeping an up-to-date list of devices helps an organization keep track of

where devices are supposed to be, and quickly identify if a device is
missing or lost.
The method for maintaining a list of devices may be automated (for
example, a device-management system) or manual (for example,
documented in electronic or paper records). For on-the-road devices, the
location may include the name of the personnel to whom the device is
assigned.
Regular inspections of devices will help organizations to more quickly
detect tampering or replacement of a device, and thereby minimize the
potential impact of using fraudulent devices.
The type of inspection will depend on the device—for example,
photographs of devices that are known to be secure can be used to
compare a device’s current appearance with its original appearance to see
whether it has changed. Another option may be to use a secure marker
pen, such as a UV light marker, to mark device surfaces and device
openings so any tampering or replacement will be apparent. Criminals will
often replace the outer casing of a device to hide their tampering, and
these methods may help to detect such activities. Device vendors may
also be able to provide security guidance and “how to” guides to help
determine whether the device has been tampered with.
The frequency of inspections will depend on factors such as location of
device and whether the device is attended or unattended. For example,
devices left in public areas without supervision by the organization’s
personnel may have more frequent inspections than devices that are kept
in secure areas or are supervised when they are accessible to the public.
The type and frequency of inspections is determined by the merchant, as
defined by their annual risk-assessment process.
Criminals will often pose as authorized maintenance personnel in order to

gain access to POS devices. All third parties requesting access to devices
should always be verified before being provided access—for example, by
checking with management or phoning the POS maintenance company
(such as the vendor or acquirer) for verification. Many criminals will try to
fool personnel by dressing for the part (for example, carrying toolboxes
and dressed in work wear), and could also be knowledgeable about
locations of devices, so it’s important personnel are trained to follow
procedures at all times.
Another trick criminals like to use is to send a “new” POS system with
instructions for swapping it with a legitimate system and “returning” the
legitimate system to a specified address. The criminals may even provide
return postage as they are very keen to get their hands on these devices.
Personnel always verify with their manager or supplier that the device is
legitimate and came from a trusted source before installing it or using it for
business.
operational procedures for restricting physical access to cardholder data
and CDE systems on a continuous basis.
It is critical to have a process or system that links user access to system

components accessed. This system generates audit logs and provides the
ability to trace back suspicious activity to a specific user.
Generating audit trails of suspect activities alerts the system administrator,

sends data to other monitoring mechanisms (like intrusion detection
systems), and provides a history trail for post-incident follow-up. Logging of
the following events enables an organization to identify and trace
potentially malicious activities
Malicious individuals could obtain knowledge of a user account with
access to systems in the CDE, or they could create a new, unauthorized
account in order to access cardholder data. A record of all individual
accesses to cardholder data can identify which accounts may have been
compromised or misused.
Accounts with increased privileges, such as the “administrator” or “root”

account, have the potential to greatly impact the security or operational
functionality of a system. Without a log of the activities performed, an
organization is unable to trace any issues resulting from an administrative
mistake or misuse of privilege back to the specific action and individual.
Malicious users often attempt to alter audit logs to hide their actions, and a
record of access allows an organization to trace any inconsistencies or
potential tampering of the logs to an individual account. Having access to
logs identifying changes, additions, and deletions can help retrace steps
made by unauthorized personnel.
Malicious individuals will often perform multiple access attempts on

targeted systems. Multiple invalid login attempts may be an indication of an
unauthorized user’s attempts to “brute force” or guess a password.
Without knowing who was logged on at the time of an incident, it is
impossible to identify the accounts that may have been used. Additionally,
malicious users may attempt to manipulate the authentication controls with
the intent of bypassing them or impersonating a valid account.
Turning the audit logs off (or pausing them) prior to performing illicit
activities is a common practice for malicious users wishing to avoid
detection. Initialization of audit logs could indicate that the log function was
disabled by a user to hide their actions.
Malicious software, such as malware, often creates or replaces system

level objects on the target system in order to control a particular function or
operation on that system. By logging when system-level objects, such as
database tables or stored procedures, are created or deleted, it will be
easier to determine whether such modifications were authorized.
By recording these details for the auditable events at 10.2, a potential

compromise can be quickly identified, and with sufficient detail to know
who, what, where, when, and how.
See guidance for sub-requirement 10.3.1

Time synchronization technology is used to synchronize clocks on multiple

systems. When clocks are not properly synchronized, it can be difficult, if
not impossible, to compare log files from different systems and establish
an exact sequence of event (crucial for forensic analysis in the event of a
breach). For post-incident forensics teams, the accuracy and consistency
of time across all systems and the time of each activity is critical in
determining how the systems were compromised.
See guidance for sub-requirement 10.4

Often a malicious individual who has entered the network will attempt to
edit the audit logs in order to hide their activity. Without adequate
protection of audit logs, their completeness, accuracy, and integrity cannot
be guaranteed, and the audit logs can be rendered useless as an
investigation tool after a compromise.
Adequate protection of the audit logs includes strong access control (limit
access to logs based on “need to know” only), and use of physical or
network segregation to make the logs harder to find and modify.
Promptly backing up the logs to a centralized log server or media that is
difficult to alter keeps the logs protected even if the system generating the
logs becomes compromised.

By writing logs from external-facing technologies such as wireless,
firewalls, DNS, and mail servers, the risk of those logs being lost or altered
is lowered, as they are more secure within the internal network.
Logs may be written directly, or offloaded or copied from external systems,
to the secure internal system or media.
File-integrity monitoring or change-detection systems check for changes to

critical files, and notify when such changes are noted. For file-integrity
monitoring purposes, an entity usually monitors files that don’t regularly
change, but when changed indicate a possible compromise.
Many breaches occur over days or months before being detected. Regular
log reviews by personnel or automated means can identify and proactively
address unauthorized access to the cardholder data environment.
The log review process does not have to be manual. The use of log
harvesting, parsing, and alerting tools can help facilitate the process by
identifying log events that need to be reviewed.
Checking logs daily minimizes the amount of time and exposure of a
potential breach.
Daily review of security events—for example, notifications or alerts that
identify suspicious or anomalous activities—as well as logs from critical
system components, and logs from systems that perform security
functions, such as firewalls, IDS/IPS, file-integrity monitoring (FIM)
systems, etc. is necessary to identify potential issues. Note that the
determination of “security event” will vary for each organization and may
include consideration for the type of technology, location, and function of
the device. Organizations may also wish to maintain a baseline of “normal”
traffic to help identify anomalous behavior.
Logs for all other system components should also be periodically reviewed
to identify indications of potential issues or attempts to gain access to
sensitive systems via less-sensitive systems. The frequency of the reviews
should be determined by an entity’s annual risk assessment.
If exceptions and anomalies identified during the log-review process are

not investigated, the entity may be unaware of unauthorized and
potentially malicious activities that are occurring within their own network.
Retaining logs for at least a year allows for the fact that it often takes a
while to notice that a compromise has occurred or is occurring, and allows
investigators sufficient log history to better determine the length of time of
a potential breach and potential system(s) impacted. By having three
months of logs immediately available, an entity can quickly identify and
minimize impact of a data breach. Storing logs in off-line locations could
prevent them from being readily available, resulting in longer time frames
to restore log data, perform analysis, and identify impacted systems or
data.
Without formal processes to detect and alert when critical security controls
fail, failures may go undetected for extended periods and provide attackers
ample time to compromise systems and steal sensitive data from the
The specific types of failures may vary depending on the function of the
device and technology in use. Typical failures include a system ceasing to
perform its security function or not functioning in its intended manner; for
example, a firewall erasing all its rules or going offline.
service provider
If critical security control failures alerts are not quickly and effectively
responded to, attackers may use this time to insert malicious software,
gain control of a system, or steal data from the entity’s environment.
service provider.
Documented evidence (e.g., records within a problem management

system) should support that processes and procedures are in place to
respond to security failures. In addition, personnel should be aware of their
responsibilities in the event of a failure. Actions and responses to the
failure should be captured in the documented evidence.
Implementation and/or exploitation of wireless technology within a network
are some of the most common paths for malicious users to gain access to
the network and cardholder data. If a wireless device or network is
installed without a company’s knowledge, it can allow an attacker to easily
and “invisibly” enter the network. Unauthorized wireless devices may be
hidden within or attached to a computer or other system component, or be
attached directly to a network port or network device, such as a switch or
router. Any such unauthorized device could result in an unauthorized
access point into the environment.
Knowing which wireless devices are authorized can help administrators
quickly identify non-authorized wireless devices, and responding to the
identification of unauthorized wireless access points helps to proactively
minimize the exposure of CDE to malicious individuals.
Due to the ease with which a wireless access point can be attached to a
network, the difficulty in detecting their presence, and the increased risk
presented by unauthorized wireless devices, these processes must be
performed even when a policy exists prohibiting the use of wireless
technology.
The size and complexity of a particular environment will dictate the
appropriate tools and processes to be used to provide sufficient assurance
that a rogue wireless access point has not been installed in the
environment.
For example: In the case of a single standalone retail kiosk in a shopping

mall, where all communication components are contained within tamper-
resistant and tamper-evident casings, performing a detailed physical
inspection of the kiosk itself may be sufficient to provide assurance that a
rogue wireless access point has not been attached or installed. However,
in an environment with multiple nodes (such as in a large retail store, call
center, server room or data center), detailed physical inspection is difficult.
In this case, multiple methods may be combined to meet the requirement,
such as performing physical system inspections in conjunction with the
results of a wireless analyzer.
rogue wireless access point has not been attached or installed. However,
in an environment with multiple nodes (such as in a large retail store, call
center, server room or data center), detailed physical inspection is difficult.
In this case, multiple methods may be combined to meet the requirement,
such as performing physical system inspections in conjunction with the
results of a wireless analyzer.
A vulnerability scan is a combination of automated or manual tools,
techniques, and/or methods run against external and internal network
devices and servers, designed to expose potential vulnerabilities that could
be found and exploited by malicious individuals.
There are three types of vulnerability scanning required for PCI DSS:
 Internal quarterly vulnerability scanning by qualified personnel (use of a

PCI SSC Approved Scanning Vendor (ASV) is not required)
 External quarterly vulnerability scanning, which must be performed by an
ASV
 Internal and external scanning as needed after significant changes
Once these weaknesses are identified, the entity corrects them and
repeats the scan until all vulnerabilities have been corrected.
Identifying and addressing vulnerabilities in a timely manner reduces the
likelihood of a vulnerability being exploited and potential compromise of a
system component or cardholder data.
An established process for identifying vulnerabilities on internal systems

requires that vulnerability scans be conducted quarterly. Vulnerabilities
posing the greatest risk to the environment (for example, ranked “High” per
Requirement 6.1) should be resolved with the highest priority.
Internal vulnerability scans can be performed by qualified, internal staff that

are reasonably independent of the system component(s) being scanned
(for example, a firewall administrator should not be responsible for
scanning the firewall), or an entity may choose to have internal
vulnerability scans performed by a firm specializing in vulnerability
scanning.
As external networks are at greater risk of compromise, quarterly external
vulnerability scanning must be performed by a PCI SSC Approved
Scanning Vendor (ASV).
A robust scanning program ensures that scans are performed and
vulnerabilities addressed in a timely manner.
The determination of what constitutes a significant change is highly

dependent on the configuration of a given environment. If an upgrade or
modification could allow access to cardholder data or affect the security of
the cardholder data environment, then it could be considered significant.
Scanning an environment after any significant changes are made ensures
that changes were completed appropriately such that the security of the
environment was not compromised as a result of the change. All system
components affected by the change will need to be scanned.
The intent of a penetration test is to simulate a real-world attack situation
with a goal of identifying how far an attacker would be able to penetrate
into an environment. This allows an entity to gain a better understanding of
their potential exposure and develop a strategy to defend against attacks.
A penetration test differs from a vulnerability scan, as a penetration test is
an active process that may include exploiting identified vulnerabilities.
Conducting a vulnerability scan may be one of the first steps a penetration
tester will perform in order to plan the testing strategy, although it is not the
only step. Even if a vulnerability scan does not detect known
vulnerabilities, the penetration tester will often gain enough knowledge
about the system to identify possible security gaps.
Penetration testing is generally a highly manual process. While some
automated tools may be used, the tester uses their knowledge of systems
to penetrate into an environment. Often the tester will chain several types
of exploits together with a goal of breaking through layers of defenses. For
example, if the tester finds a means to gain access to an application
server, they will then use the compromised server as a point to stage a
new attack based on the resources the server has access to. In this way, a
tester is able to simulate the methods performed by an attacker to identify
areas of potential weakness in the environment.
Penetration testing techniques will be different for different

organizations, and the type, depth, and complexity of the testing will
depend on the specific environment and the organization’s risk
assessment.
the most recent external penetration test to verify that penetration testing is
performed as follows:
Penetration testing conducted on a regular basis and after significant
changes to the environment is a proactive security measure that helps
minimize potential access to the CDE by malicious individuals.
The determination of what constitutes a significant upgrade or modification
is highly dependent on the configuration of a given environment. If an
upgrade or modification could allow access to cardholder data or affect the
security of the cardholder data environment, then it could be considered
significant. Performing penetration tests after network upgrades and
modifications provides assurance that the controls assumed to be in place
are still working effectively after the upgrade or modification.
service provider.
For service providers, validation of PCI DSS scope should be performed
as frequently as possible to ensure PCI DSS scope remains up to date
and aligned with changing business objectives
Intrusion detection and/or intrusion prevention techniques (such as

IDS/IPS) compare the traffic coming into the network with known
“signatures” and/or behaviors of thousands of compromise types (hacker
tools, Trojans, and other malware), and send alerts and/or stop the attempt
as it happens. Without a proactive approach to unauthorized activity
detection, attacks on (or misuse of) computer resources could go
unnoticed in real time. Security alerts generated by these techniques
should be monitored so that the attempted intrusions can be stopped.
Change-detection solutions such as file-integrity monitoring (FIM) tools
check for changes, additions, and deletions to critical files, and notify when
such changes are detected. If not implemented properly and the output of
the change-detection solution monitored, a malicious individual could add,
remove, or alter configuration file contents, operating system programs, or
application executables. Unauthorized changes, if undetected, could
render existing security controls ineffective and/or result in cardholder data
being stolen with no perceptible impact to normal processing.

operational procedures for security monitoring and testing on a continuous
basis.
ATOS PCI Contro
Solution Type Requirement Solution Description
Policy / Process / Procedure
See below
Hardware Configuration Firewall and router configuration restrict traffic to only

authorized communications (for example: restricting
source/destination addresses/ports and blocking content).
Hardware Configuration Firewall and router configuration are set to permit only
established connections into the internal network and denies
any inbound connections not associated with a previously
established session. Firewall and router configuration standard
must provide the inventory of those established connections.
Hardware Configuration The firewall and router configuration (includes the standard)
should contain, spanning any varying technologies, methods
used to meet the intent of this requirement: i.e., the controls
used to meet this requirement may be different for IPv4
networks than for IPv6 networks.
Hardware Configuration Atos Policy and the Technical System Security guide have this
listed as a requirement. Any portable computing device that
connects to the network (CDE) have the firewall configuration
in place. This will be a system check before being allowed to
connect to the CDE:
• Personal firewall software or equivalent functionality is in

place for all portable computing devices (including company
and/or employee-owned) that connect to the Internet when
outside the network (for example, laptops used by employees),
and which are also used to access the CDE.
• Specific configuration settings are defined for personal
• Personal firewall (or equivalent functionality) is configured to
actively run.
not be alterable by users of the portable computing devices.
Hardware Configuration Atos security policy, the firewall and router configuration
standard and any applicable Technical System Security guides
illustrate the procedures for managing firewalls, that they're in
use and easily accessible known to all affected parties.
Hardware Configuration There needs to be a unified policy regarding firewall

maintenance including how maintenance procedures are
performed, who has access to the firewall and when
maintenance is scheduled.
Hardware Configuration The firewall and router configuration standard (can be in the
network standard) must include all inbound and outbound
traffic necessary for the cardholder data environment.
Note: Limit traffic to a minimum and only if necessary. Every

concession must have a legitimate requirement. Default rule
must be an implicit "deny."
Hardware Configuration The firewall and router configuration standard must include:
• Minimum guidance for ensuring router configuration files are

secure from unauthorized access.
• And that the latest file is synchronized (running). The latest
file must be the start-up file.
network standard) must include:
• Minimum guidance for the network lifecycle on tracking,

cradle-to-grave, each of the network services, protocols and
ports.
insecurities.
Tracking of the introduction and/or changes to each of the

network services, protocols and ports. This can exist through
automation (Service Now) or tracked in Microsoft suite.

ports.
insecurities.


ports.
insecurities.


ports.
insecurities.
Tracking" of the introduction and/or changes to each of the

Hardware Configuration IP address spoofing is used to perform malicious activities

such as Man In The Middle, DoS and DDoS attacks. Firewall
and routers configuration must restrict the advance of forged
traffic from the internet (RFC 1918): external (internal facing)
interface should not accept any addresses that are used in the
internal network range as the source.
▪ Ensure firewall filters block traffic from the internet that has a
source address from inside the network-Set up rules on the
firewall, router and other network gateways that examine
incoming packets i.e., drop conflicting source IPs.
▪ Filter outgoing packets that have a source address different
from the internal network to prevent an attack originating from
the local site.
Hardware Configuration Firewall and router configuration restrict traffic to only
authorized communications (for example: restricting
Hardware Configuration The firewall and router configuration (includes the standard)
should contain, spanning any varying technologies, methods
used to meet the intent of this requirement: i.e., the controls
used to meet this requirement may be different for IPv4
networks than for IPv6 networks.
Hardware Configuration Atos Policy and the Technical System Security guide have this
listed as a requirement. Any portable computing device that
connects to the network (CDE) have the firewall configuration
in place. This will be a system check before being allowed to
connect to the CDE:
• Personal firewall software or equivalent functionality is in

place for all portable computing devices (including company
and/or employee-owned) that connect to the Internet when
outside the network (for example, laptops used by employees),
and which are also used to access the CDE.
actively run.
not be alterable by users of the portable computing devices.
Policy / Process / Procedure Atos security policy, the firewall and router configuration
standard and any applicable Technical System Security guides
illustrate the procedures for managing firewalls, that they're in
use and easily accessible known to all affected parties.
Policy / Process / Procedure There needs to be a unified policy regarding firewall
maintenance including how maintenance procedures are
performed, who has access to the firewall and when
maintenance is scheduled.
Audit / Interview / Sample Review Ideally, you'd want to select an access point vendor that does
not ship with default keys that need to be changed. The
vendors product should also support the latest strong security
standards and make it easy to ensure they are setup correctly.
Please reference requirement 2.1 which speaks to SMTP
community strings and default password change requirements.
Audit / Interview / Sample Review It is imperative that the organization adopts secure benchmark
hardening and vulnerability checklists for each asset in the
environment before it hits production. Proper configuration
standards must be developed (written down and documented)
for all system components. It’s a good idea, and considered a
best practice, to standardize your configurations as much as
possible. You are required to document your configuration
standards and if a system component is checked, it must meet
the specifications you documented.
Audit / Interview / Sample Review Each physical bare-metal server deployed in the organization
should have 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.) If virtualization is used, their can be multiple virtual
servers on one physical server, however, that physical server
should have only one primary function (i.e. Web)
Audit / Interview / Sample Review Each physical bare-metal server deployed in the organization
should have 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.) If virtualization is used, their can be multiple virtual
servers on one physical server, however, that physical server
should have only one primary function (i.e. Web)
Audit / Interview / Sample Review It is imperative that organization's utilize a defense in depth
strategy and only permit essential ports and services to run on
their network
Audit / Interview / Sample Review Organizations must ensure that security is baked into every
level of the overall application/service deployment. If an
insecure protocol must be leveraged for compatibility
purposes, it should be adequately tested. A safeguard should
also be in place due to the use of the insecure service/protocol
Audit / Interview / Sample Review System administrators and engineers must have knowledge of
common security parameter settings available specifically to
the application/service they are implementing.
Audit / Interview / Sample Review In an effort to prevent misuse, organizations should develop of
policy during the server build process to disable any
unnecessary inherent functionality
Audit / Interview / Sample Review Admin-level system access other than console should be
strongly encrypted
Policy / Process / Procedure Organizations should consider leveraging asset management

software capable of auto-discovery, risk detection, & CMDB
Policy / Process / Procedure Organizations should ensure that the established SLA with
vendors defines the scope of work adequately
Policy / Process / Procedure If PCI data exists in a shared environment by a hosting

provider, tests and checks must be configured and enabled
Policy / Process / Procedure Compliance to this requirement can be achieved by
formulating a formal policy of data retention. This policy should
indicate which type of data should be retained and which data
needs to be destroyed when it is not needed anymore.
Policy / Process / Procedure Storage of sensitive authentication data after authorization is

prohibited. This data is very valuable to malicious individuals
as it allows them to generate counterfeit payment cards and
Audit / Interview / Sample Review Organizations must 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.
Audit / Interview / Sample Review Organizations are not to 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.
Audit / Interview / Sample Review Organizations should not store the personal identification
number (PIN) or the encrypted PIN block after authorization.
Audit / Interview / Sample Review PAN, if fully displayed on computer screens, receipts, fax or
print out can be used for fraudulent purposes. Hence, it is a
must to verify that PAN should be masked when it appears to
any of the unauthorized individuals.
Audit / Interview / Sample Review The organization must take measures to render PAN
unreadable anywhere it is stored (including on portable digital
media, backup media, and in logs). 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.
Audit / Interview / Sample Review 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
Audit / Interview / Sample Review It is extremely important to protect cryptographic keys as any
access to key by a fraudulent individual means that the
information can be decrypted by them and used for all the
wrong purposes.
wrong purposes.
wrong purposes.
wrong purposes.
wrong purposes.
Policy / Process / Procedure Management of cryptographic keys is as important as the
implementation of the encryption process itself. For
compliance purposes it is important to develop and examine
the documentation that is provided to customers as a guidance
to protect the cryptographic keys.
Audit / Interview / Sample Review Management of cryptographic keys is as important as the






Audit / Interview / Sample Review Personnel need to be aware of and following security policies
and documented operational procedures for managing the
secure storage of cardholder data on a continuous basis.
Audit / Interview / Sample Review For safe transmission of cardholder data from the sender to
receiver over a public network, it is important to use reliable
certificates or keys, strong encryption, and secure
authentication protocol to transport data over the network. Any
requests to join by systems that could result in an unsafe or
unsecured connection to the network should be rejected.
Audit / Interview / Sample Review For safe transmission of cardholder data from the sender to
receiver over a wireless network, it is important to use reliable
certificates or keys, strong encryption, and secure
authentication protocol to transport data over the network.
Audit / Interview / Sample Review This requirement maintains that Personal Account Numbers
should never be sent unencrypted or in plain text format over a
messaging platform such as emails, instant messengers or
chat, etc. These platforms are vulnerable to exposure through
packet sniffers that can be used by malicious individuals to
extract valuable confidential information such as PAN
Audit / Interview / Sample Review The organization is responsible for documenting and
communicating the security policies and operational
procedures to all affected parties
Audit / Interview / Sample Review Commercial grade anti-virus solutions provide signature-based
malware detection capabilities. New signatures are created
and made available by the vendor to address and protect the
organization from zero day exploits
Audit / Interview / Sample Review Commercial grade anti-virus solutions provide signature-based
malware detection capabilities. New signatures are created
and made available by the vendor to address and protect the
organization from zero day exploits.
All systems (Internet-connected or not) should have an anti-

virus client installed to protect the asset against malicious
software. If the asset has a distinct or proprietary OS which an
AV vendor would not support, those systems should be
sufficiently hardened per a STIG to minimize the effect of a
malicious program wreaking havoc.
Audit / Interview / Sample Review Advanced, extensible, and scalable centralized security
management software allows the organization to ensure in
near real time that all systems are up to date with the latest
signature files, and provide an auditing mechanism to prove
this
Audit / Interview / Sample Review Most commercially available anti virus vendors package their
software in such a way that the mechanisms utilized to ensure
that an endpoint is up to date is persistent. In the event of a
rootkit or some other malicious program designed to detect
and kill this process, a host base intrusion detection system
should be utilized.
Audit / Interview / Sample Review Anti-virus should be set up in such a manner that its settings
cannot be disabled or changed by any user, except the
authorized personnel. When an anti-virus program runs
continuously in the background, it can detect a virus in real
time and will constantly check for malware threats
Audit / Interview / Sample Review The organization is responsible for documenting and
communicating the security policies and operational
procedures to all affected parties
Policy / Process / Procedure Document a software asset list of all tools and libraries that are
used within the development process.
Implement a process to regularly monitor each item on the list

for notification of vulnerabilities and patches.
Identify additional subscriptions to industry news groups,

mailing lists, user groups etc.
Identify the process and mechanisms that identify, rank and

track the status of action items that are assigned to address
and mitigate the risks associated with each new vulnerability.
Hardware Configuration Identify the policy/process/work instructions that directs the
organization to subscribe to the appropriate vendor
feeds/websites to check patch updates to ensure that all
system components and software have the latest vendor-
supplied security
patches installed. Policy should include a requirement that all
critical patches are deployed within a month of release.
Policy / Process / Procedure Identify the policy/process/work instructions that directs the
organization to periodically review process documentation for
accuracy, updates, evolution to ensure alignment with current
best practice for code development and security
Policy / Process / Procedure In addition to the periodic review of process documentation,

periodic process audits and/or training would verify that the
responsible personnel are following procedure and applying
coding best practices related to security i.e. 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.
responsible personnel are participating in one or more manual
or automated code reviews, per the requirements of the client /
customer / contract
organization to periodically review process documentation for
accuracy, updates, evolution to ensure alignment with current
best practice for Change and Configuration Management
organization to perform periodic reviews of the network
architecture to ensure that development/test and production
systems are separate and distinct.
User roles are defined and assigned to allow the lowest level
of access required to complete the required activities.
whenever possible, different people should have different
responsibilities in each environment. However, it may be
necessary for a coder to have broad access to the dev/test
environment but only user rights in production for limited
troubleshooting purposes

responsible personnel are assigned to roles that align with
their access requirements and responsibilities in each
environment.

periodic process audits and/or training would verify that
responsible personnel are trained and follow the process to
use mock data, rather than live data for testing and
development

periodic process audits and/or training would verify that
responsible personnel are trained and follow the process to
scrub mock data and account information prior to
implementation into a live environment
Policy / Process / Procedure Conduct a periodic review of the Change Management and/or
Configuration Management procedures to ensure the inclusion
of the following:
 Documentation of impact
 Documented change approval by authorized parties
 Functionality testing to verify that the change does not
 Back-out procedures
Perform periodic reviews of completed updates or

implementations to ensure that all the required components
were completed as required.
of the following:
▪ Functionality testing to verify that the change does not

of the following:

of the following:

of the following:

of the following for more significant system changes or
updates:
▪ Network diagram is updated to reflect changes.

▪ Systems are configured per configuration standards, with all
default passwords changed and unnecessary services
disabled.
▪ Systems are protected with required controls—e.g., file-
integrity monitoring (FIM), anti-virus, patches, audit logging.
▪ Sensitive authentication data (SAD) is not stored and all
cardholder data (CHD) storage is documented and
incorporated into data-retention policy and procedures
▪ New systems are included in the quarterly vulnerability
scanning process.

organization to ensure developers are trained and current in
secure coding techniques that are relevant to the application
coding languages used.
The secure coding techniques must be based on industry best
practices or standards.
Developer training, which can either be conducted in-house or
by a qualified third party, is deemed sufficient for PCI
compliance once each developer is able to both identify and
resolve all known common coding vulnerabilities.
Developers should receive secure code training upon hire and
at least annually. It is recommended to have developers sign
an agreement or ideally pass an exam to demonstrate
compliance with requirement 6.5.
Note: Refer to the OWASP Top Ten for further details on

required training materials to cover 6.5.1 - 6.5.10


















Policy / Process / Procedure (Web) Applications that are (public) Internet facing, are
protected by either a Web Application Firewall (WAF) or by
Web Application Vulnerability Scanning process.
Note: Recommend both solutions whenever possible to

provide optimal coverage
Policy / Process / Procedure Policies and procedures related to PCI-DSS will be reviewed
and maintained regularly.
An annual review will be conducted to ensure all development

documentation in requirement 6 is kept up-to-date
Policy / Process / Procedure With role-based access control (RBAC), a subject is given one
or more roles depending on the subject’s job. Access is
determined by the subject’s role. This control calls for these
specific job roles to be defined, so that principles of least
privilege may be incorporated.
Audit / Interview / Sample Review Least principle access dictates that user's are assigned to
roles based on their job function, and that those roles be
assigned the minimum privileges required to fulfill that job
function
Audit / Interview / Sample Review Job classification and function access based on defined roles
ties once again into RBAC
Audit / Interview / Sample Review It is imperative to the organization that it knows of all
individuals with elevated privileges and access. The electronic
storage of this data should be keep confidential, and encrypted
Audit / Interview / Sample Review Access controls systems for each application used by the
organization (especially SaaS-related) should be configured to
implicitly deny access. Access to these systems should be
permitted only once explicitly granted, and level of access
needs to map to a defined role for the user
Audit / Interview / Sample Review The organizational SOP should clearly state what the security
policies and operational procedures are. This SOP should be
kept in a secure space, but available to all employees for easy
review
Audit / Interview / Sample Review Security policies and operational procedures regarding the
restricted access to cardholder data must be documented, and
known by everyone
Policy / Process / Procedure Identify the Policy and Process documents that document the
organization's rules for setting up and maintaining user access,
password requirements and user login protocols.
Policy / Process / Procedure Policy to require each user to have a unique ID.
Include a system check to verify that each ID is unique and
has not been user previously
Design reporting capability to identify "generic" or multi user
accounts
Policy / Process / Procedure A System Access Request process is implemented that
manages requests and authorizations for additions, deletions
and modifications of User IDs and access rights
Policy / Process / Procedure Human resources, immediately upon receipt of notice of a

termination, would initiate a System Access Request to revoke
access for the terminated user. Termination SAR requests
would be completed on a daily basis with an appropriate cutoff
time to complete the request each day.
The HR Termination SAR would include additional information

regarding the receipt and disposition of any physical
authentication methods.
Policy / Process / Procedure Accounts that have not been accessed within 90 days will be
disabled. Accounts that have not been accessed for longer
periods (length TBD by agreement with the Client) may be
deleted. Reviews of user accounts will be conducted
periodically (weekly / monthly) by assigned administrative
personnel.
Policy / Process / Procedure Vendors requiring access to the system for support or
maintenance will be required to submit a Vendor SAR that
includes information specific to the request, including but not
limited to
▪ Start time / Stop Time

▪ Vendor User Name to be used
▪ Reason for access
▪ Description of the work to be done
▪ Etc.
Assigned systems administration resources will monitor the

access window and verify that only the authorized work is
completed and will disable the vendor user account upon
completion of the work. If any additional work is required or
identified, the process will either escalate to authorize the work
at that time or an additional Vendor SAR will be submitted to
come back to complete the additional work.
Policy / Process / Procedure User Access Management settings will be implemented to lock
account access and require the user contact IT Support or
initiate a password reset that verifies the user identity before
completing the reset and unlocking the account. Recommend
lock out after 3 failed attempts but no more than 6 failed
attempts. Additional measures, including wait times between
failed logins and 2 step authentication may be considered
based on the Client's requirements.
Policy / Process / Procedure User Access Management settings will be implemented to lock
account access and require the user contact IT Support or
initiate a password reset that verifies the user identity before
completing the reset and unlocking the account. Recommend
lock out after 3 failed attempts but no more than 6 failed
attempts. Additional measures, including wait times between
failed logins and 2 step authentication may be considered
based on the Client's requirements.
Policy / Process / Procedure User Access Management settings will be implemented to

require users to re-authenticate their login credential if they
have been inactive for more than 15 minutes (15 minutes is
the maximum time recommended, the timeout can be set to a
lower threshold)
Policy / Process / Procedure User Access Management settings will be implemented to
require users to use passwords/pass phrases or other means
of authenticating user identity and authority to access systems
and application that contain sensitive data.
Policy / Process / Procedure All privileged passwords are protected with strong encryption
both at rest and in transit.
The solution includes flexible and centralized password policy
management for all privileged accounts across the
organization including password aging, complexity,
versioning, and archiving. The organizations can set policy for
privileged password format, including the requirements for a
minimum length, and numeric and
alphabetic characters; and can ensure passwords are unique.
Password changes are automated based on an
organizationally-defined time-frame, enabling
organizations to schedule password changes including after
every use, and enforce time limitations on passwords for all
privileged users.
Policy / Process / Procedure The User Access Management process for unlocking disabled
account, resetting passwords, or any other user account
services provided by a support function will require user
authentication via security questions that are stored securely
as part of the users profile.
Policy / Process / Procedure User profile policy will require a minimum length of at least
seven characters. Passwords will contain both numeric and
alphabetic characters.
Alternatively, the passwords/phrases must have complexity

and strength at least equivalent to the parameters specified
above.
Policy / Process / Procedure User profile policy and procedures will require:
a passwords/pass phrases to change every 90 days.
Policy / Process / Procedure User profile policy and procedures will require:
The password system will have the ability to keep the last 4
passwords / pass phrases used and prevent users from using
any of the last 4 passwords.
Policy / Process / Procedure Initial password setup and resets are known to the user and to
the personnel who created them and must be changed in a
timely fashion. These passwords are temporary and should
expire within a limited period of time.
Users should be prompted to change the temporary password

immediately after logging in and may be provided with links to
complete a self serve password change
Do not use generic or common passwords to set up or reset

user accounts
Policy / Process / Procedure See Below

Policy / Process / Procedure For user roles or profiles that include administrative access to
the CDE, the system will require 2 factor authentication. User
ID and Password combination and either Smart Card
authentication or another form of Token authentication
Policy / Process / Procedure System configurations for remote access servers and systems
are configured to verify multi-factor authentication for:
 All remote access by personnel, both user and administrator,
and
 All third-party/vendor remote access (including access to
applications and system components for support or
maintenance purposes).
Policy / Process / Procedure Conduct periodic reviews and audits to ensure that policy and
procedures are published, communicated, trained and followed
regarding strong authentication and password security.
Policy / Process / Procedure Organizational policy and process will implement solutions that
ensure use group, shared, or generic IDs, passwords, or other
authentication methods are managed as follows:

▪ 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.
Policy / Process / Procedure As service providers Atos' Organizational policy and process
will implement solutions that ensure use group, shared, or
generic IDs, passwords, or other authentication methods apply
to each customer. Passwords and Pass Phrases will be
unique and will not be used for multiple customers or sites
Policy / Process / Procedure User Access Management and any cooperating resources
responsible for the issuance of additional authentication
mechanisms will have policy, process and tools available to
track and manage the assignment and issuance of physical or
logical security tokens, smart cards, certificates, etc. so that:
▪ Authentication mechanisms are assigned to an individual

account and not shared among multiple accounts.
▪ Physical and/or logical controls are in place to ensure only
the intended account can use that mechanism to gain access.
Policy / Process / Procedure Policy and procedures will be published and maintained so
that database and application configuration settings ensure
that every user is authenticated before being granted access
to any database containing sensitive data. What is more
threatening is that the user cannot even be traced since that
user is an unknown individual
Audit / Interview / Sample Review Security policies and operational procedures will be published
to the organization's documentation library.
Changes will be communicated via the organizations Change
Management or Communication Management process.
New hires will receive training on the security policies and
procedures as appropriate to their role and responsibilities.
Periodic reviews, audits and refresher training will be
conducted to ensure continued awareness and compliance.
Physical Security Determine the scope of "appropriate" depending on the

Customers needs. The geography, architecture, security
technology, etc. of an organization play a part in developing
and executing security controls to reduce and monitor access
to cardholder data.
Presence of physical security controls should be verified in

every data center, server rooms and all other facilities holding
confidential data. Entry to such areas should be verified for
security through keys, badges or other mechanisms.
A sample of systems should be selected and the administrator

should try to log in to these systems to check whether they are
locked by the user or not.
Physical Security Installation of video cameras or other access control

mechanisms to monitor entry and exit areas.
These should have mechanisms to prevent tampering and

disablement.
Video and access records will be cataloged and stored for a

minimum of 3 months
Physical Security Restrict access to publicly available networks.
Physical Security Restrict access to wireless networks, handheld devices,

gateways, telecommunication lines and all other hardware.
Physical Security Publish and periodically review policy and procedures to:
▪ Identifying onsite personnel and visitors (for example,

assigning badges)
▪ Changes to access requirements
▪ Revoking or terminating onsite personnel and expired visitor
Periodically review and verify that access to the identification

process (such as a badge system) is limited to authorized
personnel.
Physical Security 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.
Physical Security Policy and strong procedures will be in place to recognize the
identity of visitors to check whether they are authorized to
enter the sensitive areas of the facility or not.
Physical Security Policy and Process related to physically securing all media will
be published, communicated and trained.
Cardholder data is prone to being compromised if it is kept

unprotected in a system, on a piece of paper on a desk or
even kept unsecured in portable media. Media is not limited
to backup data at a long term storage facility
Storing backup media in a safe offsite location also prepares

the organization to prepare for a business continuity plan to
cater for safe backup in times of disaster.
Physical Security Policy and process related to CDE data storage will include an
annual review of documented security protocols and its
implementation
Physical Security See Below
Physical Security Policy and process will require that all media (Meaning any
physical item separate or separable from a computer that
stores or contains payment card information, whether the info
exists on paper, in electronic form on a disc or drive, or in
some other kind of medium) will be identified and classified
according to it's sensitivity. The intent is that the organization
has identified media that contains sensitive data so it can
protect it
Physical Security Policy and process will require that all media sent to outside
facilities is transported via a secured courier and that all
transport activities are tracked, managed and traceable
Physical Security Policy and process that requires all media sent to outside
facilities is transported via a secured courier and that all
transport activities are tracked, managed and traceable will
also include management approval for any and all media that
is moved from a secured area
Physical Security The organization shall publish and maintain policy and process
to perform inventory control and destruction to manage unused
important forms to prevent unauthorized use.
The organization should use a forms inventory control ledger

to record and control the inventory, and verify the inventory as
required.
Physical Security The organization will utilize and review media inventory logs to
verify that periodic media inventories are performed at least
annually.
Physical Security The organization will conduct periodic reviews of the policy
and processes related to the storage, transfer, transmission
and destruction of sensitive media. Rules related to sensitive
media may be contained within a more comprehensive policy
related to the storage, transfer, transmission and destruction of
all media.
Physical Security The organization will conduct periodic refresher training and/or
process audits to ensure that the policy and processes related
to the storage, transfer, transmission and destruction of
sensitive media are trained and followed.
The organization will conduct periodic records audits to ensure

that the policy and processes related to the storage, transfer,
transmission and destruction of sensitive media are followed.
Physical Security The organization publish and maintain policy and procedures
to employ verifiable methods for securely destroying electronic
media include secure wiping, degaussing, or physical
destruction (such as grinding or shredding hard disks).
Policy / Process / Procedure See Below
Policy / Process / Procedure Asset Management policy and procedures will provide the
guidance and mechanisms to maintain an up-to-date list of
devices. At a minimum, the list will 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.
Policy / Process / Procedure Policy and procedures will be published, trained and
implemented to provide guidance for periodic inspection of
devices to detect and report evidence of tempering or
replacement.
Audit / Interview / Sample Review Policy and process will require that training materials are
reviewed periodically to ensure that they are up to date and to
identify opportunities for improvement.
At a minimum, new hire training and periodic refresher training

will cover the following:
▪ Verifying the identity of any third-party persons claiming to be

repair or maintenance personnel, prior to granting them access
to modify or troubleshoot devices
▪ Being aware of suspicious behavior around devices (for
example, attempts by unknown persons to unplug or open
devices)
▪ Reporting suspicious behavior and indications of device
tampering or substitution to appropriate personnel (for
example, to a manager or security officer).
Audit / Interview / Sample Review Security policies and operational procedures will be published
to the organization's documentation library.
Changes will be communicated via the organizations Change
Management or Communication Management process.
New hires will receive training on the security policies and
procedures as appropriate to their role and responsibilities.
Periodic reviews, audits and refresher training will be
conducted to ensure continued awareness and compliance.
Audit / Interview / Sample Review Auditing and account association to individual named users
must be enabled in order to ensure traceability of data access
- to a specific user. Logging data must be captured to include
user, data and time and level of access (amoung other data
elements). In addition, Implement audit trails for all systems,
alerts on suspicious activity, and a response plan for those
anomalies
Audit / Interview / Sample Review Properly implemented controls should allow the examiner to
assemble all necessary post-event data to properly depict: the
change or level-of-access made, date and time the change(s)
were made, user making the change, etc. The gathering of this
information should extend to all users including system
administrators. Track all admin actions, login attempts, account
changes, and pauses in the audit trail.
Audit / Interview / Sample Review Log data will provide the forensic trail from which to assmble
the "story" of the access, change or removal of restricted data.
Ensuring the necessary data elements to assemble the "story"
will depend on the level of logging and audit data that is
captured. A balance must be struck however between the level
of log data caputred, compared to the requirements to store
and archive the data. Excessive logging can also impact
system performance. This too is a consideration to be made.
Hardware Configuration Time synchronization and restriction of time change /

modification features is a vital part of log-data collection.
System components should be directed to a master time
controller and access to change or modify system time should
be restricted as to avoid malicious attempts to modify log data
via the date / timestamp function. Check computer clocks and
correct any significant time variations on a weekly basis, or
more often, depending on the error margin for time accuracy


Policy / Process / Procedure System administrators or, accounts with root access, (by
default) can mofidy audit or log data. Actions undertaken using
these accounts should be logged and audited frequently. In
addition, automated notifications should be considered when
elevated accounts access, or modify log data. Enable a
"separation of duties" approach users who have system
administrator access, to those who have access to log or audit
data.
default) can modify audit or log data. Actions undertaken using
data.
default) can modify audit or log data. Actions undertaken using
data.
Policy / Process / Procedure Log files should be backed-up and archived per the
organizational data retention policy to ensure historical access
to log data if needed. Access to log archives should be
restricted to users or accounts with a need-to-know.
Policy / Process / Procedure Log data should be written to non-destructive media (SAN,
NAS, tape, etc.) residing on aspects of the network considered
"trusted" or core. Care should be taken to not store logs on
same systems or external-facing technologies as these
systems may be accessible via the same means of
compromise as the original security event.
Policy / Process / Procedure File Integrity Monitoring (FIM) establishes alerts or notifications
in the event key system files are modified or altered. FIM
should be considered as part of a comprehensive data
protection or log retention program.
Audit / Interview / Sample Review Develop emergent and non-emergent (maintenance-based)

reviews of log data to ensure log integrity, accessibility and to
ensure the right data elements are being captured (specific to
policy requirements). Note exceptions or missing data
elements to ensure against intentional or unintentional removal
of log data. Make necessary adjustments to logging events to
ensure alignment with logging requirements post-review.
Policy / Process / Procedure Develop emergent and non-emergent (maintenance-based)


Policy / Process / Procedure Device monitoring via internal tool sets or external managed or
monitored security service provider is highly recommended.
Tools or service providers alert on the status, activity
(malicious or other) and health of critical infrastructure
components.
Policies should be developed to ensure the health and activity

of these devices is monitored and controlled.
Corresponding impact analysis and response plans should be

developed to include the criticality of the device, the potential
for impact, the severity of impact should one occur and a plan
for recovery for all infrastructure devices required for business
operation.
Policy / Process / Procedure Device monitoring via internal tool sets or external managed or
monitored security service provider is highly recommended.
Tools or service providers alert on the status, activity
(malicious or other) and health of critical infrastructure
components.
Policies should be developed to ensure the health and activity

of these devices is monitored and controlled.
Corresponding impact analysis and response plans should be

developed to include the criticality of the device, the potential
for impact, the severity of impact should one occur and a plan
for recovery for all infrastructure devices required for business
operation.
Policy / Process / Procedure Review security policies frequently to ensure accuracy and
relevancy based on business need. Personnel should be
interviewed to verify that all security policies and procedures
are communicated to them. Efforts can include; security
awaareness training and certification procedures for staff or
associates charged with information-handling, account or
infrastructure administration.
Policy / Process / Procedure Solutions to address this control range from policy
development to technology solutions and software aimed at
detection and reporting.
Policies and procedures are required to ensure network

controls exist to reduce or prohibit the introduction of
unahotrized wiress technology and, to aler of its presence if
introduced.
Network mapping policies require that all segements of the

network (including those where wireless technologies exist)
help to identify authorized segments in the event of question or
audit. These aretifacts are also very helpful for maintenance,
disaster recovery, scalability planning, etc.
Wireless network scanning technology enables the end user to

detect unathorized wireless network devices or network
segments on their network. This technolgy can be configured
to execute hands-off, scheduled scans of all, or part of a given
network programatically and to alert of the presence of
previoulsy unmapped or, newly introduced network segments.
Policy / Process / Procedure Solutions to address this control range from policy
development to technology solutions and software aimed at
detection and reporting.
Policies and procedures are required to ensure network

controls exist to reduce or prohibit the introduction of
unamortized wiress technology and, to alert of its presence if
introduced.
Network mapping policies require that all segments of the

network (including those where wireless technologies exist)
help to identify authorized segments in the event of question or
audit. These artifacts are also very helpful for maintenance,
disaster recovery, scalability planning, etc.
Wireless network scanning technology enables the end user to

detect unauthorized wireless network devices or network
segments on their network. This technology can be configured
to execute hands-off, scheduled scans of all, or part of a given
network programmatically and to alert of the presence of
previously unmapped or, newly introduced network segments.
Policy / Process / Procedure The current incident response plan should be modified to
include procedures for the detection, location, mitigation, and
remediation of unauthorized wireless technologies.
Procedures should not only include details specific to incident

response, but also in evidence handling and forensic
assessment of unamortized devices.
Audit / Interview / Sample Review Internal and External vulnerability scanning is an inspection of
the potential points of exploit on a computer or network to
identify security holes.
A vulnerability scan detects and classifies system weaknesses

in computers, networks and communications equipment and
predicts the effectiveness of countermeasures.
A mature VMS program typically leverages commercially

available products and / services developed to look for new
and known system exploits. The collection of exploits is
typically vast and derrvied from extensive experience and
research.
Common VMS products include Qualys, Rapid 7, Retina,

MBSA, etc.


research.

MBSA, etc.


research.

MBSA, etc.


research.

MBSA, etc.
Policy / Process / Procedure A viable penetration testing plan seeks to leverage ethical
hacking techniques to determine how far a mallicous actor
could get in a trusted, secure environment.
Audit / Interview / Sample Review A viable penetration testing plan seeks to leverage ethical
Policy / Process / Procedure Remediation reports represent the findings discovered as part
of the Penetration Test. Remediation plans are specific tasks
and timings associated with addressing vulnerabilities
discovered during the test,
This particular control reference indicates the need to ensure

penetration / vulnerability testing spans segments to ensure
that the sum total of the network and application inventory is
covered.
This particular control reference indicates the need to ensure

penetration / vulnerability testing spans segments to ensure
that the sum total of the network and application inventory is
covered.
Policy / Process / Procedure Intrusion Detection / Intrusion Prevention systems (IDS / IPS)
monitor for suspect activity and generate alerts and automated
responses based on pre-determined response profiles.
IDS / IPS platforms operate much like antivirus and other

signature-based solutions whereby, software updates (read:
Signatures) are applied to counter the latest threat. As the
control indicates, updates should be made frequently to ensure
the device is properly configured to defend against the latest
threats.
Policy / Process / Procedure Change Management (i.e. File Integrity Monitoring systems
(FIM)) establishes alerts or notifications in the event key
system components or files are modified or altered.
From a design perspective, it is important to balance the

implementation of this technology against the rate of particular
change. If change is frequent, less rigidity should be applied.
This will ensure against false positives and inaccurate alerting.
If however, little-to-no change is expected, CMDS shoul

d be planned as part of a comprehensive infrastructure and
data protection program.
Policy / Process / Procedure Considerations for this control should be included as part of
the Incident Response Plan.
The Incident Response Plan should also include provision for

change detection (and response) at varying levels of risk and
criticality.
Policy / Process / Procedure Review security policies frequently to ensure accuracy and
relevancy based on business need. Personnel should be
interviewed to verify that all security policies and procedures
are communicated to them. Efforts can include; security
awaareness training and certification procedures for staff or
associates charged with information-handling, account or
infrastructure administration.
ATOS PCI Control Framework Guidance
Control Implementation Effectiveness of Control
See Below See Below
Ensure firewall and router configuration is set to Firewall and router configuration restrict traffic to only
restrict only authorized traffic. authorized communications (for example: restricting
Provide a firewall and router configuration that Firewall and router configuration illustrate an inventory of
permits only established connections into the only established connections into the internal network and
internal network and denies any inbound denies any inbound connections not associated with a
connections not associated with a previously previously established session. Firewall and router
established session. Firewall and router configuration standard must provide the inventory of those
configuration standard must provide the inventory established connections.
of those established connections.
Ensure the firewall and router configuration Prevent the disclosure of private IP addresses and routing
standard reflect this requirement. Ensure the information from internal networks to the Internet.
configuration change management tracking Interviewed personnel and support documentation provide
clearly demonstrates this as a priority (from that any disclosure of private IP addresses and routing
inception and through the course of varying information to external entities is authorized.
changes). Approach and delivery must be
interoperable, repeatable and acted upon by
administrators.
Provide the guidance necessary to ensure this Atos Policy and the Technical System Security guide have
requirement is in place--Any portable computing this listed as a requirement--Any portable computing
device that connects to the network (CDE) have device that connects to the network (CDE) have the
the firewall configuration in place. There is an firewall configuration in place. There is an automated
automated system check before a system is system check before a system is allowed to connect to the
allowed to connect to the CDE. Atos CDE:
installs/configures/supports a security baseline (in • Personal firewall software or equivalent functionality is in
the Atos Technical System Security guide) that is place for all portable computing devices (including
the image for every new build and is enforced on company and/or employee-owned) that connect to the
any devices attempting to connect. Internet when outside the network (for example, laptops
the CDE.
• Personal firewall (or equivalent functionality) is
configured to actively run.
configured to not be alterable by users of the portable
computing devices.
Atos security policy, the firewall and router Atos security policy, the firewall and router configuration
configuration standard and any applicable standard and any applicable Technical System Security
Technical System Security guides clearly illustrate guides clearly illustrate the procedures for managing
the procedures for managing firewalls, that firewalls, that they're in use and easily accessible known
they're in use and easily accessible known to all to all affected parties.
affected parties.
Firewall maintenance requirements should be Realization of this control takes a collaborative effort
spelled out in the organizations SOP. Who has between the sys admins, firewall admins, network admins,
access to the firewall can be determined via role- and management
based access and/or GPO. Firewall maintenance
should almost always be scheduled after core
hours, unless an emergency patch is required
The network lifecycle must be formally tracked, The firewall and router configuration standard provides for
via Microsoft suite or in automation (ServiceNow) the life cycle cradle-to-grave, of ensuring all inbound and
for the inception, changes and approvals to any outbound traffic is understood and has a justification.
inbound and outbound traffic ensuring justification
for each instance.
The firewall and router configuration standard Requirement is effectively communicated in the firewall
(can be in the network standard) provides the and router configuration standard. The current file is
latest configuration file secure from unauthorized stored with only authorized access, synchronized and can
access and that the most current file is be tested at any time.
synchronized.
via Microsoft suite or in automation (ServiceNow) the life cycle cradle-to-grave, of secure and approved
for the inception, changes and approvals to insecure network services, protocols and ports.
secure and approved insecure services,
protocols and ports.
secure and "approved" insecure services,
Based upon the firewall capabilities and Firewall and router configuration:
compatibilities, firewall and router configuration:
1. Set firewall filters to block traffic from the 1. Ensure firewall filters block traffic from the internet that
internet that has a source address from inside the has a source address from inside the network-Set up rules
network-Set up rules on the firewall, router and on the firewall, router and other network gateways that
other network gateways that examine incoming examine incoming packets i.e., drop conflicting source IPs.
packets i.e., drop conflicting source IPs. 2. Filter outgoing packets that have a source address
2. Set firewall rules to filter outgoing packets that different from the internal network to prevent an attack
have a source address different from the internal originating from the local site.
network to prevent an attack originating from the
local site.
Ensure firewall and router configuration is set to Firewall and router configuration restrict traffic to only
restrict only authorized traffic. authorized communications (for example: restricting
Ensure the firewall and router configuration Prevent the disclosure of private IP addresses and routing
standard reflect this requirement. Ensure the information from internal networks to the Internet.
configuration change management tracking Interviewed personnel and support documentation provide
clearly demonstrates this as a priority (from that any disclosure of private IP addresses and routing
inception and through the course of varying information to external entities is authorized.
changes). Approach and delivery must be
interoperable, repeatable and acted upon by
administrators.
Provide the guidance necessary to ensure this Atos Policy and the Technical System Security guide have
requirement is in place--Any portable computing this listed as a requirement--Any portable computing
device that connects to the network (CDE) have device that connects to the network (CDE) have the
the firewall configuration in place. There is an firewall configuration in place. There is an automated
automated system check before a system is system check before a system is allowed to connect to the
allowed to connect to the CDE. Atos CDE:
installs/configures/supports a security baseline (in • Personal firewall software or equivalent functionality is in
the Atos Technical System Security guide) that is place for all portable computing devices (including
the image for every new build and is enforced on company and/or employee-owned) that connect to the
any devices attempting to connect. Internet when outside the network (for example, laptops
the CDE.
configured to actively run.
configured to not be alterable by users of the portable
computing devices.
Atos security policy, the firewall and router Atos security policy, the firewall and router configuration
configuration standard and any applicable standard and any applicable Technical System Security
Technical System Security guides clearly illustrate guides clearly illustrate the procedures for managing
the procedures for managing firewalls, that firewalls, that they're in use and easily accessible known
they're in use and easily accessible known to all to all affected parties.
affected parties.
Firewall maintenance requirements should be Realization of this control takes a collaborative effort
spelled out in the organizations SOP. Who has between the sys admins, firewall admins, network admins,
access to the firewall can be determined via role- and management
based access and/or GPO. Firewall maintenance
should almost always be scheduled after core
hours, unless an emergency patch is required
This configuration change would be made my the Most wireless access points on the market today do not
admin or engineer responsible for setting up the ship with default encryption keys that need to be changed
WAP. upon arrival. An encryption algorithm such as WPA2/AES
or TKIP should be an option for its configuration. It's usage
is strongly encouraged
The adoption of CIS benchmarks in the These configuration standards must meet some hardening
organization is ultimately a management decision standards such as those from SANS or NIST. The Center
and requires their commitment. The benefits of for Internet Security is the primary recognized industry-
leveraging this standard should be considered by standard for secure configuration guidance, developing
all respective teams, and incorporated by the comprehensive, consensus-derived checklists to help
administrator/engineer prior to the installation of identify and mitigate known security vulnerabilities across
any software. a wide range of platforms. CIS benchmarks provide
prescriptive guidance for establishing a secure
configuration posture for your IT Infrastructure, including a
detailed description and rationale of potential
vulnerabilities together with clear auditing and remediation
steps. As such, the CIS benchmarks are the overwhelming
option of choice for auditors worldwide.
By leveraging tools such as SCCM, Chef, By leveraging tools such as SCCM, Chef, Puppet, or
Puppet, or Alienvault's USM appliance, Alienvault's USM appliance, organizations will be able to
organizations will be able to create an run a create an run a custom scan of their environment ensuring
custom scan of their environment ensuring that that each server has only one primary function
each server has only one primary function
organizations will be able to create an run a create an run a custom scan of their environment ensuring
custom scan of their environment ensuring that that each server has only one primary function
each server has only one primary function
organizations will be able to create and run a create and run a custom scan of their environment
custom scan of their environment ensuring that ensuring that only required services, ports, and protocols
only required services, ports, and protocols are are permitted
permitted
All integrated security features should be well- All integrated security features should be well-
documented and follow an established baseline. documented and follow an established baseline. For
For situations where an insecure protocol must situations where an insecure protocol must be used, this
be used, this documentation should spell out how documentation should spell out how a safeguard is being
a safeguard is being leveraged to protect the leveraged to protect the asset
asset
Organizations can ensure that this knowledge set Organizations can ensure that this knowledge set exists
exists by querying their admins. Most CM tools by querying their admins. Most CM tools will allow you to
will allow you to create an run a custom scan of create an run a custom scan of you environment where
you environment where you can ensure than you can ensure than hardening standards are integrated
hardening standards are integrated per policy per policy
The sys admin or integrator should be able to The sys admin or integrator should be able to confirm this
confirm this requirement. A custom scan of the requirement. A custom scan of the environment using
environment using some CM tool can also ensure some CM tool can also ensure that scripts, etc. are not
that scripts, etc. are not able to be ran able to be ran
The sys admin or integrator would be responsible The system administrator or integrator would be
for ensuring admin access is privileged access responsible for ensuring admin access is privileged access
requiring MFA, and utilizes strong encryption requiring MFA, and utilizes strong encryption algorithms.
algorithms. On Windows systems, a reviews of On Windows systems, a reviews of Services will inform us
Services will inform us if insecure remote-login if insecure remote-login services such as Telnet or
services such as Telnet or prohibited prohibited
Software of this type would need to be installed Assets (hardware, software, etc.) are specified and listed
and maintained by an engineer or admin. If into the management software for easy tracking. From
leveraging a SaaS offering, sufficient support here, criticality levels can be set, as well as a list of
from the vendor should be written into the SLA approved software
A quick review of the SOP or SLA should depict As vendors are engaged and their services leveraged, the
verbiage meant to ensure that applicable established SLA should clearly define a SOW, and who is
personnel are aware of the role they play in responsible for various aspects. Applicable admins and
ensuring that vendor defaults are managed and engineers are to be informed that they have a crucial role
reviewed periodically. The criticality of the service to play in ensuring that the vendor implements their
provided such dictate this interval solution properly and that it is kept current
If leveraging a service provider like AWS to When selecting your hosting provider, ensure that they're
maintain cardholder data, the organization must able to logically segment components on the same server,
have intimate knowledge of how this data is to be as isolate assets into their select security zones. These
stored-particularly if the server being used is zones create their own enclave where specific controls
shared by other tenants. The SLA between the can be applied (usually at an additional cost) based on
organization and the provider will define these the nature of the data
aspects.
The PCI DSS defines the Primary Account The PCI DSS defines the Primary Account Number (PAN),
Number (PAN), cardholder name, expiration date cardholder name, expiration date and service code to be
and service code to be sensitive pieces of sensitive pieces of information that need to be protected
information that need to be protected after being after being stored. Either a manual or an automatic
stored. Either a manual or an automatic process process should be set up which identifies which data
should be set up which identifies which data needs to be stored and which needs to be destroyed and
needs to be stored and which needs to be immediate action should be taken on data that needs to be
destroyed and immediate action should be taken deleted. SDelete is a tool for secure removal on Windows
on data that needs to be deleted. SDelete is a platforms. Use the -D parameter for PCI compliant
tool for secure removal on Windows platforms. removal. SRM is a tool for secure removal on Unix
Use the -D parameter for PCI compliant removal. platforms. Use the -p 7 parameter to specify 7 removal
SRM is a tool for secure removal on Unix passes.
platforms. Use the -p 7 parameter to specify 7
removal passes.
For complying to PCI DSS, data that is termed as For complying to PCI DSS, data that is termed as
authentication data should not be stored beyond authentication data should not be stored beyond the
the retention period. This data includes magnetic retention period. This data includes magnetic strip
strip contents, verification code and PIN. The contents, verification code and PIN. The deletion of such
deletion of such data is important as this data is data is important as this data is extremely valuable for
extremely valuable for scammers as they can scammers as they can make fake duplicate payment cards
make fake duplicate payment cards based upon based upon this information. If sensitive authentication
this information. If sensitive authentication data is data is received, follow the company procedure for safely
received, follow the company procedure for safely deleting the data and verify that no recovery of the data is
deleting the data and verify that no recovery of possible.
the data is possible.
The DB admin will be able to show proof that full The DB admin will be able to show proof that full track
track card data is not captured and maintained on card data is not captured and maintained on the database
the database
The DB admin would be able to ensure that this Set neverPersist to true in the
requirement is met via a simple configuration PaymentSystemPluginMapping.xml file. This option
change captures the CVV data and sends it for payment
authorization in a single transaction. This eliminates the
step to temporarily store the CVV data in the database.
The DB admin will be able to ensure that this The DB admin will be able to ensure that this parameter is
parameter is not maintained in the DB not maintained in the DB
Compliance to this requirement entails written Compliance to this requirement entails written policies and
policies and procedures for masking the display procedures for masking the display of Personal Account
of Personal Account Number (PAN). These Number (PAN). These should enlist which roles are
should enlist which roles are authorized to view authorized to view full PAN and the legitimate reason of
full PAN and the legitimate reason of why they why they need to do so. Only the individuals with the roles
need to do so. Only the individuals with the roles enlisted should be able to see full PAN and any
enlisted should be able to see full PAN and any unauthorized individual should see PAN in masked form.
unauthorized individual should see PAN in By default, the last 5 digits of the account number are
masked form. shown in plain text typically. To be PCI compliant, you
must reduce this to the last 4 digits of the account number.
To change this value, open the
PaymentSystemPluginMapping XML file and change the
value of the plain attribute on the <Keyword
name="account" element from -5 to -4.
Per PCI DSS, the Primary Account Number (PAN) Per PCI DSS, the Primary Account Number (PAN) can be
can be stored after a transaction but it must be stored after a transaction but it must be made illegible by
made illegible by using techniques such as using techniques such as encryption, truncation or
encryption, truncation or hashing. If the PAN hashing. If the PAN stores the cardholder name, expiration
stores the cardholder name, expiration date and date and service code, additional efforts to protect the
service code, additional efforts to protect the data data should be adopted. But if they are stored separately
should be adopted. But if they are stored from the PAN then no additional efforts are required.
separately from the PAN then no additional efforts Hence, the storage plan of these pieces of information
are required. Hence, the storage plan of these must be carefully planned to minimize the complexity.
pieces of information must be carefully planned to
minimize the complexity. Key management is also important when encryption is
being used for compliance purposes. To make encryption
Key management is also important when more effective, limit the access to keys used for decrypting
encryption is being used for compliance the cipher text. By limiting the key backup location, not
purposes. To make encryption more effective, only can you restore the key easily in time of need, you
limit the access to keys used for decrypting the can also put a limit to number of individuals who can
cipher text. By limiting the key backup location, acquire and restore the keys.
not only can you restore the key easily in time of
need, you can also put a limit to number of
individuals who can acquire and restore the keys.
A disk encryption solution such as Intel Security A disk encryption solution such as Intel Security (McAfee)
(McAfee) Complete Endpoint Protection, or Complete Endpoint Protection, or Sophos SafeGuard
Sophos SafeGuard Enterprise should be installed Enterprise should be installed and configured by the
and configured by the organization. These organization. These applications typically come standard
applications typically come standard with the with the security features required to be compliant with this
security features required to be compliant with requirement per PCI DSS
this requirement per PCI DSS
Keys should remain in a protected key vault at all Strict policies and procedures should be implemented and
times. In particular, ensure that there is a gap should ensure the following:
between the threat vectors that have direct
access to the data and the threat vectors that Keys are only access by the fewest possible individuals
have direct access to the keys. This implies that Key-encrypting keys are as strong as the data encrypting
keys should not be stored on the application or keys
web server (assuming that application attackers Key-encrypting keys and data encrypting keys are stored
are part of the relevant threat model) in separate locations
Keys are stored in fewest possible locations
If keys are compromised or an external authority The effectiveness of this control can be measured by
expires them, key changes will be needed. maintaining current documentation of the cryptographic
Application polices or emergency needs will force architecture in a protected space within the organization
application administrators to rotate keys and
potentially rekey data at some point. It's best to
be prepared to rapidly handle this need when
necessary. Including a key version and encryption
algorithm version with the encrypted data is a
useful, proactive feature. For instance, including
a simple prefix string, such as "{1,1}...", prior to
the encrypted data could indicate algorithm
version 1, key version 1. This allows for an
"online" change to the encryption algorithm and
key without re-encrypting all existing data all at
once.
Access to the keys must be restricted to the The effectiveness of this control can be measured by
smallest amount of users possible. This group of reviewing policy around how encryption keys are
users will ideally be users who are highly trusted maintained as well as the key vault itself
and trained to perform Key Custodian duties.
There will obviously be a requirement for
system/service accounts to access the key data
to perform encryption/decryption of data.
Store secret and private keys used to The effectiveness of this control can be measured by
encrypt/decrypt cardholder data in one (or more) reviewing policy around how encryption keys are
of the following forms at all times: maintained as well as the key vault itself
- Encrypted with a key-encrypting key that is at
least as strong as the data-encrypting key, and
that is stored separately from the data-encrypting
key
- Within a secure cryptographic device (such as a
host security module (HSM) or approved point-of-
interaction device)
- As at least two full-length key components or
key shares, in accordance with an industry-
accepted method.
Cryptographic key storage areas are to be limited The effectiveness of this control can be measured by
to environments designed to maintain them, and reviewing policy stating where encryption keys are
where they are deemed absolutely critical maintained and why
The organization should have a complete The effectiveness of this control can be measured by
understanding of how to securely store, transmit reviewing policy addressing all eight (8) applicable sub-
and update the keys without disclosing them to requirements to this control
an unauthorized entity.
The organization must generate strong keys so The effectiveness of this control can be measured by
that the security of the data isn't undermined by reviewing conducting internal pen testing to determine if
weak cryptographic keys. A strong key is the key is weak. A review of the algorithm being used will
generated by using a key length which is also be beneficial
sufficient for your data security requirements and
compliant with the PCI DSS. The key size alone
isn't a measure of the strength of a key. The data
used to generate the key must be sufficiently
random ("sufficient" often being determined by
your data security requirements) and the entropy
of the key data itself must be high.
The method used to distribute keys must be The effectiveness of this control can be measured by
secure to prevent the theft of keys in transit. The reviewing the key vault distribution setting to conclude that
use of a protocol such as Diffie Hellman can help a secure protocol is being used
secure the distribution of keys, the use of secure
transport such as TLS and SSHv2 can also
secure the keys in transit. Older protocols like
SSLv3 should not be used.
Configure key management software to store the The effectiveness of this control can be measured by
merchant key (in encrypted format) in an external reviewing the key management system settings and
file. Specify a key encryption key in a separate configuration
file, which is used to encrypt the merchant key.
Each file should be protected with file system
protection.
The PCI DSS standard mandates that keys used The effectiveness of this control can be measured by
for encryption must be rotated at least annually. reviewing the key management system settings and
The key rotation process must remove an old key configuration
from the encryption/decryption process and
replace it with a new key. All new data entering
the system must encrypted with the new key.
While it is recommended that existing data be
rekeyed with the new key, as per the rekey data
at least every one to three years rule above, it is
not clear that the PCI DSS requires this.
The key management processes must cater for The effectiveness of this control can be measured by
archived, retired or compromised keys. If retired reviewing the key management system settings and
or replaced cryptographic keys need to be configuration
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.
The requirement for split knowledge and/or dual The effectiveness of this control can be measured by
control for key management prevents an reviewing the key management system settings and
individual user performing key management tasks configuration
such as key rotation or deletion. The system
should require two individual users to perform an
action (i.e. entering a value from their own OTP)
which creates to separate values which are
concatenated two create the final key data.
The system put in place to comply with The effectiveness of this control can be measured by
requirement 3.6.6 can go a long way to reviewing the key management system settings and
preventing unauthorized substitution of key data. configuration
In addition to the dual control process you should
implement strong access control, auditing and
logging for key data so that unauthorized access
attempts are prevented and logged.
To perform the strong key management functions The effectiveness of this control can be measured by
we have seen in requirement 3.6 we must have reviewing the forms signed by the custodians
highly trusted and trained key custodians who
understand how to perform key management
duties. The key custodians must also sign a form
stating they understand the responsibilities that
come with this role.
In order to comply with this requirement, it is The effectiveness of this control can be measured by
necessary that personnel are well aware of assessing the results from personnel interviews
security policies and procedures to manage the
safe storage of cardholder data on a regular
basis. Personnel should be interviewed from time
to time to verify that they understand and
implement those policies and operational
procedures in their routine work involving
cardholder data handling.
It is important to keep in mind that some of the To meet the requirements of the PCI-DSS, you must
authentication protocols such as TLS 1.0, SSL disable weak keys and protocol implementations (such as
v2.0 and SSH v1.0 have vulnerabilities known to SSL v2.0, SSL v3.0, SSH v1.0 and TLS 1.0) that have
hackers and can easily be exploited by them for known vulnerabilities. These encryption types are
getting information access or even diverting the considered too weak for PCI-DSS compliance. Instead,
information flowing across a network. Hence, to you should use stronger implementations like TLS 1.1 or
prevent this exploitation, protocols should be higher
configured with their secure versions only.
The organization can gauge the effectiveness of The use of WEP and any other algorithm proven to be
this control by reviewing the wireless access point ineffective as a security control must be prohibited within
configuration with an administrator and confirming wireless networks
that weak encryption schemes are not in use
The organization can gauge the effectiveness of Messaging tools such as packet sniffers (which can be
this control by ensuring that messaging tools used for legitimate purposes by a network admin) should
responsible for sending data be configured to only be used for sending information if they have been
encrypt the data being sent or received configured to encrypt the data being sent or received
The organization can gauge the effectiveness of To comply with this PCI DSS requirement, it is important to
this control by establishing periodic reviews of the draft strong policies and procedures regarding the
security policy and interviewing sample sets of protection of cardholder data over a network. There should
users be policies for strong encryption, authenticated protocols
and the use of reliable keys and certificates. Moreover,
these policies and procedures should be communicated to
every individual member of the staff and it should be
ensured that every individual understands them
The anti-virus solution is an application to be In order to be assured that anti-virus is installed and
installed onto the client it is meant to protect. This protecting the endpoint or host, a screenshot will suffice as
can be done manually, as part of an image, or an artifact. This artifact should depict that the endpoint has
remotely executed the most up to date DAT file.
The anti-virus solution is an application to be In order to be assured that anti-virus is installed and
installed onto the client it is meant to protect. This protecting the endpoint or host, a screenshot will suffice as
can be done manually, as part of an image, or an artifact. This artifact should depict that the endpoint has
remotely executed the most up to date DAT file.
A vulnerability scan or pentest on the client is a For systems with distinct operating systems, a formal
definite act that should be carried out by an testing plan should exist to ensure these systems exude
experienced professional no signs of compromise (vulnerability scans, internal
pentest, etc.)
On a periodic basis, members of the OPSEC This capability will either reside on-premise within an
team can run a report, or view via the dashboard enclave or in the cloud. It is testable and configurable per
the current status of all systems within the the organization's requirement.
organization with an anti-virus client. The
capability to monitor threats, signatures fired, and
processes terminated will exist with this platform
This capability can either be reviewed in the This capability can either be reviewed in the vendors
vendors documentation regarding their product, documentation regarding their product, or selectively.
or selectively. enabled. The organization can enabled. The organization can confirm the existence of a
confirm the existence of a HIDS solution by HIDS solution by looking within installed programs on the
looking within installed programs on the endpoint, endpoint, or reviewing the logs feeding into a SIEM
or reviewing the logs feeding into a SIEM
The organization can gauge the effectiveness of A strict policy prohibiting the alteration or disablement of
this control by ensuring that all systems have an the anti-virus should be communicated to the staff to stop
AV client installed and running in real-time. A any weaknesses from potential exploitation. If the anti-
report sample should be generated regularly from virus is disabled for some amount of time due to any
the manager to ensure this is being met reason, extra security measures should be taken such as,
disabling internet connection before disabling anti-virus,
and then performing a system scan after enabling it again.
If an anti-virus program needs to be disabled because of
any technical reasons, permission must be taken by the
authority
The organization can gauge the effectiveness of To make sure that every individual is aware of security
this control by establishing periodic reviews of the policies and operational procedures of an organization,
security policy and interviewing sample sets of and to ensure maximum protection of the network from
users malware, personnel should be communicated the
organizational policies and procedures regarding malware
protection
IA and Cyber Security resources have access to IA and Cyber Security resources have access to a variety
a variety of industry related sources for of industry related sources for vulnerability and risk related
vulnerability and risk related news and news and information
information
Policy and process documentation as well as the
Policy and process documentation as well as the associated mechanism exists related to patches, risks and
associated mechanism exists related to patches, vulnerabilities
risks and vulnerabilities
System components and software have the latest System components and software have the latest vendor-
vendor-supplied security supplied security
patches installed. Critical patches are consistently patches installed. Critical patches are consistently applied
applied within a month of release. within a month of release.
Remove development, test and/or custom Processes, mechanisms and records of code review / peer
application accounts, user IDs, and review / manual or automated testing / verification and
passwords before applications become active or validation should occur and be evident throughout the
are released to customers. lifecycle
Review developed code periodically

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.
Periodic training and audits are conducted to Periodic training and audits are conducted to ensure that
ensure that responsible personnel know how to responsible personnel know how to incorporate security
incorporate security best practices in their coding best practices in their coding and that they implement that
and that they implement that knowledge into their knowledge into their coding practices
coding practices
Remove development, test and/or custom Processes, mechanisms and records of code review / peer
application accounts, user IDs, and review / manual or automated testing / verification and
passwords before applications become active or validation should occur and be evident throughout the
are released to customers. lifecycle
Review developed code periodically

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.
Periodic Reviews are conducted and Periodic Reviews are conducted and documented in the
documented in the Policy or Procedure change Policy or Procedure change history. Resulting changes or
history. Resulting changes or updates would be updates would be recorded as a separate line item
recorded as a separate line item
Development/test functions are separated from Periodic audits and training are scheduled and the results,
production functions. in the form of audits reports and training records are
available for review and action as indicated
In environments where one individual performs
multiple roles (for example application
development and implementing updates to
production systems), duties are assigned such
that no one individual has end-to-end control of a
process without an independent checkpoint.
Assign roles based access that aligns with the Periodic audits and training are scheduled and the results,
roles and responsibility of the resource within in the form of audits reports and training records are
each system or application available for review and action as indicated
Include assignment cleanup as part of the project

closeout process to ensure that roles are
maintained at the highest level of restriction
possible
Conduct periodic review of process Periodic audits and training are scheduled and the results,
documentation, periodic process audits and/or in the form of audits reports and training records are
training to ensure and verify that mock data, available for review and action as indicated
rather than live data is used for testing and
development
Conduct periodic review of process Periodic audits and training are scheduled and the results,
documentation, periodic process audits and/or in the form of audits reports and training records are
training to ensure and verify that test data and available for review and action as indicated
account information is removed before transition
to the live system
A Change Review Board or equivalent function A Change Review Board or equivalent function will have
will have scheduled meetings and an agenda to scheduled meetings and an agenda to review and approve
review and approve upcoming updates and upcoming updates and implementations.
implementations.
CRB Meeting Minutes and artifacts should be available for
CRB Meeting Minutes and artifacts should be review and reference
available for review and reference
implementations.
implementations.
implementations.
implementations.
implementations.
Identify the policy/process/work instructions that The organization's recurring training function includes
directs the organization to ensure developers are training for Developer's Secure Coding Techniques that is
trained and current in secure coding techniques administered at least annually.
that are relevant to the application coding
languages used. The organization's onboarding process includes roles
based training requirements for new hires, including
The secure coding techniques must be based on Secure Coding Techniques for Developer roles
industry best practices or standards.
Developer training, which can either be

conducted in-house or by a qualified third party, is
deemed sufficient for PCI compliance once each
developer is able to both identify and resolve all
known common coding vulnerabilities.
Developers should receive secure code training
upon hire and at least annually. It is
recommended to have developers sign an
agreement or ideally pass an exam to
demonstrate compliance with requirement 6.5.
Note: Refer to the OWASP Top Ten for further

details on required training materials to cover
6.5.1 - 6.5.10


6.5.1 - 6.5.10


6.5.1 - 6.5.10


6.5.1 - 6.5.10


6.5.1 - 6.5.10


6.5.1 - 6.5.10


6.5.1 - 6.5.10


6.5.1 - 6.5.10
The secure coding techniques must be based on based training requirements for new hires, including
industry best practices or standards. Secure Coding Techniques for Developer roles
NOTE: Refer to the OWASP Top Ten for further

6.5.1 - 6.5.10


6.5.1 - 6.5.10
The secure coding techniques must be based on based training requirements for new hires, including
industry best practices or standards. Secure Coding Techniques for Developer roles

6.5.1 - 6.5.10
The review or internal audit is scheduled. Provide periodic reviews to ensure that public-facing web
The review or audit plan is communicated. applications are secured via manual or automated
Stakeholders and responsible resources are application vulnerability security assessment tools or
notified. Process documentation and evidence of methods, at least annually and after any changes.
the performance of the process is reviewed.
Non-conformances are noted and documented. An automated technical solution is in place that detects
Results are presented and reviewed. Corrective and prevents web-based attacks (for example, a web-
actions are identified, planned and assigned. application firewall) in front of public-facing web
Follow up activities and effectiveness reviews are applications, to continually check all traffic.
completed
All development personnel, and any other staff A process for conducting this review will also be
and third parties that are subject to the documented.
development policies and procedures will be
made fully aware of the requirements.
All documentation must be readily available to all

personnel involved in application development,
for instance, allowing staff to find and access the
documentation by placing them onto the
company intranet.
As the identity management system is By using an identity management system, the organization
onboarded, roles are created for specific job would know with assured certainty that RBAC is
functions, and a subject has to be assigned to a implemented. Even with legacy systems and software, the
role to execute actions that are authorized for the components of an identity management system - the
role. The system assigns permissions to job provisioning and credentials servers - can be used to
functions based on operations rather than to translate the roles information for the legacy software.
resource objects
Within an identity management system, as roles An identity management system would assist the
are assigned and mapped to job functions, it organization in ensuring that principles of least privileges
must be ensured that each role created has the is adhered to. In order to prevent privilege creep, it
absolute minimum amount of privileges assigned becomes necessary for each role, function, and user
to perform their job tasks. This becomes account mapped to be reviewed periodically
increasingly important with the creation of admin
role function
As the identity management system is By using an identity management system, the organization
onboarded, roles are created for specific job would know with assured certainty that RBAC is
functions, and a subject has to be assigned to a implemented. Even with legacy systems and software, the
role to execute actions that are authorized for the components of an identity management system - the
role. The system assigns permissions to job provisioning and credentials servers - can be used to
functions based on operations rather than to translate the roles information for the legacy software.
resource objects
Within the IAM system, these are built-in By utilizing an IAM system, maintaining a record of admin
capabilities and feature sets that simply must be accounts, and requesting approval becomes seamless.
enabled and configured. Most system will keep track of all your admin users for
you, and send an inquiry to management periodically to
ensure that an individual still require this level of access.
Most IAM systems can now be configured to have admin
access requests be routed to two or three system owners
for their blessing before access can be granted
To ensure that this capability exists and is in To ensure that this capability exists and is in place, once
place, once each new application or system is each new application or system is stood up an admin
stood up an admin needs only to attempt to login needs only to attempt to login via a credential set that has
via a credential set that has not been explicitly not been explicitly permitted access. As long as the
permitted access. As long as the authentication authentication attempt is unsuccessful, the test can be
attempt is unsuccessful, the test can be deemed deemed a success.
a success.
a success.
a success.
a success.
The SOP can easily be reviewed to detect any The SOP can easily be reviewed to detect any
shortcomings in organizational policies, as well as shortcomings in organizational policies, as well as confirm
confirm principles such as least privilege exist. principles such as least privilege exist. This artifact should
This artifact should be revised in accordance with be revised in accordance with industry standards
industry standards guidelines guidelines
Organizational policies and procedures should be All security policies and operational procedures regarding
readily available an visible to all employees for the restricted access to cardholder data should be put in a
review within a secure area documented format, implemented and communicated to all
the parties involved
User access controls are in place and used by 1 user = 1 User ID

the appropriate user administrators so that each
user ID is uniquely assigned to an individual user.
No "generic" user IDs are created or permitted
by policy
User access controls are in place and used by 1 user = 1 User ID

the appropriate user administrators so that each
user ID is uniquely assigned to an individual user.
No "generic" user IDs are created or permitted
by policy
Any changes to the list of and access rights to the Successful implementation would result in full alignment
user database must be requested and authorized between user access requests with actual user access
by the System Access Request process. No privileges
adds, deletions or changes are made without a
completed and approved request.
The only exceptions are authorized administrative
changes to correct errors that are identified
during periodic reviews.
HR Process documentation for terminated Terminated employees have their assigned physical
employees includes initiating a SAR request with authentication methods retrieved and access rights are
the required information. terminated within the required time limits
responsible HR resources are trained and use
the process as published and instructed
System Access Administrators will have No Windows systems have unused or disabled accounts
documented processes for conducting an inactive
user review. The process may include automated
reporting and/or manual user activity reviews.
Assigned personnel will be trained and will use
the published process to conduct the review and
complete any required actions
System Access Administrators and Vendors will Vendors will not have access to the systems without
have a documented and published process for submitting a request and receiving authorization. All
requesting and conducting vendor related Windows guest accounts are disabled
maintenance and support. This process will
include steps for activating and deactivating
vendor access as well as guidance to monitor the
support or maintenance activities
User Access Management policy will set the No Windows systems have accounts that have never
standards for failed access lock-out. These logged in or never changed their password
standards will be implemented at the network,
system / application and user levels as
appropriate
System Access Admins will have process and

work instructions for authenticating and
reactivating locked users. Automated "self
service" tools may be used to facilitate the
process and reduce manual intervention while
maintaining system integrity.
User Access Management policy will set the No account lockout configuration checks failed
standards for failed access lock-out. These
standards will be implemented at the network,
system / application and user levels as
appropriate
System Access Admins will have process and

work instructions for authenticating and
reactivating locked users. Automated "self
service" tools may be used to facilitate the
process and reduce manual intervention while
maintaining system integrity.
User Access Management policy will set the No session lock/termination configuration checks failed
standards for application/system timeout.
User Access Management policy and processes No password configuration checks failed
will set the standards for user passwords and/or
other authentication methods.
Passwords must meet the minimum standards

set by the policy:
▪ Length
▪ Numbers/Letter/Special
▪ Not reused
▪ Not matching ID
▪ Non-repeating
Process for distributing and initializing tokens /

smart cards
Process for setting up biometric devices
Identify files that contain PAS information and Passwords files are unreadable both at rest and in transit.
implement a technical solution that masks, at a
minimum, the number of digits required by the
PCI-DSS standards and increase the number of
digits masked to maximize protection while still
allowing resources the ability to use the PAS info
as required for their role and responsibility.
The user creation process will include having the Users requesting account support will be asked to verify
user set up a number of security questions and their identity using the security questions and answers
answers. provided in their user profiles. Disabled accounts will not
be unlocked and no changes or updates will be made
unless the security questions are answered correctly.
The user creation process will include having the Applied password prevent unauthorized users from
user set up a password that is validated against guessing user ID login information thus reducing the risk of
the established requirements unauthorized access to organizational systems and
applications.
Network / System / Application settings would be Account passwords that are not change within the 90-day
set to force passwords to change every 90 days, requirement would be disabled and require an authorized
at a minimum. Users receive reminders started user to request a password reset to unlock their profile to
15 days before the password expiration and are access the system / application.
prompted to change their passwords via a self
service portal or via their technical support team.
Account passwords that are not change within

the 90-day requirement would be disabled and
require an authorized user to request a password
reset to unlock their profile to access the system /
application.
Network / System / Application settings would Preventing the repeated use of passwords or passphrases
securely save the last 4 passwords used and provides additional security and reduces the risk of
prevent users from applying any of those unauthorized access via the use of an old password that
passwords / pass phrases as a new passwords / may have been found, discovered or recovered.
pass phrase.
Network / System / Application Policy and Forcing initial passwords and reset passwords to either
process would require initial passwords and change or expire within 24 hours minimizes the risk of
resets to follow the same requirements as the unauthorized access via the usage of common set up or
published password policy. reset passwords.
In addition, initial passwords and reset passwords

will be set to expire after a set timeframe if they
are not changed.
Users are prompted to change their password

immediately after their first login with the
temporary password and are provided with
linkage to the self serve support application for
password changes
See Below See Below

This requirement is intended to apply to all Only users with 2 factor authentication will be allowed to
personnel with administrative access to the CDE. have administrative access to the CDE. This reduces the
This requirement applies only to personnel with risk of unauthorized access via the discovery or recovery
administrative access and only for non-console of a user password alone.
access to the CDE; it does not apply to
application or system accounts performing
automated functions.
If the entity does not use segmentation to
separate the CDE from the rest of their network,
an administrator could use multi-factor
authentication either when logging onto the CDE
network or when logging onto a system.
If the CDE is segmented from the rest of the
entity’s network, an administrator would need to
use multi-factor authentication when connecting
to a CDE system from a non-CDE network. Multi-
factor authentication can be implemented at
network level or at system/application level; it
does not have to be both. If the administrator
uses MFA when logging into the CDE network,
they do not also need to use MFA to log into a
particular system or application within the CDE.
This requirement is intended to apply to all Only remote users with 2 factor authentication will be
remote personnel with user and administrative allowed to have access to the CDE. This reduces the risk
access to the CDE. of unauthorized access via the discovery or recovery of a
If the entity does not use segmentation to user password alone.
separate the CDE from the rest of their network,
an administrator could use multi-factor
authentication either when logging onto the CDE
network or when logging onto a system.
If the CDE is segmented from the rest of the
entity’s network, an administrator would need to
use multi-factor authentication when connecting
to a CDE system from a non-CDE network. Multi-
factor authentication can be implemented at
network level or at system/application level; it
does not have to be both. If the administrator
uses MFA when logging into the CDE network,
they do not also need to use MFA to log into a
particular system or application within the CDE.
Policy and Process documentation is published Users are familiar with and trained on policy and process
and periodically reviewed and updated. related to password security. Users can locate the
Policy and Process documentation is appropriate published references.
communicated to the appropriate user community
Policy and Process training is provided during on
boarding and periodically
Policy and Process documentation is published to ▪ Generic user IDs are disabled or removed.
periodically review the active user list to ensure: ▪ Shared user IDs do not exist for system administration
and other critical functions.
 Generic user IDs are disabled or removed. ▪ Shared and generic user IDs are not used to administer
 Shared user IDs do not exist for system any system components.
administration and other critical functions.
 Shared and generic user IDs are not used to
administer any system components.
Automated reporting or manual reviews will be

conducted to complete the review per the client
site's capabilities and environment.
Utilize a random password or pass phrase Atos resource working at multiple client engagements will
generators or another industry accepted method have unique passwords and pass phrases for each site
for ensuring unique passwords and pass with no re-use or duplication.
phrases, even across multiple customers
Policy and Process documentation is published to Physical authentication mechanisms are assigned to 1
periodically review the active user list to ensure: specific user.
▪ Generic user IDs are disabled or removed. Only the account holder assigned to the mechanism can
▪ Shared user IDs do not exist for system use it to gain access.
administration and other critical functions.
▪ Shared and generic user IDs are not used to Policy and process is published and communicated that
administer any system components. guides the use and control of physical authentication
mechanisms.
Automated reporting or manual reviews will be
conducted to complete the review per the client
site's capabilities and environment.
Non-DBA users will not have direct access to Only authorized and authenticated users have direct
query the data. Instead, access should be access to database containing cardholder data. This
provided through programmatic methods only, minimizes the chances of unauthorized and malicious
e.g. through stored procedures. individual gaining access to the system.
No user activity can go untraced as each ID is linked to a

known user.
Policies and procedures are configurable items All affected parties (employees, contractors, vendors, etc.)
and should be included in the organizations CM are aware of, familiar with, and adhere to the policies and
Database process. process for security in and around the CDE
Onboarding and refresher training will be
addressed via the organizations HR/Training
departments or at the group level as appropriate
to the organization.
Reviews and Audits will be addressed by the
organizations QA function to ensure continues
compliance.
Select and install physical controls and implement Only authorized personnel and visitors are granted access
policy and procedures for their effective use and to the CDE. Controls are able to track, monitor and log
management. user access. Systems are locked at all times when not in
use.
Ensure coordination between IT and Security to
ensure system operation and enforcement of
both eh physical security and data security within
the CDE
Video surveillance and access logging should be All physical user access to the CDE is monitored,
considered in the design of a data center, recorded, logged, saved and retrievable for no less than 3
computer room, or other physical area with months.
systems in the CDE.
Where these controls are not already in place,

facilities upgrades should be planned and
implemented to ensure compliance with
Requirement 9 of the DSS
Disable or disconnect publicly available jacks that Only authorized users are able to gain access to network
are not in use. Ensure logical measures are in resources
place that prevent unauthorize access to the
network.
Ensure that wireless access points, gateways, Only authorized users are able to wireless access points,
handheld devices, networking/communications gateways, handheld devices, networking/communications
hardware, and telecommunication lines are hardware, and telecommunication lines are adequately
adequately secured in order to minimize the risk secured in order to minimize the risk of unauthorized
of unauthorized access or tampering access or tampering
Physically identify employees / contractors / Documented policies and procedures for visitors verify
vendors and visitors by implementing a badging that:
system that clearly and visibly differentiates to
various categories of personnel and include New onsite individuals are distinguished from the regular
processes that direct access level and duration employees .e.g. by assigning a badge.
based on an Access Request Process. Access to the distinguishing mechanism such as assigning
badges, is limited to only authorized staff.
Visitor and Vendor access will expire at a Visitor identification mechanism, e.g. badge, is cancelled
designated time. Employees and Contractors as soon as the visitor leaves. For example, the authorized
may have to renew periodically per Client staff has the responsibility to take back the badge before
requirements and guidance. the visitor leaves.
Access must be controlled in such a manner that When a visit of an authorized individual to a sensitive area
only those employees should be allowed to visit ends, it should be ensured that all access permissions are
the sensitive areas, who have a work-related taken back from him/her and they cannot get access to the
need and are properly authorized. The following CDE again without authorized approval. It should also be
elements must be considered before granting verified that none of the recently terminated employees of
access to cardholder data environment: the organization are trying to gain access to these areas.
The duration of access

Permissible level of access
Purpose of access
To achieve compliance in this area, requirements Only authorized and escorted visitors are authorized into
9.4.1 through 9.4.4 must be met and verified by the CDE thus, reducing unauthorized access of malicious
the authority. individuals to the cardholder data environment.
All visitors should be verified before granting Only authorized and escorted visitors are authorized into
access and must be escorted throughout their the CDE thus, reducing unauthorized access of malicious
visit to areas holding cardholder data. individuals to the cardholder data environment.
Visitor identification such as visitor badges must Only authorized and escorted visitors are authorized into
be identifiable from the inside personnel and the CDE thus, reducing unauthorized access of malicious
should be expired after a certain condition is met. individuals to the cardholder data environment.
Visitors must be asked to return their badges Only authorized and escorted visitors are authorized into
before leaving the facility. the CDE thus, reducing unauthorized access of malicious
individuals to the cardholder data environment.
Maintain a visitor log to keep a record of all Only authorized and escorted visitors are authorized into
individuals visiting the areas holding sensitive the CDE thus, reducing unauthorized access of malicious
information. These logs must mention the name individuals to the cardholder data environment.
of the visitor, the company on whose behalf they
are visiting and the inside personnel who granted
them access.
Keep the log records for a minimum of three
months.
Authorized users follow the published processes Policy and Process related to physically securing all media
for securing all media, including but not limited to: will be published, communicated and trained.
▪ Printed media Cardholder data is prone to being compromised if it is kept

▪ Reports, queries, lists, receipts etc unprotected in a system, on a piece of paper on a desk or
▪ Portable Electronic Media even kept unsecured in portable media. Media is not
▪ CD/DVD, Thumb drives, hard drives, etc limited to backup data at a long term storage facility
Storing backup media in a safe offsite location also

prepares the organization to prepare for a business
continuity plan to cater for safe backup in times of disaster.
Assign resources and schedule review with Annual reviews should ensure that security protocols are
review criteria in place. sufficient and effective or make recommendations to
improve protocols or identify opportunities for improvement
in performance.
See Below See Below
Policy and process will be published, All media is has a classification and responsible resources
communicated and implemented to responsible are knowledgeable in the proper handling of said media
personnel that clearly defines the various types of
media that the organization may create, receive
or otherwise manage. Process documentation
will provide guidance on the storage, transfer,
transmission and destruction of all media,
depending on is classification.
The organization will engage the services of a All media transfers are secure, logged, tracked and
secure courier and implement processes to verifiable
ensure that media transfers are secure, logged,
tracked and verifiable
Processes will ensure that media transport from a Processes will ensure that media transport from a secure
secure area does not take place without area does not take place without management approval
management approval
Policy and process will be published, The organization has minimized the risk of stolen or
communicated and implemented to responsible missing media going unnoticed by having current and
personnel that clearly defines the various types of accurate inventories of sensitive media.
Policy and process will be published, The organization has minimized the risk of stolen or
communicated and implemented to responsible missing media going unnoticed by periodically reviewing
personnel that clearly defines the various types of the inventory logs for of sensitive media.
Periodic Reviews are conducted and Policy and processes documentation related to the
documented in the Policy or Procedure change storage, transfer, transmission and destruction of sensitive
history. Resulting changes or updates would be media is current, relevant and aligned with the appropriate
recorded as a separate line item best practices, rules and regulations.
The organization shall establish policy and Sensitive media, in both electronic and hard copy formats
processes to provide training and periodic are destroyed or made unreadable when no longer
process audit to ensure that policy and needed and thereby reducing the risk that sensitive data
processes related to the storage, transfer, could be compromised by unauthorized personnel
transmission and destruction of sensitive media
are trained and followed.
The organization publish and maintain policy and No electronic media is disposed of without first ensuring
procedures to employ verifiable methods for that any sensitive data is destroyed and unrecoverable by
securely destroying electronic media include means of the approved and required electronic media
secure wiping, degaussing, or physical destruction process
destruction (such as grinding or shredding hard
disks).
See Below See Below
Asset Management policy and procedures will All assets are accounted for as part of the organizations
provide the guidance and mechanisms to asset management system.
maintain an up-to-date list of devices. At a
minimum, the list will include the following: All devices can be identified at the assigned location
• Make, model of device No devices are found to be not on the asset list
• 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.
Policy and procedures will be published, trained Employees are trained, knowledgeable and use the
and implemented to provide guidance for periodic appropriate processes to protect devices from being
inspection of devices to detect and report tampered with or replaced by unauthorized personnel
evidence of tempering or replacement.
HR and internal training programs will offer point- Employees are trained, knowledgeable and use the
of-sale security training to new hires and as appropriate processes to protect devices from being
periodic refresher training to employees based on tampered with or replaced by unauthorized personnel
assigned roles and responsibilities.
Policies and procedures are configurable items All affected parties (employees, contractors, vendors, etc.)
and should be included in the organizations CM are aware of, familiar with, and adhere to the policies and
Database process. process for security in and around the CDE
Onboarding and refresher training will be
addressed via the organizations HR/Training
departments or at the group level as appropriate
to the organization.
Reviews and Audits will be addressed by the
organizations QA function to ensure continues
compliance.
Permitted actions without proper authentication or The effectiveness of this control can be measured by
identification should be strictly limited. In addition, frequent audits of the user directory compared to a similar
the use of generic user accounts or, access to review of system access. System activity that does not
system accounts with root access should specifically relate to an individual named-user should be
discouraged. User accounts should be directly discouraged and eliminated where possible.
related to named users through the use of
account creation or modification policy.
The process to track and monitor user access to The effectiveness of this control can be demonstrated by a
cardholder data should be automated to avoid review of system activity contrasted against a review of
any human error. Besides this, every user activity audit events generated programatically. Gaps in the
during log-in time should also be recorded. The logging process should be addressed from a development
data should further be sorted out in such a perspective and sufficiently enabled as to both, cover all
manner that the users who made access to system activity while avoiding increases to system
important and private information over the performance or resource utilization.
network should be separated from the rest.
Automation should include notification processes
to alert in the event of data move, copy
modification of removal.
All user account creation, modification of removal The effectiveness of this control can be demonstrated by
should be logged to include, the date and time of test modification of non-production accounts and a
the change, the user account effecting the subsequent review of audit activities.
change and the type of change executed.
Simply stated: If it is not known which users were
logged in at the time of an incident, it is not
possible to identify users that may have been
involved.
All audit log clearing actions should be recorded Sample or Test data should be deleted and testing of
and any individual found guilty of log clearing automated notification and/or logging processes
should be questioned. To limit the possibility of demostrated.
such an event, it is important to restrict the rights
of log clearing to a few authorized individuals only
Every access to the system level objects needs Control effectivness can be demontrated by establishing a
to be closely monitored, but what is more test or control environment by which to make changes that
important is the monitoring of any creation and will not affect production acitivity. Modification of system
deletion of these objects. To achieve this, it is level objects should enabled automated notifications or, at
important to log every user activity on system minimum, generated sufficient log data as to depict the
level objects, such as the name of the user, his user making the change, the type of change made and the
access rights, and the time of access. This data date and time of the change.
can further help finding out whether there was
any creation and/or deletion at that particular time
when the user accessed the particular area. To
achieve full compliance to this requirement, it is
recommended to isolate all system level objects
and get the record of all activities on those
objects.
All systems should be verified to ensure that time The effectivness of this control can be demonstrated a by
synchronization technology is in use and review of time synchronization capabilities between
functional from a common and reliable source. systems and, attempted change of system time against
the system master time controlled. Changes beyond that
of the pre-determined time synchronization controlled
should be denied.
should be denied.
should be denied.
All systems should be verified to ensure that time The effectivness of this control can be demonstrated by a
should be denied.
This requirement maintains that assessment trails The effectiness of this contrl can be demonstrated by
should be secured so that they cannot be altered. establishing test accounts with standard and elevated
As such, strict access control based on need-to- privlidges. Both account types should attempt to access
know classification should be enabled. The use of restricted audit or log data including attempts to modify
system accounts with an ability to delete or this data.
modify audit data should me heavily controlled
(as these can be used anonymously for malicious Account types that are successfully validated could be
purposes). User accounts should be tied to used as account templates from which to base future
specific individuals and the actions of these account creation.
accounts audited frequently.
Implementation of File Integrity Monitoring tools The effectivness of this control can be demonstrated by
(Tripwire, Verisys, CimTrack, etc.) to alert to enababling File Integrity Monitoring tools and
changes of mission-critical, or information- corresponding notification protocols. Test changes made
sensitive log files. to sample data should generate corresponding alerts and
notifications based on the action taken.
Alerting should be set to notify of Change and to
alert administrators directly based on unplanned
deletion to removal.
It is recommended to daily review logs of all the An effective log review or audit program outlines first; a
system components which store, process or process to identify and prioritize logs to be reviewed then
transmit cardholder data or that have indirectly an a schedule and task assignments for the review.
impact on the cardholder data. Review and check
a sample of all system components and servers Automation can be applied to search for anomalous
that carry out security functions. behavior however, this type of review (read: automated) is
not recommended if discreet changes to data are
suspected.
suspected.
suspected.
suspected.
Audit logs must be saved for a minimum time Control effectivness can be demonstrated by a review of
period of one year to cater for the fact that many log retention and log recall procedures to include:
times a security compromise is discovered quite
after some time of its actual occurrence. These Logs greater than three-months old.
logs should be stored online as offline storing of Logs less than three-months old.
logs would result in delayed availability.
Logs greater than three-months old may require more than
At least 3 months old logs should be kept one business-day to access. However, logs less than
somewhere where they are readily available at all three-months old should be available near real-time. This
times. Audit policies and procedures should be is necessary in the event a security episode is identified
examined and personnel should be interviewed to and immediate access to relevant log data is neccessary
verify that proper audit log retention policies exist, to determine how the system was accessed, the exten of
and that official procedures exist to maintain audit the changes made and, the user account responsible for
logs for one year along with immediately available the change.
3 months old logs
A comprhensive device health and activity The effectivness of this control can be demonstrated by
monitoring program includes automated establishing a test environment from which to work and,
notifications in the event of intended or systematically disabling key portions of the environment to
unintended outage. Escalation procedures should demonstrate the corresponding alert. Alerts that are
be developed and enabled to cascade intentionally not acknowledged should casdace to the next
notifications that are not addressed or responded level of management per the defined escalation
to within a period of time determined to match the procedures.
criticality of the infrastructure item. (i.e. "Firewall
Outage Notifications will be responded to within
15 minutes. Notifications within 15 minutes that
are not acknowledged will be escalated to a
supervisor or manager...").
A comprhensive device health and activity The effectivness of this control can be demonstrated by
monitoring program includes automated establishing a test environment from which to work and,
notifications in the event of intended or systematically disabling key portions of the environment to
unintended outage. Escalation procedures should demonstrate the corresponding alert. Alerts that are
be developed and enabled to cascade intentionally not acknowledged should casdace to the next
notifications that are not addressed or responded level of management per the defined escalation
to within a period of time determined to match the procedures.
criticality of the infrastructure item. (i.e. "Firewall
Outage Notifications will be responded to within
15 minutes. Notifications within 15 minutes that
are not acknowledged will be escalated to a
supervisor or manager...").
A comprehensive security program should include The effectivness of this contrl can be demonstrated by
provision for the development and ongoing review of the information security program specific to data
administration of security policies and retention, account and infrastructure administation and, by
procedures. The program should be considered a review of security awareness training and operational
living process that changes as the business and standards.
threat landscape change. Quarterly reviews of
the program schould be includes as part of
program maintenance activities.
To achieve compliance, the following measures Effectiveness of this control can be demonstrated by a
must be taken: number of means, including:
•Verification of policies and procedures to detect * A comparison of current, filed network topology diagrams
and identify authorized and unauthorized wireless to current (actual) state design.
devices. * Penetration testing or, testing of unamortized (or loosely
•Verification of the methodology used for controlled) wireless network segments.,
detection. This should be adequate enough to * Enabling Test configurations of Wireless Detection
identify basic wireless devices such as WLAN technology by enabling an unplanned wireless access
cards, portable devices, and wireless devices point or segment to the network.
connected to network ports.
•Ensuring that network scans are performed on a
quarterly basis
•Verification of automatic notifications in case
automatic monitoring mechanism such as
wireless IPS/IDS is being used.
•Examine the incident response plan to verify that
a mechanism to properly respond to incident
reporting is implemented.
To achieve compliance, the following measures Effectiveness of this control can be demonstrated by a
must be taken: number of means, including:
•Verification of policies and procedures to detect * A comparison of current, filed network topology diagrams
and identify authorized and unauthorized wireless to current (actual) state design.
devices. * Penetration testing or, testing of unamortized (or loosely
•Verification of the methodology used for controlled) wireless network segments.,
detection. This should be adequate enough to * Enabling Test configurations of Wireless Detection
identify basic wireless devices such as WLAN technology by enabling an unplanned wireless access
cards, portable devices, and wireless devices point or segment to the network.
connected to network ports.
•Ensuring that network scans are performed on a
quarterly basis
•Verification of automatic notifications in case
automatic monitoring mechanism such as
wireless IPS/IDS is being used.
•Examine the incident response plan to verify that
a mechanism to properly respond to incident
reporting is implemented.
Additions or modifications to the incident Effectiveness of this control can be demonstrated by

response plan should follow current, documented testing the aspect of the incident response plan specific to
procedures for modification, review, approval and identification of unauthorized network nodes or wireless
implementation of the change. devices. Specifically, a test of this change should follow a
"Mock Detection" scenario that puts to test the aspect of
the Incident Response plan specific to unauthorized
network use or access.
To achieve compliance, the following steps must Effectiveness of this control can be demonstrated as
be ensured: follows:
•It should be verified that at least four quarterly * At least four quarterly scans were conducted in last 12
scans were conducted in last 12 months. months.
•Scan reports should be reviewed to verify that all • Scan reports should be reviewed to verify that all results
results are rescanned until all high risk are rescanned until all high risk vulnerabilities are
vulnerabilities are removed. removed.
•Verify that the internal scan was conducted by • Verify that the internal scan was conducted by qualified
qualified personnel and that the external scan personnel and that the external scan was conducted by an
was conducted by an Approved Scanning Vendor Approved Scanning Vendor (ASV).
(ASV). • Examine the change control documentation and verify
•Examine the change control documentation and that any change in system components was also made a
verify that any change in system components part of the scanning process.
was also made a part of the scanning process.
A penetration test serves to evaluate a system in terms of
Penetration testing in the context of compliance how far a malicious hacker will be able to penetrate into
should involve the following: the network, by simulating an attack. It is a proactive
approach and serves as a counter mechanism by the
* An inventory of application and systems in- organization to develop protective strategies against a
scope. potential attack. A penetration test is one step ahead of a
* A priority rating assigned to each application or vulnerability scan as a penetration tester attempts to
system based on business-criticality and potential exploit the vulnerabilities detected in a vulnerability scan.
risk.
* Based on priority, a plan to test the application. It is important that in order to comply with this requirement,
* Execution of the Pen Test(s) in-scope. the penetration testing mechanism must be examined and
* Resulitng Pen Test report indicating the penetration testers should be interviewed to verify the
following: above mentioned fulfillments. Results should be verified to
- Systems Tested validate that penetration tests are performed at least once
- Level of Access Achieved a year and also after every change within the network.
- Exploits Used to Achieve Access Network and application penetration tests must be verified
- Vulnerabilities Identified. at all levels of the organization. The results of penetration
- Recommendations for Remediation based on tests must also be examined to verify that the discovered
risk and level of exposure. vulnerabilities were removed and a retest confirmed the
removal of those vulnerabilities.
risk.

risk.
Penetration Testing Output (Remediation) Penetration testing in the context of compliance should
Reports should be implemented by system or involve the following:
application.
* An inventory of application and systems in-scope.
A viable remediation plan should include: * A priority rating assigned to each application or system
- An indication and description of the vulnerability based on business-criticality and potential risk.
discovered. * Based on priority, a plan to test the application.
- Risks associated with the vulnerability. * Execution of the Pen Test(s) in-scope.
- A priority ranking of the vulnerabilities * Resulitng Pen Test report indicating the following:
discovered. - Systems Tested
- Task assignments from remediation (Assigned - Level of Access Achieved
to, date expected, etc.). - Exploits Used to Achieve Access
- Vulnerabilities Identified.
- Recommendations for Remediation based on risk and
level of exposure.
- Estimated time to remediate.

risk.
risk.
IDS / IPS solutions should be placed The effectiness of IDS / IPS implementation can be
implemented based on throrough design reviews demonstrated as part of a comprehensive Penetration
of the network and, proximal to known points of Testing program such that; effective IDS / IPS capabilities
ingress / egress. should significantly limit or, at a minimum, alert to the
existence of penetration attempts.
Where possible, IDS / IPS technology should be
centrally monitored and administered to reduce During a penetration test, an effective IDS / IPS
the need for individual updates and, to ensure implementation will alert to attempted access methods to
events across devices are available for include, type of attempt, location of attempt, time, date,
comprehensive viewing. etc.
Implementation of File Integrity Monitoring tools The effectivness of this control can be demonstrated by
(Tripwire, Verisys, CimTrack, etc.) to alert to enababling File Integrity Monitoring tools and
changes of mission-critical, or information- corresponding notification protocols. Test changes made
sensitive log files. to sample data should generate corresponding alerts and
notifications based on the action taken.
Alerting should be set to notify of Change and to
alert administrators directly based on unplanned
deletion to removal.
Response plans should include an inventory of The effectivness of this contrl can be demonstrated by
systems covered by CMDS, their priority and rehersal of the Incident Response Plan specific to
criticality in the organization and, the priority-level unplanned or unauthorized change management
of response that is expected based on the detection.
change or alert generated.
A comprehensive security program should include The effectivness of this contrl can be demonstrated by
provision for the development and ongoing review of the information security program specific to data
administration of security policies and retention, account and infrastructure administation and, by
procedures. The program should be considered a review of security awareness training and operational
living process that changes as the business and standards.
threat landscape change. Quarterly reviews of
the program schould be includes as part of
program maintenance activities.
Control Output:
Artifact
See Below
Firewall and Router Configuration.

Screen shot of firewall settings.
Firewall administrator is able to show the
settings in an interview.
Firewall and router configuration.

Screen shots from firewall and router.
Firewall and router configuration standard
with a current inventory.
Interview with the firewall/router
custodian/administrator.

▪ Firewall and router configurations
(screen shot).
▪ Firewall and router configuration
standard (actual document).
▪ Interview with firewall and network
aligned administrators.
▪ Atos Policy and the Technical System

Security guide.
▪ Interview with the asset administrator.
▪ Any portable computing device that
connects to the network (CDE) have the
settings in place.
• Atos security policy
• Firewall and router configuration
standard
• Any applicable Technical System
Security guides
• Interview with aligned firewall
administrators
Documentation proving that firewall

maintenance occurs, dictating how/why
would be required as an artifact. If an IAM
system is in place, it can easily be shown
who in the organization has access to the
firewalls
An Excel spreadsheet or a Word

document or a dashboard (automated)
that reflects the requirement for the
assurance that inbound and outbound
traffic is limited minimum necessary and
each instance is justified.
• An Excel spreadsheet or a Word
that reflects the requirement for
configuration files to be secure and the
most current is synchronized.
configuration file being stored securely.
configuration file synchronized and
running.

that reflects each and every rule, port and
protocol, their definition, inception date
and approval.

and approval.
and approval.

and approval.



▪ Firewall and router configurations

(screen shot).
▪ Firewall and router configuration
standard (actual document).
▪ Interview with firewall and network
aligned administrators.
▪ Atos Policy and the Technical System
Security guide.
▪ Interview with the asset administrator.
▪ Any portable computing device that
connects to the network (CDE) have the
settings in place.
• Atos security policy

• Firewall and router configuration
standard
• Any applicable Technical System
Security guides
• Interview with aligned firewall
administrators
Documentation proving that firewall
maintenance occurs, dictating how/why
would be required as an artifact. If an IAM
system is in place, it can easily be shown
who in the organization has access to the
firewalls
A running config pulled from the WAP

should suffice as an artifact during an
audit
A CIS report template can serve as an
artifact for compliance, as well as a recent
vulnerability scan report showing that the
system is hardened per the specification
of the benchmark
Running a report from any of these CM
tools will produce an artifact that should
satisfy this requirement


satisfy this requirement. An interview with
key personnel to determine why certain
ports may be open will also satisfy this
requirement.
satisfy this requirement. A review of the
organization's SOP or asset baseline
manual should also exude compliance
A sample scan of select system

components after the interview with sys
admins will produce enough evidence to
A sample scan targeting select system

components after the interview with sys
admins will produce enough evidence to
An interview with the sys admin, as well
as watching how he/she authenticates
remotely to any system will help to ensure
compliance. The review of a custom scan
using a CM tool targeting running services
able to be accessed remotely will also
suffice as an artifact
Watching an admin or engineer login to

this application and viewing all available
elements should suffice as an artifact
An interview with the appropriate admin or

engineer, as well as documentation
defining this relationship should suffice as
an artifact for this requirement
The SLA defined between the hosting

provider and the organization will be very
granular and provide this level of detail
which will suffice as an artifact
Policy Review
Sdelete/SRM Install and configuration
To verify that no data from magnetic

stripe, verification code and Personal
Identification Number is stored even after
authorization, examine all data sources
such as incoming and outgoing
transaction details, logs, history files, trace
files, database contents, etc.
A review of all applicable logs (transaction,
history, DB contents, etc.) can and should
be reviewed periodically to ensure that full
track data is not stored
For a sample of system components,

examine data sources and 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
For a sample of system components,

examine data sources, and verify that
PINs and encrypted PIN blocks are not
stored after authorization
System configurations and screens,
receipts, etc., must be examined to
achieve compliance.
Ensure that the PDIEncrypt flag is set to

On (it is typically on by default) in the
configuration file
The organization can rely upon the
vendor's white paper/documentation on
their solution highlighting the fact that it is
in compliance with this requirement
Key Vault Review

Admin Interview
Policy Audit
Key Vault Review

Admin Interview
Policy Audit
Key Vault Review
Admin Interview
Policy Audit
Key Vault Review

Admin Interview
Policy Audit
Key Vault Review

Admin Interview
Policy Audit
Policy Audit
Internal Pen Test Results

Key Vault Review
Policy Audit
Admin Interview
Key Vault Review
Policy Audit
Admin Interview
Key Vault Review
Policy Audit
Admin Interview
Key Vault Review
Policy Audit
Admin Interview
Key Vault Review
Policy Audit
Admin Interview
Key Vault Review
Policy Audit
Admin Interview
Key Vault Review
Policy Audit
Admin Interview
Key Vault Review
Policy Audit
Personnel Interviews
Key Vault Review
Policy Audit
To carry out a compliance check, all
locations of cardholder data transmittal
over public networks should be identified.
The actual applied system configuration
setting should then be checked against
the documented procedures to ensure
that they are actually being put into
practice. The processes should be verified
for recognition of trusted certificates
and/or keys, use of secure version of
protocol and a strong encryption
methodology. Verification should be done
by selecting a sample of data transmission
and identifying whether strong
cryptography is applied on the data during
transit or not, protocol with secured
version is being used and only trusted
keys are accepted. For strong
cryptography, verify that the wireless
networks transmitting the cardholder data
use industry best practices for encryption,
such as IEEE 802.11
Admin Interview
WAP Configuration Review
Policy Audit
Compliance to this requirement entails
that a sample of outbound messages
should be taken and examined. This
would help to verify that Personal Account
Numbers are encrypted via strong
cryptography if end-user messaging
technology is being used to send
cardholder data. Moreover, there should
be a written policy for this and it must be
reviewed to check that it clearly forbids the
transmittal of unprotected or unencrypted
PAN’s across end-user messaging
platforms
To verify that this requirement is being

met, the documentation needs to be
examined and personnel should be
interviewed to ensure their understanding
Compliance to this requirement should be

achieved by taking a sample of system
components and verifying that an updated
version of antivirus is deployed and fully
functional. The Network Access Control
(NAC) mechanism can also help to verify
that all individual systems have latest
patches applied to them
To achieve compliance, the following
measures need to be taken:
▪ Check up the policies and procedures of

the organization to make sure that they
mention the need of updated antivirus
software and confirm that it is applied
according to the policies and procedures.
▪ Inspect the anti-virus configuration to
verify that anti-virus scans are set to start
H70automatically after certain time
periods and are on auto-update mode.
▪ Verify by checking the anti-virus
configuration, that H69log generation of
anti-virus is enabled and are in
compliance with requirement 10.7
A report ran from this tool will suffice as an

artifact that is operational
To achieve compliance, the following

measures need to be taken:
▪ Check up the policies and procedures of

the organization to make sure that they
mention the need of updated antivirus
software and confirm that it is applied
according to the policies and procedures.
▪ Inspect the anti-virus configuration to
verify that anti-virus scans are set to start
automatically after certain time periods
and are on auto-update mode.
▪ Verify by checking the anti-virus
configuration, that log generation of anti-
virus is enabled and are in compliance
with requirement 10.7
To ensure that all systems are complying
with this requirement, examine a sample
of systems and verify that all of them have
their anti-virus programs running in real
time. Also verify that none of the anti-virus
programs of the taken sample can be
disabled or altered by common users and
that only personnel authorized by the
management can make these changes in
special case scenarios
To verify that this requirement is being

met, the documentation needs to be
examined and personnel should be
interviewed to ensure their understanding.
Maintain a patching audit log as evidence

of compliance.
Change requests/approvals and logs of
the patches being applied within the
specified timeframes for the associated
patch release dates
Meeting notes for peer review

Results of automated testing
Feedback and markups for manual code
reviews.
Change Requests and the resulting
changes management records.
Audit records
Training records
Improved metrics reports with acceptable
occurrences of error per SLOC
Meeting notes for peer review
Results of automated testing
Feedback and markups for manual code
reviews.
Change Requests and the resulting
changes management records.
Periodic Reviews are conducted and

documented in the Policy or Procedure
change history. Resulting changes or
updates would be recorded as a separate
line item
Network Architecture Diagrams illustrating
the separation of dev/test and prod
environments.
Roles definitions with clear rights and

restrictions cross references with resource
assignments to roles.
Periodic audits and training are scheduled

and the results, in the form of audits
reports and action items as well as
training records are available for review
and follow up as indicated
A random sample of test data from the

development and test environments
should indicate that no live data is used
for testing.
Periodic audits and training are scheduled

and the results, in the form of audits
reports and action items as well as
training records are available for review
and follow up as indicated
A random sample of test data from

recently installed or updated systems
should indicate that no test data or
account information was transitioned into
the live environment.
Reviews of the process and audits of the
CRB meeting minutes and artifacts will be
maintained for reference and review




Training records, applicable certifications,
training schedules, onboarding checklists.
Audit results, actions items and follow up
activities are documented and stored for
later reference and review.
As part of annual training requirements,

development staff will review and sign an
acknowledgment of their understanding of
the development policies and procedures.
Changes that are made to the policies and

procedures are always clearly
communicated to all staff
A mapping from this system highlighting

each job role and the permissions
contained within each would suffice as an
artifact for compliance purposes
A list from the IAM stating the exact
number of permissions and capabilities for
each created role would suffice as an
A mapping from this system highlighting

each job role and the permissions
contained within each would suffice as an
A screenshot depicting these settings as

enabled and configured should suffice as
an artifact for compliance purposes
As an artifact to exude compliance for this

control, a screenshot of the failed login
attempt or a screenshot of a configuration
setting depicting an implicit deny all
setting should suffice.


The SOP can be either electronic or

physical. Fir compliance purposes, the
section speaking to role-based access,
least privileges, and need to know can
simply be provided to the auditor for
review
To ensure compliance, this documentation

should be regularly reviewed and staff
should be ensured to verify their security
awareness
System User Reports listing the

appropriate data to show any instances of
User IDs that are generic in nature or are
accessed by more than 1 user
simultaneously.
System User Reports listing the

appropriate data to show any instances of
User IDs that are generic in nature or are
accessed by more than 1 user
simultaneously.
Audit results, actions items and follow up
activities are documented and stored for
later reference and review.
SAR Termination Requests

User Access Termination Reports (Period
to be determined by the client.
Weekly/Monthly/Quarterly)
Periodic user activity review reports are

stored for reference and review
Vendor Access Logs

Vendor access requests (processed)
Vendor Action Reports (change reports)
Vendor User Lists and Status reports
User lockout reports
Password reset request reports
User lockout reports

Password reset request reports
Screenshot of the implemented policy in

the application settings.
A logged in device will time out after the

appropriate time period with no activity
User profile report that indicates that the
password complies with the policy
Smart Card / Token issuance logs

indicating issue date / return date / user /
manager / etc.
Biometric setup and last update

information
Screen shots of configuration settings.

Sample files to show encryption and
masking as required
User profile report that indicates that user

profiles comply with the requirements for
security questions
profiles comply with the requirements for
password guidelines

passwords comply with the requirements
for updating passwords on a periodic
basis not to exceed 90 days.

passwords comply with the requirements
for uniqueness ad re-use
User profile report that indicates that
password setup and password resets are
either changed by the user or are disabled
by the system.
See Below
User profile report that indicates that
personnel with Admin rights in the CDE
require 2 factor authentication.
User profile report for remote users that

indicates that all personnel with access
rights in the CDE require 2 factor
authentication.
Training Documents
Training system reports
Document repository or library locations.
Atos policy documentation and personnel

interview results.
Atos policy documentation and personnel

interview results.
Control Logs for the issuance of
authentication mechanisms.
Usage logs used to review login patterns

for indications of unauthorized shared
usage
Interview results indicate proper issuance,

control and usage.
User ID reports to indicate those with DBA

roles, responsibilities, and access rights.
Database activity reports reflecting actions

taken only by authorized DBAs
Published policy and procedure
documentation
Training records
Audit and review records.
User access logs

System performance logs
Video and access logs including date time

stamps are retrievable for the specified
timeframe.
Network jack connection assignements or
reports for active / inactive jacks
Wireless asset configuration reports and

change logs.
Network Architecture diagrams that

include information related to the physical
security of wireless devices
Security logs for badge issuance / return

and activation / deactivation.
Security Logs for badges may align with

System Access Requests. Cross
reference reports could be used to verify
authorization to access a system.
Security logs for badge issuance / return
and activation / deactivation.
Security Logs for badges may align with

System Access Requests. Cross
reference reports could be used to verify
authorization to access a system.
System Access Requests (Authorized)

Visitor Badge Logs

Visitor Badge Logs

Visitor Badge Logs

Visitor Badge Logs
Visitor Badge Logs
Internal Audit and spot inspection reports

for unsecured media.
Documentation of annual review and any

deficiencies or recommendations.
See Below
Policy and process documentation related

to the classification of media that contains
sensitive data
Contract, SOW or SLA documentation

with a secure media transportation vendor.
Transport Logs
Transport Logs will include proper
management approvals.
Current and up to date media logs.
Records of the periodic reviews
Records of the periodic reviews
training records
Audit Logs / Audit Reports
Action items and follow up records
resulting from Audit Logs and Reports
Destruction logs
Destroyed media transport logs from a 3rd
part vendor.
See Below
Asset Management Query or Reports

Device inspection logs
Device tamper reports
New hire training records

Refresher training records
Published policy and procedure
documentation
Training records
Audit and review records.
An output of user database with specific

focus on accounts that cannot be
correlated to an individual.
An audit report of user activity (access,

changes, failed log in attempts, duration of
activity, etc.) correlated to existing user
accounts will depict the activity of users
and define how specific accounts are
being used. Use of generic accounts
should be minimal if not eliminated
completely.
Artifact(s) include:
* System Context Diagrams depicting end-
to-end system transactions and the points
at which audit data is generated and
captured.
* Audit reports generated by the system
contracted against a manual review of the
same transaction and a review of the data
captured.
captured.
captured.
captured.
captured.
captured.
captured.
captured.
captured.
Outputs of test-account modification
aligned with the corresponding audit
records demonstrating the following: Time
and date of change, The change as
executed, The account effecting the
change.
Outputs of altert notifications aligned with

key system activity data of the change
(date / time / type of change / user
account responsible for the change).
Outputs of altert notifications aligned with

key system activity data of the change
(date / time / type of change / user
account responsible for the change).
captured.
captured.
captured.
captured.
captured.
captured.
captured.
captured.
captured.
captured.
captured.
captured.
captured.
captured.
System context diagrams depicting time

synchronization and parent / child
relationships for time synch.


An account directory depicting the access
controls enabled for each account or role
type.

type.

type.

type.
type.
FIM output reports from test activities.
System context or architectural diagrams

indicating the existence of FIM technology
- paired with the corresponding notification
plan.
Task-driven review of logs should include

a rotating schedule (as to distributed the
work across disparate parties). This
schedule (and the corresponding sign-off
of each review) can be used to
demonstrate control compliance.


Log retention policy, storage and archival
schedule.
Output reports from the notification tool

set or dashboard including a printed copy
of the escalation procedures defined as
part of the notification policy.
Output reports from the notification tool
set or dashboard including a printed copy
of the escalation procedures defined as
part of the notification policy.
Security awareness training plans and

administrative policy documentation.
* Control artifacts include:
* Network mapping and inventory

documentation depicting the presence of
IDS / IPS or wireless detection technology.
* Written policy depicting controls specific

to unathorized use of wireless devices,
wireless networks and/or the introduction
or expansion of unathorized network
segements.
* Outputs of IDS / IPS scanning reports.
* Reports depicting alerts generated from

the introuduction of unauthorized wireless
or network technology.
* Control artifacts include:
* Network mapping and inventory

documentation depicting the presence of
IDS / IPS or wireless detection technology.
* Written policy depicting controls specific

to unauthorized use of wireless devices,
wireless networks and/or the introduction
or expansion of unauthorized network
segments.
* Outputs of IDS / IPS scanning reports.
* Reports depicting alerts generated from

the introduction of unauthorized wireless
or network technology.
Written copies of the incident response

plan and, results from the most recent
Incident Response plan review or mock
exercise.
* Output reports of VM scan schedules
including inclusion and exclusion ranges.
* Copies of the latest vulnerability scan

results and corresponding remediation
plans.


plans.

plans.


plans.
* Penetration testing plans and output
reports.
* Remediation plans from application or
system owners should also be included.
reports.

reports.
reports.

reports.
reports.

reports.
* Alerts or output reports from IDS / IPS
consoles.
* Network designs indicating the existence
of IDS / IPS technologies.
FIM output reports from test activities.
System context or architectural diagrams

indicating the existence of FIM technology
- paired with the corresponding notification
plan.
* Incident Response Plan - specifically

those chanpters on FIM or Change
Management Detection.
* Output alert reports from FIM or CMD
systems.
* Architectural documentation indicating
the existence of FIM or CMDS.
Security awareness training plans and

administrative policy documentation.
# Title
AC-1 Access Control Policy and Procedures
AC-2 Account Management

AC-3 Access Enforcement
AC-4 Information Flow Enforcement
AC-5 Separation of Duties

AC-6 Least Privilege
AC-7 Unsuccessful Login Attempts
AC-8 System Use Notification
AC-9 Previous Logon (Access) Notification

AC-10 Concurrent Session Control
AC-11 Session Lock
AC-12 Session Termination

AC-13 Supervision and Review Access Control
AC-14 Permitted Actions Without

Identification Or Authentication
AC-15 Automated Marking

AC-16 Security Attributes
AC-17 Remote Access
AC-18 Wireless Access
AC-19 Access Control for Mobile Devices

AC-20 Use of External Information Systems
AC-21 User-based Collaboration and

Information Sharing
AC-22 Publicly Accessible Content

AT-1 Security Awareness and Training Policy
and Procedures
AT-2 Security Awareness
AT-3 Security Training
AT-4 Security Training Records

AT-5 Contacts With Security Groups and
Associations
AU-1 Audit and Accountability Policy and

Procedures
AU-2 Auditable Events
AU-3 Content of Audit Records
AU-4 Audit Storage Capacity

AU-5 Response To Audit Processing Failures
AU-6 Audit Review, Analysis, and Reporting
AU-7 Audit Reduction and Report Generation
AU-8 Time Stamps
AU-9 Protection of Audit Information
AU-10 Non-repudiation
AU-11 Audit Record Retention

AU-12 Audit Generation
AU-13 Monitoring for Information Disclosure
AU-14 Session Audit
CA-1 Security Assessment and Authorization

Policies and Procedures
CA-2 Security Assessments
CA-3 Information System Connections
CA-4 Security Certification
CA-5 Plan of Action and Milestones

CA-6 Security Authorization
CA-7 Continuous Monitoring

CM-1 Configuration Management Policy and
Procedures
CM-2 Baseline Configuration
CM-3 Configuration Change Control

CM-4 Security Impact Analysis
CM-5 Access Restrictions for Change

CM-6 Configuration Settings
CM-7 Least Functionality

CM-8 Information System Component
Inventory
CM-9 Configuration Management Plan
CP-1 Contingency Planning Policy and

Procedures
CP-2 Contingency Plan
CP-3 Contingency Training
CP-4 Contingency Plan Testing and Exercises
CP-5 Contingency Plan Update

CP-6 Alternate Storage Site
CP-7 Alternate Processing Site

CP-8 Telecommunications Services
CP-9 Information System Backup
CP-10 Information System Recovery and

Reconstitution
IA-1 Identification and Authentication Policy

and Procedures
IA-2 Identification and Authentication
(Organizational Users)
IA-3 Device Identification and

Authentication
IA-4 Identifier Management

IA-5 Authenticator Management
IA-6 Authenticator Feedback
IA-7 Cryptographic Module Authentication
IA-8 Identification and Authentication (Non-

organizational Users)
IR-1 Incident Response Policy and
Procedures
IR-2 Incident Response Training
IR-3 Incident Response Testing and Exercises
IR-4 Incident Handling
IR-5 Incident Monitoring
IR-6 Incident Reporting
IR-7 Incident Response Assistance

IR-8 Incident Response Plan
MA-1 System Maintenance Policy and

Procedures
MA-2 Controlled Maintenance
MA-3 Maintenance Tools
MA-4 Non-local Maintenance
MA-5 Maintenance Personnel

MA-6 Timely Maintenance
MP-1 Media Protection Policy and Procedures
MP-2 Media Access

MP-3 Media Marking
MP-4 Media Storage

MP-5 Media Transport
MP-6 Media Sanitization

PE-1 Physical and Environmental Protection
Policy and Procedures
PE-2 Physical Access Authorizations
PE-3 Physical Access Control
PE-4 Access Control for Transmission

Medium
PE-5 Access Control for Output Devices
PE-6 Monitoring Physical Access

PE-7 Visitor Control
PE-8 Access Records
PE-9 Power Equipment and Power Cabling
PE-10 Emergency Shutof
PE-11 Emergency Power
PE-12 Emergency Lighting
PE-13 Fire Protection
PE-14 Temperature and Humidity Controls
PE-15 Water Damage Protection
PE-16 Delivery and Removal

PE-17 Alternate Work Site
PE-18 Location of Information System

Components
PE-19 Information Leakage
PL-1 Security Planning Policy and Procedures

PL-2 System Security Plan
PL-3 System Security Plan Update

PL-4 Rules of Behavior
PL-5 Privacy Impact Assessment
PL-6 Security-related Activity Planning

PM-1 Information Security Program Plan
PM-2 Senior Information Security Officer
PM-3 Information Security Resources
PM-4 Plan of Action and Milestones Process
PM-5 Information System Inventory
PM-6 Information Security Measures of

Performance
PM-7 Enterprise Architecture
PM-8 Critical Infrastructure Plan
PM-9 Risk Management Strategy
PM-10 Security Authorization Process

PM-11 Mission/business Process Definition
PS-1 Personnel Security Policy and

Procedures
PS-2 Position Categorization
PS-3 Personnel Screening
PS-4 Personnel Termination

PS-5 Personnel Transfer
PS-6 Access Agreements
PS-7 Third-party Personnel Security
PS-8 Personnel Sanctions
RA-1 Risk Assessment Policy and Procedures

RA-2 Security Categorization
RA-3 Risk Assessment
RA-4 Risk Assessment Update

RA-5 Vulnerability Scanning
SA-1 System and Services Acquisition Policy

and Procedures
SA-2 Allocation of Resources
SA-3 Life Cycle Support

SA-4 Acquisitions
SA-5 Information System Documentation
SA-6 Software Usage Restrictions
SA-7 User-installed Software

SA-8 Security Engineering Principles
SA-9 External Information System Services
SA-10 Developer Configuration Management

SA-11 Developer Security Testing
SA-12 Supply Chain Protection
SA-13 Trustworthiness
SA-14 Critical Information System

Components
SC-1 System and Communications Protection
Policy and Procedures
SC-2 Application Partitioning
SC-3 Security Function Isolation
SC-4 Information In Shared Resources
SC-5 Denial of Service Protection

SC-6 Resource Priority
SC-7 Boundary Protection
SC-8 Transmission Integrity
SC-9 Transmission Confidentiality
SC-10 Network Disconnect

SC-11 Trusted Path
SC-12 Cryptographic Key Establishment and

Management
SC-13 Use of Cryptography
SC-14 Public Access Protections
SC-15 Collaborative Computing Devices
SC-16 Transmission of Security Attributes
SC-17 Public Key Infrastructure Certificates
SC-18 Mobile Code
SC-19 Voice Over Internet Protocol

SC-20 Secure Name / Address Resolution
Service (Authoritative Source)
SC-21 Secure Name / Address Resolution

Service (Recursive Or Caching Resolver)
SC-22 Architecture and Provisioning for

Name / Address Resolution Service
SC-23 Session Authenticity
SC-24 Fail In Known State

SC-25 Thin Nodes
SC-26 Honeypots
SC-27 Operating System-independent

Applications
SC-28 Protection of Information At Rest
SC-29 Heterogeneity
SC-30 Virtualization Techniques
SC-31 Covert Channel Analysis
SC-32 Information System Partitioning

SC-33 Transmission Preparation Integrity
SC-34 Non-modifiable Executable Programs
SI-1 System and Information Integrity Policy

and Procedures
SI-2 Flaw Remediation

SI-3 Malicious Code Protection
SI-4 Information System Monitoring

SI-5 Security Alerts, Advisories, and
Directives
SI-6 Security Functionality Verification
SI-7 Software and Information Integrity
SI-8 Spam Protection
SI-9 Information Input Restrictions
SI-10 Information Input Validation
SI-11 Error Handling

SI-12 Information Output Handling and
Retention
SI-13 Predictable Failure Prevention

Control Description
The organization develops, disseminates, and reviews/updates [ Assignment:

organization-defined frequency ]: A formal, documented access control policy that
addresses purpose, scope, roles, responsibilities, management commitment,
coordination among organizational entities, and compliance; and Formal, documented
procedures to facilitate the implementation of the access control policy and associated
access controls.
The organization manages information system accounts, including: Identifying account

types (i.e., individual, group, system, application, guest/anonymous, and temporary);
Establishing conditions for group membership; Identifying authorized users of the
information system and specifying access privileges; Requiring appropriate approvals for
requests to establish accounts; Establishing, activating, modifying, disabling, and
removing accounts; Specifically authorizing and monitoring the use of guest/anonymous
and temporary accounts; Notifying account managers when temporary accounts are no
longer required and when information system users are terminated, transferred, or
information system usage or need-to-know/need-to-share changes; Deactivating: (i)
temporary accounts that are no longer required; and (ii) accounts of terminated or
transferred users; Granting access to the system based on: (i) a valid access
authorization; (ii) intended system usage; and (iii) other attributes as required by the
organization or associated missions/business functions; and Reviewing accounts
[ Assignment: organization-defined frequency ].
The information system enforces approved authorizations for logical access to the
system in accordance with applicable policy.
The information system enforces approved authorizations for controlling the flow of
information within the system and between interconnected systems in accordance with
applicable policy.
The organization: Separates duties of individuals as necessary, to prevent malevolent

activity without collusion; Documents separation of duties; and Implements separation
of duties through assigned information system access authorizations.
The organization employs the concept of least privilege, allowing only authorized
accesses for users (and processes acting on behalf of users) which are necessary to
accomplish assigned tasks in accordance with organizational missions and business
functions.
The information system: Enforces a limit of [ Assignment: organization-defined number ]

consecutive invalid login attempts by a user during a [ Assignment: organization-defined
time period ]; and Automatically [ Selection: locks the account/node for an
[ Assignment: organization-defined time period ] ; locks the account/node until released
by an administrator; delays next login prompt according to [ Assignment: organization-
defined delay algorithm ]] when the maximum number of unsuccessful attempts is
exceeded. The control applies regardless of whether the login occurs via a local or
network connection.
The information system: Displays an approved system use notification message or

banner before granting access to the system that provides privacy and security notices
consistent with applicable federal laws, Executive Orders, directives, policies,
regulations, standards, and guidance and states that: (i) users are accessing a U.S.
Government information system; (ii) system usage may be monitored, recorded, and
subject to audit; (iii) unauthorized use of the system is prohibited and subject to
criminal and civil penalties; and (iv) use of the system indicates consent to monitoring
and recording; Retains the notification message or banner on the screen until users take
explicit actions to log on to or further access the information system; and For publicly
accessible systems: (i) displays the system use information when appropriate, before
granting further access; (ii) displays references, if any, to monitoring, recording, or
auditing that are consistent with privacy accommodations for such systems that
generally prohibit those activities; and (iii) includes in the notice given to public users of
the information system, a description of the authorized uses of the system.
The information system notifies the user, upon successful logon (access), of the date
and time of the last logon (access).
The information system limits the number of concurrent sessions for each system
account to [ Assignment: organization-defined number ].
The information system: Prevents further access to the system by initiating a session
lock after [ Assignment: organization-defined time period ] of inactivity or upon
receiving a request from a user; and Retains the session lock until the user reestablishes
access using established identification and authentication procedures.
[ Withdrawn: Incorporated into SC-10 ].

[ Withdrawn: Incorporated into AC-2 and AU-6 ].
The organization: Identifies specific user actions that can be performed on the
information system without identification or authentication; and Documents and
provides supporting rationale in the security plan for the information system, user
actions not requiring identification and authentication.
[ Withdrawn: Incorporated into MP-3 ].

The information system supports and maintains the binding of [ Assignment:
organization-defined security attributes ] to information in storage, in process, and in
transmission.
The organization: Documents allowed methods of remote access to the information
system; Establishes usage restrictions and implementation guidance for each allowed
remote access method; Monitors for unauthorized remote access to the information
system; Authorizes remote access to the information system prior to connection; and
Enforces requirements for remote connections to the information system.
The organization: Establishes usage restrictions and implementation guidance for

wireless access; Monitors for unauthorized wireless access to the information system;
Authorizes wireless access to the information system prior to connection; and Enforces
requirements for wireless connections to the information system.
The organization: Establishes usage restrictions and implementation guidance for

organization-controlled mobile devices; Authorizes connection of mobile devices
meeting organizational usage restrictions and implementation guidance to
organizational information systems; Monitors for unauthorized connections of mobile
devices to organizational information systems; Enforces requirements for the
connection of mobile devices to organizational information systems; Disables
information system functionality that provides the capability for automatic execution of
code on mobile devices without user direction; Issues specially configured mobile
devices to individuals traveling to locations that the organization deems to be of
significant risk in accordance with organizational policies and procedures; and Applies
[ Assignment: organization-defined inspection and preventative measures ] to mobile
devices returning from locations that the organization deems to be of significant risk in
accordance with organizational policies and procedures.
The organization establishes terms and conditions, consistent with any trust
relationships established with other organizations owning, operating, and/or
maintaining external information systems, allowing authorized individuals to: Access the
information system from the external information systems; and Process, store, and/or
transmit organization-controlled information using the external information systems.
The organization: Facilitates information sharing by enabling authorized users to

determine whether access authorizations assigned to the sharing partner match the
access restrictions on the information for [ Assignment: organization-defined
information sharing circumstances where user discretion is required ]; and Employs
[ Assignment: list of organization-defined information sharing circumstances and
automated mechanisms or manual processes required ] to assist users in making
information sharing/collaboration decisions.
The organization: Designates individuals authorized to post information onto an

organizational information system that is publicly accessible; Trains authorized
individuals to ensure that publicly accessible information does not contain nonpublic
information; Reviews the proposed content of publicly accessible information for
nonpublic information prior to posting onto the organizational information system;
Reviews the content on the publicly accessible organizational information system for
nonpublic information [ Assignment: organization-defined frequency ]; and Removes
nonpublic information from the publicly accessible organizational information system, if
discovered.
organization-defined frequency ]: A formal, documented security awareness and
training policy that addresses purpose, scope, roles, responsibilities, management
commitment, coordination among organizational entities, and compliance; and Formal,
documented procedures to facilitate the implementation of the security awareness and
training policy and associated security awareness and training controls.
The organization provides basic security awareness training to all information system
users (including managers, senior executives, and contractors) as part of initial training
for new users, when required by system changes, and [ Assignment: organization-
defined frequency ] thereafter.
The organization provides role-based security-related training: (i) before authorizing

access to the system or performing assigned duties; (ii) when required by system
changes; and (iii) [ Assignment: organization-defined frequency ] thereafter.
The organization: Documents and monitors individual information system security

training activities including basic security awareness training and specific information
system security training; and Retains individual training records for [ Assignment:
organization-defined time period ].
The organization establishes and institutionalizes contact with selected groups and
associations within the security community: - To facilitate ongoing security education
and training for organizational personnel; - To stay up to date with the latest
recommended security practices, techniques, and technologies; and - To share current
security-related information including threats, vulnerabilities, and incidents.

organization-defined frequency ]: A formal, documented audit and accountability policy
that addresses purpose, scope, roles, responsibilities, management commitment,
procedures to facilitate the implementation of the audit and accountability policy and
associated audit and accountability controls.
The organization: Determines, based on a risk assessment and mission/business needs,

that the information system must be capable of auditing the following events:
[ Assignment: organization-defined list of auditable events ]; Coordinates the security
audit function with other organizational entities requiring audit-related information to
enhance mutual support and to help guide the selection of auditable events; Provides a
rationale for why the list of auditable events are deemed to be adequate to support
after-the-fact investigations of security incidents; and Determines, based on current
threat information and ongoing assessment of risk, that the following events are to be
audited within the information system: [ Assignment: organization-defined subset of the
auditable events defined in AU-2 a. to be audited along with the frequency of (or
situation requiring) auditing for each identified event ].
The information system produces audit records that contain sufficient information to, at
a minimum, establish what type of event occurred, when (date and time) the event
occurred, where the event occurred, the source of the event, the outcome (success or
failure) of the event, and the identity of any user/subject associated with the event.
The organization allocates audit record storage capacity and configures auditing to
reduce the likelihood of such capacity being exceeded.
The information system: Alerts designated organizational officials in the event of an
audit processing failure; and Takes the following additional actions: [ Assignment:
organization-defined actions to be taken (e.g., shut down information system, overwrite
oldest audit records, stop generating audit records) ].
The organization: Reviews and analyzes information system audit records [ Assignment:
organization-defined frequency ] for indications of inappropriate or unusual activity, and
reports findings to designated organizational officials; and Adjusts the level of audit
review, analysis, and reporting within the information system when there is a change in
risk to organizational operations, organizational assets, individuals, other organizations,
or the Nation based on law enforcement information, intelligence information, or other
credible sources of information.
The information system provides an audit reduction and report generation capability.
The information system uses internal system clocks to generate time stamps for audit
records.
The information system protects audit information and audit tools from unauthorized
access, modification, and deletion.
The information system protects against an individual falsely denying having performed
a particular action.
The organization retains audit records for [ Assignment: organization-defined time

period consistent with records retention policy ] to provide support for after-the-fact
investigations of security incidents and to meet regulatory and organizational
information retention requirements.
The information system: Provides audit record generation capability for the list of
auditable events defined in AU-2 at [ Assignment: organization-defined information
system components ]; Allows designated organizational personnel to select which
auditable events are to be audited by specific components of the system; and Generates
audit records for the list of audited events defined in AU-2 with the content as defined
in AU-3.
The organization monitors open source information for evidence of unauthorized

exfiltration or disclosure of organizational information [ Assignment: organization-
defined frequency ].
The information system provides the capability to: Capture/record and log all content
related to a user session; and Remotely view/hear all content related to an established
user session in real time.

organization-defined frequency ]: Formal, documented security assessment and
authorization policies that address purpose, scope, roles, responsibilities, management
documented procedures to facilitate the implementation of the security assessment
and authorization policies and associated security assessment and authorization
controls.
The organization: Develops a security assessment plan that describes the scope of the
assessment including: Security controls and control enhancements under assessment;
Assessment procedures to be used to determine security control efectiveness; and
Assessment environment, assessment team, and assessment roles and responsibilities;
Assesses the security controls in the information system [ Assignment: organization-
defined frequency ] to determine the extent to which the controls are implemented
correctly, operating as intended, and producing the desired outcome with respect to
meeting the security requirements for the system; Produces a security assessment
report that documents the results of the assessment; and Provides the results of the
security control assessment, in writing, to the authorizing official or authorizing official
designated representative.
The organization: Authorizes connections from the information system to other
information systems outside of the authorization boundary through the use of
Interconnection Security Agreements; Documents, for each connection, the interface
characteristics, security requirements, and the nature of the information
communicated; and Monitors the information system connections on an ongoing basis
verifying enforcement of security requirements.
[ Withdrawn: Incorporated into CA-2 ].
The organization: Develops a plan of action and milestones for the information system
to document the organizations planned remedial actions to correct weaknesses or
deficiencies noted during the assessment of the security controls and to reduce or
eliminate known vulnerabilities in the system; and Updates existing plan of action and
milestones [ Assignment: organization-defined frequency ] based on the findings from
security controls assessments, security impact analyses, and continuous monitoring
activities.
The organization: Assigns a senior-level executive or manager to the role of authorizing
official for the information system; Ensures that the authorizing official authorizes the
information system for processing before commencing operations; and Updates the
security authorization [ Assignment: organization-defined frequency ].
The organization establishes a continuous monitoring strategy and implements a

continuous monitoring program that includes: A configuration management process for
the information system and its constituent components; A determination of the security
impact of changes to the information system and environment of operation; Ongoing
security control assessments in accordance with the organizational continuous
monitoring strategy; and Reporting the security state of the information system to
appropriate organizational officials [ Assignment: organization-defined frequency ].
organization-defined frequency ]: A formal, documented configuration management
policy that addresses purpose, scope, roles, responsibilities, management commitment,
procedures to facilitate the implementation of the configuration management policy
and associated configuration management controls.
The organization develops, documents, and maintains under configuration control, a

current baseline configuration of the information system.
The organization: Determines the types of changes to the information system that are
configuration controlled; Approves configuration-controlled changes to the system with
explicit consideration for security impact analyses; Documents approved configuration-
controlled changes to the system; Retains and reviews records of configuration-
controlled changes to the system; Audits activities associated with configuration-
controlled changes to the system; and Coordinates and provides oversight for
configuration change control activities through [ Assignment: organization-defined
configuration change control element (e.g., committee, board ] that convenes
[ Selection: (one or more): [ Assignment: organization-defined frequency ] ;
[ Assignment: organization-defined configuration change conditions ]].
The organization analyzes changes to the information system to determine potential
security impacts prior to change implementation.
The organization defines, documents, approves, and enforces physical and logical access
restrictions associated with changes to the information system.
The organization: Establishes and documents mandatory configuration settings for
information technology products employed within the information system using
[ Assignment: organization-defined security configuration checklists ] that reflect the
most restrictive mode consistent with operational requirements; Implements the
configuration settings; Identifies, documents, and approves exceptions from the
mandatory configuration settings for individual components within the information
system based on explicit operational requirements; and Monitors and controls changes
to the configuration settings in accordance with organizational policies and procedures.
The organization configures the information system to provide only essential capabilities
and specifically prohibits or restricts the use of the following functions, ports, protocols,
and/or services: [ Assignment: organization-defined list of prohibited or restricted
functions, ports, protocols, and/or services ].
The organization develops, documents, and maintains an inventory of information
system components that: Accurately reflects the current information system; Is
consistent with the authorization boundary of the information system; Is at the level of
granularity deemed necessary for tracking and reporting; Includes [ Assignment:
organization-defined information deemed necessary to achieve efective property
accountability ]; and Is available for review and audit by designated organizational
officials.
The organization develops, documents, and implements a configuration management

plan for the information system that: Addresses roles, responsibilities, and configuration
management processes and procedures; Defines the configuration items for the
information system and when in the system development life cycle the configuration
items are placed under configuration management; and Establishes the means for
identifying configuration items throughout the system development life cycle and a
process for managing the configuration of the configuration items.

organization-defined frequency ]: A formal, documented contingency planning policy
that addresses purpose, scope, roles, responsibilities, management commitment,
procedures to facilitate the implementation of the contingency planning policy and
associated contingency planning controls.
The organization: Develops a contingency plan for the information system that:
Identifies essential missions and business functions and associated contingency
requirements; Provides recovery objectives, restoration priorities, and metrics;
Addresses contingency roles, responsibilities, assigned individuals with contact
information; Addresses maintaining essential missions and business functions despite
an information system disruption, compromise, or failure; Addresses eventual, full
information system restoration without deterioration of the security measures originally
planned and implemented; and Is reviewed and approved by designated officials within
the organization; Distributes copies of the contingency plan to [ Assignment:
organization-defined list of key contingency personnel (identified by name and/or by
role) and organizational elements ]; Coordinates contingency planning activities with
incident handling activities; Reviews the contingency plan for the information system
[ Assignment: organization-defined frequency ]; Revises the contingency plan to address
changes to the organization, information system, or environment of operation and
problems encountered during contingency plan implementation, execution, or testing;
and Communicates contingency plan changes to [ Assignment: organization-defined list
of key contingency personnel (identified by name and/or by role) and organizational
elements ].
The organization trains personnel in their contingency roles and responsibilities with
respect to the information system and provides refresher training [ Assignment:
organization-defined frequency ].
The organization: Tests and/or exercises the contingency plan for the information
system [ Assignment: organization-defined frequency ] using [ Assignment: organization-
defined tests and/or exercises ] to determine the plans efectiveness and the
organizations readiness to execute the plan; and Reviews the contingency plan
test/exercise results and initiates corrective actions.
[ Withdrawn: Incorporated into CP-2 ].

The organization establishes an alternate storage site including necessary agreements to
permit the storage and recovery of information system backup information.
The organization: Establishes an alternate processing site including necessary

agreements to permit the resumption of information system operations for essential
missions and business functions within [ Assignment: organization-defined time period
consistent with recovery time objectives ] when the primary processing capabilities are
unavailable; and Ensures that equipment and supplies required to resume operations
are available at the alternate site or contracts are in place to support delivery to the site
in time to support the organization-defined time period for resumption.
The organization establishes alternate telecommunications services including necessary
agreements to permit the resumption of information system operations for essential
missions and business functions within [ Assignment: organization-defined time period ]
when the primary telecommunications capabilities are unavailable.
The organization: Conducts backups of user-level information contained in the

information system [ Assignment: organization-defined frequency consistent with
recovery time and recovery point objectives ]; Conducts backups of system-level
information contained in the information system [ Assignment: organization-defined
frequency consistent with recovery time and recovery point objectives ]; Conducts
backups of information system documentation including security-related
documentation [ Assignment: organization-defined frequency consistent with recovery
time and recovery point objectives ]; and Protects the confidentiality and integrity of
backup information at the storage location.
The organization provides for the recovery and reconstitution of the information system
to a known state after a disruption, compromise, or failure.

organization-defined frequency ]: A formal, documented identification and
authentication policy that addresses purpose, scope, roles, responsibilities,
management commitment, coordination among organizational entities, and
compliance; and Formal, documented procedures to facilitate the implementation of
the identification and authentication policy and associated identification and
authentication controls.
The information system uniquely identifies and authenticates organizational users (or
processes acting on behalf of organizational users).
The information system uniquely identifies and authenticates [ Assignment:

organization-defined list of specific and/or types of devices ] before establishing a
connection.
The organization manages information system identifiers for users and devices by:
Receiving authorization from a designated organizational official to assign a user or
device identifier; Selecting an identifier that uniquely identifies an individual or device;
Assigning the user identifier to the intended party or the device identifier to the
intended device; Preventing reuse of user or device identifiers for [ Assignment:
organization-defined time period ]; and Disabling the user identifier after [ Assignment:
organization-defined time period of inactivity ].
The organization manages information system authenticators for users and devices by:
Verifying, as part of the initial authenticator distribution, the identity of the individual
and/or device receiving the authenticator; Establishing initial authenticator content for
authenticators defined by the organization; Ensuring that authenticators have sufficient
strength of mechanism for their intended use; Establishing and implementing
administrative procedures for initial authenticator distribution, for lost/compromised or
damaged authenticators, and for revoking authenticators; Changing default content of
authenticators upon information system installation; Establishing minimum and
maximum lifetime restrictions and reuse conditions for authenticators (if appropriate);
Changing/refreshing authenticators [ Assignment: organization-defined time period by
authenticator type ]; Protecting authenticator content from unauthorized disclosure and
modification; and Requiring users to take, and having devices implement, specific
measures to safeguard authenticators.
The information system obscures feedback of authentication information during the

authentication process to protect the information from possible exploitation/use by
unauthorized individuals
The information system uses mechanisms for authentication to a cryptographic module

that meet the requirements of applicable federal laws, Executive Orders, directives,
policies, regulations, standards, and guidance for such authentication.
The information system uniquely identifies and authenticates non-organizational users

(or processes acting on behalf of non-organizational users).
organization-defined frequency ]: A formal, documented incident response policy that
procedures to facilitate the implementation of the incident response policy and
associated incident response controls.
The organization: Trains personnel in their incident response roles and responsibilities
with respect to the information system; and Provides refresher training [ Assignment:
organization-defined frequency ].
The organization tests and/or exercises the incident response capability for the
information system [ Assignment: organization-defined frequency ] using [ Assignment:
organization-defined tests and/or exercises ] to determine the incident response
efectiveness and documents the results.
The organization: Implements an incident handling capability for security incidents that
includes preparation, detection and analysis, containment, eradication, and recovery;
Coordinates incident handling activities with contingency planning activities; and
Incorporates lessons learned from ongoing incident handling activities into incident
response procedures, training, and testing/exercises, and implements the resulting
changes accordingly.
The organization tracks and documents information system security incidents.
The organization: Requires personnel to report suspected security incidents to the

organizational incident response capability within [ Assignment: organization-defined
time-period ]; and Reports security incident information to designated authorities.
The organization provides an incident response support resource, integral to the

organizational incident response capability, that ofers advice and assistance to users of
the information system for the handling and reporting of security incidents.
The organization: Develops an incident response plan that: Provides the organization
with a roadmap for implementing its incident response capability; Describes the
structure and organization of the incident response capability; Provides a high-level
approach for how the incident response capability fits into the overall organization;
Meets the unique requirements of the organization, which relate to mission, size,
structure, and functions; Defines reportable incidents; Provides metrics for measuring
the incident response capability within the organization. Defines the resources and
management support needed to efectively maintain and mature an incident response
capability; and Is reviewed and approved by designated officials within the organization;
Distributes copies of the incident response plan to [ Assignment: organization-defined
list of incident response personnel (identified by name and/or by role) and
organizational elements ]; Reviews the incident response plan [ Assignment:
organization-defined frequency ]; Revises the incident response plan to address
system/organizational changes or problems encountered during plan implementation,
execution, or testing; and Communicates incident response plan changes to
[ Assignment: organization-defined list of incident response personnel (identified by
name and/or by role) and organizational elements ].

organization-defined frequency ]: A formal, documented information system
maintenance policy that addresses purpose, scope, roles, responsibilities, management
documented procedures to facilitate the implementation of the information system
maintenance policy and associated system maintenance controls.
The organization: Schedules, performs, documents, and reviews records of maintenance
and repairs on information system components in accordance with manufacturer or
vendor specifications and/or organizational requirements; Controls all maintenance
activities, whether performed on site or remotely and whether the equipment is
serviced on site or removed to another location; Requires that a designated official
explicitly approve the removal of the information system or system components from
organizational facilities for of-site maintenance or repairs; Sanitizes equipment to
remove all information from associated media prior to removal from organizational
facilities for of-site maintenance or repairs; and Checks all potentially impacted security
controls to verify that the controls are still functioning properly following maintenance
or repair actions.
The organization approves, controls, monitors the use of, and maintains on an ongoing
basis, information system maintenance tools.
The organization: Authorizes, monitors, and controls non-local maintenance and

diagnostic activities; Allows the use of non-local maintenance and diagnostic tools only
as consistent with organizational policy and documented in the security plan for the
information system; Employs strong identification and authentication techniques in the
establishment of non-local maintenance and diagnostic sessions; Maintains records for
non-local maintenance and diagnostic activities; and Terminates all sessions and
network connections when non-local maintenance is completed.
The organization: Establishes a process for maintenance personnel authorization and

maintains a current list of authorized maintenance organizations or personnel; and
Ensures that personnel performing maintenance on the information system have
required access authorizations or designates organizational personnel with required
access authorizations and technical competence deemed necessary to supervise
information system maintenance when maintenance personnel do not possess the
required access authorizations.
The organization obtains maintenance support and/or spare parts for [ Assignment:
organization-defined list of security-critical information system components and/or key
information technology components ] within [ Assignment: organization-defined time
period ] of failure.

organization-defined frequency ]: A formal, documented media protection policy that
procedures to facilitate the implementation of the media protection policy and
associated media protection controls.
The organization restricts access to [ Assignment: organization-defined types of digital

and non-digital media ] to [ Assignment: organization-defined list of authorized
individuals ] using [ Assignment: organization-defined security measures ].
The organization: Marks, in accordance with organizational policies and procedures,
removable information system media and information system output indicating the
distribution limitations, handling caveats, and applicable security markings (if any) of
the information; and Exempts [ Assignment: organization-defined list of removable
media types ] from marking as long as the exempted items remain within [ Assignment:
organization-defined controlled areas ].
The organization: Physically controls and securely stores [ Assignment: organization-

defined types of digital and non-digital media ] within [ Assignment: organization-
defined controlled areas ] using [ Assignment: organization-defined security measures ];
Protects information system media until the media are destroyed or sanitized using
approved equipment, techniques, and procedures
The organization: Protects and controls [ Assignment: organization-defined types of
digital and non-digital media ] during transport outside of controlled areas using
[ Assignment: organization-defined security measures ]; Maintains accountability for
information system media during transport outside of controlled areas; and Restricts
the activities associated with transport of such media to authorized personnel.
The organization: Sanitizes information system media, both digital and non-digital, prior
to disposal, release out of organizational control, or release for reuse; and Employs
sanitization mechanisms with strength and integrity commensurate with the
classification or sensitivity of the information.
organization-defined frequency ]: A formal, documented physical and environmental
protection policy that addresses purpose, scope, roles, responsibilities, management
documented procedures to facilitate the implementation of the physical and
environmental protection policy and associated physical and environmental protection
controls.
The organization: Develops and keeps current a list of personnel with authorized access
to the facility where the information system resides (except for those areas within the
facility officially designated as publicly accessible); Issues authorization credentials;
Reviews and approves the access list and authorization credentials [ Assignment:
organization-defined frequency ], removing from the access list personnel no longer
requiring access.
The organization: Enforces physical access authorizations for all physical access points
(including designated entry/exit points) to the facility where the information system
resides (excluding those areas within the facility officially designated as publicly
accessible); Verifies individual access authorizations before granting access to the
facility; Controls entry to the facility containing the information system using physical
access devices and/or guards; Controls access to areas officially designated as publicly
accessible in accordance with the organizations assessment of risk; Secures keys,
combinations, and other physical access devices; Inventories physical access devices
[ Assignment: organization-defined frequency ]; and Changes combinations and keys
[ Assignment: organization-defined frequency ] and when keys are lost, combinations
are compromised, or individuals are transferred or terminated.
The organization controls physical access to information system distribution and

transmission lines within organizational facilities.
The organization controls physical access to information system output devices to

prevent unauthorized individuals from obtaining the output.
The organization: Monitors physical access to the information system to detect and
respond to physical security incidents; Reviews physical access logs [ Assignment:
organization-defined frequency ]; and Coordinates results of reviews and investigations
with the organizations incident response capability.
The organization controls physical access to the information system by authenticating
visitors before authorizing access to the facility where the information system resides
other than areas designated as publicly accessible.
The organization: Maintains visitor access records to the facility where the information
system resides (except for those areas within the facility officially designated as publicly
accessible); and Reviews visitor access records [ Assignment: organization-defined
frequency ].
The organization protects power equipment and power cabling for the information
system from damage and destruction.
The organization: Provides the capability of shutting of power to the information

system or individual system components in emergency situations; Places emergency
shutof switches or devices in [ Assignment: organization-defined location by
information system or system component ] to facilitate safe and easy access for
personnel; and Protects emergency power shutof capability from unauthorized
activation.
The organization provides a short-term uninterruptible power supply to facilitate an

orderly shutdown of the information system in the event of a primary power source
loss.
The organization employs and maintains automatic emergency lighting for the
information system that activates in the event of a power outage or disruption and that
covers emergency exits and evacuation routes within the facility.
The organization employs and maintains fire suppression and detection devices/systems
for the information system that are supported by an independent energy source.
The organization: Maintains temperature and humidity levels within the facility where
the information system resides at [ Assignment: organization-defined acceptable
levels ]; and Monitors temperature and humidity levels [ Assignment: organization-
defined frequency ].
The organization protects the information system from damage resulting from water
leakage by providing master shutof valves that are accessible, working properly, and
known to key personnel.
The organization authorizes, monitors, and controls [ Assignment: organization-defined

types of information system components ] entering and exiting the facility and
maintains records of those items.
The organization: Employs [ Assignment: organization-defined management,
operational, and technical information system security controls ] at alternate work sites;
Assesses as feasible, the efectiveness of security controls at alternate work sites; and
Provides a means for employees to communicate with information security personnel in
case of security incidents or problems.
The organization positions information system components within the facility to

minimize potential damage from physical and environmental hazards and to minimize
the opportunity for unauthorized access.
The organization protects the information system from information leakage due to
electromagnetic signals emanations.

organization-defined frequency ]: A formal, documented security planning policy that
procedures to facilitate the implementation of the security planning policy and
associated security planning controls.
The organization: Develops a security plan for the information system that: - Is
consistent with the organizations enterprise architecture; - Explicitly defines the
authorization boundary for the system; - Describes the operational context of the
information system in terms of missions and business processes; - Provides the security
categorization of the information system including supporting rationale; - Describes the
operational environment for the information system; - Describes relationships with or
connections to other information systems; - Provides an overview of the security
requirements for the system; - Describes the security controls in place or planned for
meeting those requirements including a rationale for the tailoring and supplementation
decisions; and - Is reviewed and approved by the authorizing official or designated
representative prior to plan implementation; Reviews the security plan for the
information system [ Assignment: organization-defined frequency ]; and Updates the
plan to address changes to the information system/environment of operation or
problems identified during plan implementation or security control assessments.
[ Withdrawn: Incorporated into PL-2 ].

The organization: Establishes and makes readily available to all information system
users, the rules that describe their responsibilities and expected behavior with regard to
information and information system usage; and Receives signed acknowledgment from
users indicating that they have read, understand, and agree to abide by the rules of
behavior, before authorizing access to information and the information system.
The organization conducts a privacy impact assessment on the information system in

accordance with OMB policy.
The organization plans and coordinates security-related activities afecting the
information system before conducting such activities in order to reduce the impact on
organizational operations (i.e., mission, functions, image, and reputation),
organizational assets, and individuals.
The organization: Develops and disseminates an organization-wide information security
program plan that: - Provides an overview of the requirements for the security program
and a description of the security program management controls and common controls
in place or planned for meeting those requirements; - Provides sufficient information
about the program management controls and common controls (including specification
of parameters for any assignment and selection operations either explicitly or by
reference) to enable an implementation that is unambiguously compliant with the
intent of the plan and a determination of the risk to be incurred if the plan is
implemented as intended; - Includes roles, responsibilities, management commitment,
coordination among organizational entities, and compliance; - Is approved by a senior
official with responsibility and accountability for the risk being incurred to
organizational operations (including mission, functions, image, and reputation),
organizational assets, individuals, other organizations, and the Nation; Reviews the
organization-wide information security program plan [ Assignment: organization-defined
frequency ]; and Revises the plan to address organizational changes and problems
identified during plan implementation or security control assessments.
The organization appoints a senior information security officer with the mission and
resources to coordinate, develop, implement, and maintain an organization-wide
information security program.
The organization: Ensures that all capital planning and investment requests include the
resources needed to implement the information security program and documents all
exceptions to this requirement; Employs a business case/Exhibit 300/Exhibit 53 to
record the resources required; and Ensures that information security resources are
available for expenditure as planned.
The organization implements a process for ensuring that plans of action and milestones
for the security program and the associated organizational information systems are
maintained and document the remedial information security actions to mitigate risk to
organizational operations and assets, individuals, other organizations, and the Nation.
The organization develops and maintains an inventory of its information systems.
The organization develops, monitors, and reports on the results of information security
measures of performance.
The organization develops an enterprise architecture with consideration for information
security and the resulting risk to organizational operations, organizational assets,
individuals, other organizations, and the Nation.
The organization addresses information security issues in the development,

documentation, and updating of a critical infrastructure and key resources protection
plan.
The organization: Develops a comprehensive strategy to manage risk to organizational

operations and assets, individuals, other organizations, and the Nation associated with
the operation and use of information systems; and Implements that strategy
consistently across the organization.
The organization: Manages (i.e., documents, tracks, and reports) the security state of
organizational information systems through security authorization processes;
Designates individuals to fulfill specific roles and responsibilities within the
organizational risk management process; and Fully integrates the security authorization
processes into an organization-wide risk management program.
The organization: Defines mission/business processes with consideration for
information security and the resulting risk to organizational operations, organizational
assets, individuals, other organizations, and the Nation; and Determines information
protection needs arising from the defined mission/business processes and revises the
processes as necessary, until an achievable set of protection needs is obtained.

organization-defined frequency ]: A formal, documented personnel security policy that
procedures to facilitate the implementation of the personnel security policy and
associated personnel security controls.
The organization: Assigns a risk designation to all positions; Establishes screening

criteria for individuals filling those positions; and Reviews and revises position risk
designations [ Assignment: organization-defined frequency ].
The organization: Screens individuals prior to authorizing access to the information

system; and Rescreens individuals according to [ Assignment: organization-defined list
of conditions requiring rescreening and, where re-screening is so indicated, the
frequency of such rescreening ].
The organization, upon termination of individual employment: Terminates information

system access; Conducts exit interviews; Retrieves all security-related organizational
information system-related property; and Retains access to organizational information
and information systems formerly controlled by terminated individual.
The organization reviews logical and physical access authorizations to information
systems/facilities when personnel are reassigned or transferred to other positions
within the organization and initiates [ Assignment: organization-defined transfer or
reassignment actions ] within [ Assignment: organization-defined time period following
the formal transfer action ].
The organization: Ensures that individuals requiring access to organizational information

and information systems sign appropriate access agreements prior to being granted
access; and Reviews/updates the access agreements [ Assignment: organization-defined
frequency ].
The organization: Establishes personnel security requirements including security roles

and responsibilities for third-party providers; Documents personnel security
requirements; and Monitors provider compliance.
The organization employs a formal sanctions process for personnel failing to comply
with established information security policies and procedures.

organization-defined frequency ]: A formal, documented risk assessment policy that
procedures to facilitate the implementation of the risk assessment policy and associated
risk assessment controls.
The organization: Categorizes information and the information system in accordance
with applicable federal laws, Executive Orders, directives, policies, regulations,
standards, and guidance; Documents the security categorization results (including
supporting rationale) in the security plan for the information system; and Ensures the
security categorization decision is reviewed and approved by the authorizing official or
authorizing official designated representative.
The organization: Conducts an assessment of risk, including the likelihood and

magnitude of harm, from the unauthorized access, use, disclosure, disruption,
modification, or destruction of the information system and the information it processes,
stores, or transmits; Documents risk assessment results in [ Selection: security plan; risk
assessment report; [ Assignment: organization-defined document ]]; Reviews risk
assessment results [ Assignment: organization-defined frequency ]; and Updates the risk
assessment [ Assignment: organization-defined frequency ] or whenever there are
significant changes to the information system or environment of operation (including
the identification of new threats and vulnerabilities), or other conditions that may
impact the security state of the system.
[ Withdrawn: Incorporated into RA-3 ].

The organization: Scans for vulnerabilities in the information system and hosted
applications [ Assignment: organization-defined frequency and/or randomly in
accordance with organization-defined process ] and when new vulnerabilities
potentially afecting the system/applications are identified and reported; Employs
vulnerability scanning tools and techniques that promote interoperability among tools
and automate parts of the vulnerability management process by using standards for:
Enumerating platforms, software flaws, and improper configurations; Formatting and
making transparent, checklists and test procedures; and Measuring vulnerability
impact; Analyzes vulnerability scan reports and results from security control
assessments; Remediates legitimate vulnerabilities [ Assignment: organization-defined
response times ] in accordance with an organizational assessment of risk; and Shares
information obtained from the vulnerability scanning process and security control
assessments with designated personnel throughout the organization to help eliminate
similar vulnerabilities in other information systems (i.e., systemic weaknesses or
deficiencies).

organization-defined frequency ]: A formal, documented system and services acquisition
policy that includes information security considerations and that addresses purpose,
scope, roles, responsibilities, management commitment, coordination among
organizational entities, and compliance; and Formal, documented procedures to
facilitate the implementation of the system and services acquisition policy and
associated system and services acquisition controls.
The organization: Includes a determination of information security requirements for the

information system in mission/business process planning; Determines, documents, and
allocates the resources required to protect the information system as part of its capital
planning and investment control process; and Establishes a discrete line item for
information security in organizational programming and budgeting documentation.
The organization: Manages the information system using a system development life
cycle methodology that includes information security considerations; Defines and
documents information system security roles and responsibilities throughout the
system development life cycle; and Identifies individuals having information system
security roles and responsibilities.
The organization includes the following requirements and/or specifications, explicitly or
by reference, in information system acquisition contracts based on an assessment of risk
and in accordance with applicable federal laws, Executive Orders, directives, policies,
regulations, and standards: Security functional requirements/specifications; Security-
related documentation requirements; and Developmental and evaluation-related
assurance requirements.
The organization: Obtains, protects as required, and makes available to authorized

personnel, administrator documentation for the information system that describes:
Secure configuration, installation, and operation of the information system; Efective use
and maintenance of security features/functions; and Known vulnerabilities regarding
configuration and use of administrative (i.e., privileged) functions; and Obtains, protects
as required, and makes available to authorized personnel, user documentation for the
information system that describes: User-accessible security features/functions and how
to efectively use those security features/functions; Methods for user interaction with
the information system, which enables individuals to use the system in a more secure
manner; and User responsibilities in maintaining the security of the information and
information system; and Documents attempts to obtain information system
documentation when such documentation is either unavailable or nonexistent.
The organization: Uses software and associated documentation in accordance with

contract agreements and copyright laws; Employs tracking systems for software and
associated documentation protected by quantity licenses to control copying and
distribution; and Controls and documents the use of peer-to-peer file sharing
technology to ensure that this capability is not used for the unauthorized distribution,
display, performance, or reproduction of copyrighted work.
The organization enforces explicit rules governing the installation of software by users.
The organization applies information system security engineering principles in the
specification, design, development, implementation, and modification of the
information system.
The organization: Requires that providers of external information system services

comply with organizational information security requirements and employ appropriate
security controls in accordance with applicable federal laws, Executive Orders,
directives, policies, regulations, standards, and guidance; Defines and documents
government oversight and user roles and responsibilities with regard to external
information system services; and Monitors security control compliance by external
service providers.
The organization requires that information system developers/integrators: Perform

configuration management during information system design, development,
implementation, and operation; Manage and control changes to the information
system; Implement only organization-approved changes; Document approved changes
to the information system; and Track security flaws and flaw resolution.
The organization requires that information system developers/integrators, in
consultation with associated security personnel (including security engineers): Create
and implement a security test and evaluation plan; Implement a verifiable flaw
remediation process to correct weaknesses and deficiencies identified during the
security testing and evaluation process; and Document the results of the security
testing/evaluation and flaw remediation processes.
The organization protects against supply chain threats by employing: [ Assignment:

organization-defined list of measures to protect against supply chain threats ] as part of
a comprehensive, defense-in-breadth information security strategy.
The organization requires that the information system meets [ Assignment:

organization-defined level of trustworthiness ].
The organization: Determines [ Assignment: organization-defined list of critical

information system components that require re-implementation ]; and Re-implements
or custom develops such information system components.
organization-defined frequency ]: A formal, documented system and communications
protection policy that addresses purpose, scope, roles, responsibilities, management
documented procedures to facilitate the implementation of the system and
communications protection policy and associated system and communications
protection controls.
The information system separates user functionality (including user interface services)
from information system management functionality.
The information system isolates security functions from nonsecurity functions.
The information system prevents unauthorized and unintended information transfer via
shared system resources.
The information system protects against or limits the efects of the following types of
denial of service attacks: [ Assignment: organization-defined list of types of denial of
service attacks or reference to source for current list ].
The information system limits the use of resources by priority.
The information system: Monitors and controls communications at the external

boundary of the system and at key internal boundaries within the system; and Connects
to external networks or information systems only through managed interfaces
consisting of boundary protection devices arranged in accordance with an
organizational security architecture.
The information system protects the integrity of transmitted information.
The information system protects the confidentiality of transmitted information.
The information system terminates the network connection associated with a

communications session at the end of the session or after [ Assignment: organization-
defined time period ] of inactivity.
The information system establishes a trusted communications path between the user
and the following security functions of the system: [ Assignment: organization-defined
security functions to include at a minimum, information system authentication and
reauthentication ].
The organization establishes and manages cryptographic keys for required cryptography
employed within the information system.
The information system implements required cryptographic protections using

cryptographic modules that comply with applicable federal laws, Executive Orders,
directives, policies, regulations, standards, and guidance.
The information system protects the integrity and availability of publicly available
information and applications.
The information system: Prohibits remote activation of collaborative computing devices

with the following exceptions: [ Assignment: organization-defined exceptions where
remote activation is to be allowed ]; and Provides an explicit indication of use to users
physically present at the devices.
The information system associates security attributes with information exchanged

between information systems.
The organization issues public key certificates under an [ Assignment: organization-

defined certificate policy ] or obtains public key certificates under an appropriate
certificate policy from an approved service provider.
The organization: Defines acceptable and unacceptable mobile code and mobile code
technologies; Establishes usage restrictions and implementation guidance for
acceptable mobile code and mobile code technologies; and Authorizes, monitors, and
controls the use of mobile code within the information system.
The organization: Establishes usage restrictions and implementation guidance for Voice
over Internet Protocol (VoIP) technologies based on the potential to cause damage to
the information system if used maliciously; and Authorizes, monitors, and controls the
use of VoIP within the information system.
The information system provides additional data origin and integrity artifacts along with
the authoritative data the system returns in response to name/address resolution
queries.
The information system performs data origin authentication and data integrity
verification on the name/address resolution responses the system receives from
authoritative sources when requested by client systems.
The information systems that collectively provide name/address resolution service for
an organization are fault-tolerant and implement internal/external role separation.
The information system provides mechanisms to protect the authenticity of

communications sessions.
The information system fails to a [ Assignment: organization-defined known-state ] for

[ Assignment: organization-defined types of failures ] preserving [ Assignment:
organization-defined system state information ] in failure.
The information system employs processing components that have minimal
functionality and information storage.
The information system includes components specifically designed to be the target of

malicious attacks for the purpose of detecting, deflecting, and analyzing such attacks.
The information system includes: [ Assignment: organization-defined operating system-

independent applications ].
The information system protects the confidentiality and integrity of information at rest.
The organization employs diverse information technologies in the implementation of

the information system.
The organization employs virtualization techniques to present information system

components as other types of components, or components with difering
configurations.
The organization requires that information system developers/integrators perform a

covert channel analysis to identify those aspects of system communication that are
potential avenues for covert storage and timing channels.
The organization partitions the information system into components residing in separate
physical domains (or environments) as deemed necessary.
The information system protects the integrity of information during the processes of
data aggregation, packaging, and transformation in preparation for transmission.
The information system at [ Assignment: organization-defined information system

components ]: Loads and executes the operating environment from hardware-enforced,
read-only media; and Loads and executes [ Assignment: organization-defined
applications ] from hardware-enforced, read-only media.

organization-defined frequency ]: A formal, documented system and information
integrity policy that addresses purpose, scope, roles, responsibilities, management
documented procedures to facilitate the implementation of the system and information
integrity policy and associated system and information integrity controls.
The organization: Identifies, reports, and corrects information system flaws; Tests
software updates related to flaw remediation for efectiveness and potential side efects
on organizational information systems before installation; and Incorporates flaw
remediation into the organizational configuration management process.
The organization: Employs malicious code protection mechanisms at information system
entry and exit points and at workstations, servers, or mobile computing devices on the
network to detect and eradicate malicious code: - Transported by electronic mail,
electronic mail attachments, web accesses, removable media, or other common means;
or - Inserted through the exploitation of information system vulnerabilities; Updates
malicious code protection mechanisms (including signature definitions) whenever new
releases are available in accordance with organizational configuration management
policy and procedures; Configures malicious code protection mechanisms to: - Perform
periodic scans of the information system [ Assignment: organization-defined frequency ]
and real-time scans of files from external sources as the files are downloaded, opened,
or executed in accordance with organizational security policy; and - [ Selection (one or
more): block malicious code; quarantine malicious code; send alert to administrator;
[ Assignment: organization-defined action ]] in response to malicious code detection;
and Addresses the receipt of false positives during malicious code detection and
eradication and the resulting potential impact on the availability of the information
system.
The organization: Monitors events on the information system in accordance with

[ Assignment: organization-defined monitoring objectives ] and detects information
system attacks; Identifies unauthorized use of the information system; Deploys
monitoring devices: (i) strategically within the information system to collect
organization-determined essential information; and (ii) at ad hoc locations within the
system to track specific types of transactions of interest to the organization; Heightens
the level of information system monitoring activity whenever there is an indication of
increased risk to organizational operations and assets, individuals, other organizations,
or the Nation based on law enforcement information, intelligence information, or other
credible sources of information; and Obtains legal opinion with regard to information
system monitoring activities in accordance with applicable federal laws, Executive
Orders, directives, policies, or regulations.
The organization: Receives information system security alerts, advisories, and directives
from designated external organizations on an ongoing basis; Generates internal security
alerts, advisories, and directives as deemed necessary; Disseminates security alerts,
advisories, and directives to [ Assignment: organization-defined list of personnel
(identified by name and/or by role) ]; and Implements security directives in accordance
with established time frames, or notifies the issuing organization of the degree of
noncompliance.
The information system verifies the correct operation of security functions [ Selection
(one or more): [ Assignment: organization-defined system transitional states ] ; upon
command by user with appropriate privilege; periodically every [ Assignment:
organization-defined time-period ]] and [ Selection (one or more): notifies system
administrator; shuts the system down; restarts the system; [ Assignment: organization-
defined alternative action(s) ]] when anomalies are discovered.
The information system detects unauthorized changes to software and information.
The organization: Employs spam protection mechanisms at information system entry

and exit points and at workstations, servers, or mobile computing devices on the
network to detect and take action on unsolicited messages transported by electronic
mail, electronic mail attachments, web accesses, or other common means; and Updates
spam protection mechanisms (including signature definitions) when new releases are
available in accordance with organizational configuration management policy and
procedures.
The organization restricts the capability to input information to the information system
to authorized personnel.
The information system checks the validity of information inputs.
The information system: Identifies potentially security-relevant error conditions;

Generates error messages that provide information necessary for corrective actions
without revealing [ Assignment: organization-defined sensitive or potentially harmful
information ] in error logs and administrative messages that could be exploited by
adversaries; and Reveals error messages only to authorized personnel.
The organization handles and retains both information within and output from the
information system in accordance with applicable federal laws, Executive Orders,
directives, policies, regulations, standards, and operational requirements.
The organization: Protects the information system from harm by considering mean time
to failure for [ Assignment: organization-defined list of information system components ]
in specific environments of operation; and Provides substitute information system
components, when needed, and a mechanism to exchange active and standby roles of
the components.
Control Guidance
This control is intended to produce the policy and procedures that are required for the efective
implementation of selected security controls and control enhancements in the access control family. The
policy and procedures are consistent with applicable federal laws, Executive Orders, directives, policies,
regulations, standards, and guidance. Existing organizational policies and procedures may make the need for
additional specific policies and procedures unnecessary. The access control policy can be included as part of
the general information security policy for the organization. Access control procedures can be developed for
the security program in general and for a particular information system, when required. The organizational risk
management strategy is a key factor in the development of the access control policy. Related control: PM-9.
The identification of authorized users of the information system and the specification of access privileges is
consistent with the requirements in other security controls in the security plan. Users requiring administrative
privileges on information system accounts receive additional scrutiny by organizational officials responsible for
approving such accounts and privileged access. Related controls: AC-3, AC-4, AC-5, AC-6, AC-10, AC-17, AC-19,
AC-20, AU-9, IA-4, IA-5, CM-5, CM-6, MA-3, MA-4, MA-5, SA-7, SC-13, SI-9.
Access control policies (e.g., identity-based policies, role-based policies, attribute-based policies) and access
enforcement mechanisms (e.g., access control lists, access control matrices, cryptography) are employed by
organizations to control access between users (or processes acting on behalf of users) and objects (e.g.,
devices, files, records, processes, programs, domains) in the information system. In addition to enforcing
authorized access at the information-system level, access enforcement mechanisms are employed at the
application level, when necessary, to provide increased information security for the organization.
Consideration is given to the implementation of an audited, explicit override of automated mechanisms in the
event of emergencies or other serious events. If encryption of stored information is employed as an access
enforcement mechanism, the cryptography used is FIPS 140-2 (as amended) compliant. For classified
information, the cryptography used is largely dependent on the classification level of the information and the
clearances of the individuals having access to the information. Mechanisms implemented by AC-3 are
configured to enforce authorizations determined by other security controls. Related controls: AC-2, AC-4, AC-5,
AC-6, AC-16, AC-17, AC-18, AC-19, AC-20, AC-21, AC-22, AU-9, CM-5, CM-6, MA-3, MA-4, MA-5, SA-7, SC-13, SI-
9.
Information flow control regulates where information is allowed to travel within an information system and
between information systems (as opposed to who is allowed to access the information) and without explicit
regard to subsequent accesses to that information. A few examples of flow control restrictions include:
keeping export controlled information from being transmitted in the clear to the Internet, blocking outside
traffic that claims to be from within the organization, and not passing any web requests to the Internet that are
not from the internal web proxy. Information flow control policies and enforcement mechanisms are
commonly employed by organizations to control the flow of information between designated sources and
destinations (e.g., networks, individuals, devices) within information systems and between interconnected
systems. Flow control is based on the characteristics of the information and/or the information path. Specific
examples of flow control enforcement can be found in boundary protection devices (e.g., proxies, gateways,
guards, encrypted tunnels, firewalls, and routers) that employ rule sets or establish configuration settings that
restrict information system services, provide a packet-filtering capability based on header information, or
message-filtering capability based on content (e.g., using key word searches or document characteristics).
Mechanisms implemented by AC-4 are configured to enforce authorizations determined by other security
controls. Related controls: AC-17, AC-19, AC-21, CM-7, SA-8, SC-2, SC-5, SC-7, SC-18.
Examples of separation of duties include: (i) mission functions and distinct information system support
functions are divided among diferent individuals/roles; (ii) diferent individuals perform information system
support functions (e.g., system management, systems programming, configuration management, quality
assurance and testing, network security); (iii) security personnel who administer access control functions do
not administer audit functions; and (iv) diferent administrator accounts for diferent roles. Access
authorizations defined in this control are implemented by control AC-3. Related controls: AC-3.
The access authorizations defined in this control are largely implemented by control AC-3. The organization
employs the concept of least privilege for specific duties and information systems (including specific ports,
protocols, and services) in accordance with risk assessments as necessary to adequately mitigate risk to
organizational operations and assets, individuals, other organizations, and the Nation. Related controls: AC-2,
AC-3, CM-7.
Due to the potential for denial of service, automatic lockouts initiated by the information system are usually
temporary and automatically release after a predetermined time period established by the organization. If a
delay algorithm is selected, the organization may chose to employ diferent algorithms for diferent
information system components based on the capabilities of those components. Response to unsuccessful
login attempts may be implemented at both the operating system and the application levels. This control
applies to all accesses other than those accesses explicitly identified and documented by the organization in
AC-14.
System use notification messages can be implemented in the form of warning banners displayed when
individuals log in to the information system. System use notification is intended only for information system
access that includes an interactive login interface with a human user and is not intended to require notification
when an interactive interface does not exist.
This control is intended to cover both traditional logons to information systems and general accesses to
information systems that occur in other types of architectural configurations (e.g., service oriented
architectures).
The organization may define the maximum number of concurrent sessions for an information system account
globally, by account type, by account, or a combination. This control addresses concurrent sessions for a given
information system account and does not address concurrent sessions by a single user via multiple system
accounts.
A session lock is a temporary action taken when a user stops work and moves away from the immediate
physical vicinity of the information system but does not want to log out because of the temporary nature of
the absence. The session lock is implemented at the point where session activity can be determined. This is
typically at the operating system-level, but may be at the application-level. A session lock is not a substitute for
logging out of the information system, for example, if the organization requires users to log out at the end of
the workday.
This control is intended for those specific instances where an organization determines that no identification
and authentication is required; it is not, however, mandating that such instances exist in given information
system. The organization may allow a limited number of user actions without identification and authentication
(e.g., when individuals access public websites or other publicly accessible federal information systems such as
http://www.usa.gov). Organizations also identify any actions that normally require identification or
authentication but may under certain circumstances (e.g., emergencies), allow identification or authentication
mechanisms to be bypassed. Such bypass may be, for example, via a software-readable physical switch that
commands bypass of the login functionality and is protected from accidental or unmonitored use. This control
does not apply to situations where identification and authentication have already occurred and are not being
repeated, but rather to situations where identification and/or authentication have not yet occurred. Related
control: CP-2, IA-2.
Security attributes are abstractions representing the basic properties or characteristics of an entity (e.g.,
subjects and objects) with respect to safeguarding information. These attributes are typically associated with
internal data structures (e.g., records, bufers, files) within the information system and are used to enable the
implementation of access control and flow control policies, reflect special dissemination, handling or
distribution instructions, or support other aspects of the information security policy. The term security label is
often used to associate a set of security attributes with a specific information object as part of the data
structure for that object (e.g., user access privileges, nationality, affiliation as contractor). Related controls: AC-
3, AC-4, SC-16, MP-3.
This control requires explicit authorization prior to allowing remote access to an information system without
specifying a specific format for that authorization. For example, while the organization may deem it
appropriate to use a system interconnection agreement to authorize a given remote access, such agreements
are not required by this control. Remote access is any access to an organizational information system by a user
(or process acting on behalf of a user) communicating through an external network (e.g., the Internet).
Examples of remote access methods include dial-up, broadband, and wireless (see AC-18 for wireless access).
A virtual private network when adequately provisioned with appropriate security controls, is considered an
internal network (i.e., the organization establishes a network connection between organization-controlled
endpoints in a manner that does not require the organization to depend on external networks to protect the
confidentiality or integrity of information transmitted across the network). Remote access controls are
applicable to information systems other than public web servers or systems specifically designed for public
access. Enforcing access restrictions associated with remote connections is accomplished by control AC-3.
Related controls: AC-3, AC-18, AC-20, IA-2, IA-3, IA-8, MA-4.
Wireless technologies include, but are not limited to, microwave, satellite, packet radio (UHF/VHF), 802.11x,
and Bluetooth. Wireless networks use authentication protocols (e.g., EAP/TLS, PEAP), which provide credential
protection and mutual authentication. In certain situations, wireless signals may radiate beyond the confines
and control of organization-controlled facilities. Related controls: AC-3, IA-2, IA-3, IA-8.
Mobile devices include portable storage media (e.g., USB memory sticks, external hard disk drives) and
portable computing and communications devices with information storage capability (e.g., notebook/laptop
computers, personal digital assistants, cellular telephones, digital cameras, and audio recording devices).
Organization-controlled mobile devices include those devices for which the organization has the authority to
specify and the ability to enforce specific security requirements. Usage restrictions and implementation
guidance related to mobile devices include, for example, configuration management, device identification and
authentication, implementation of mandatory protective software (e.g., malicious code detection, firewall),
scanning devices for malicious code, updating virus protection software, scanning for critical software updates
and patches, conducting primary operating system (and possibly other resident software) integrity checks, and
disabling unnecessary hardware (e.g., wireless, infrared). Examples of information system functionality that
provide the capability for automatic execution of code are AutoRun and AutoPlay. Organizational policies and
procedures for mobile devices used by individuals departing on and returning from travel include, for example,
determining which locations are of concern, defining required configurations for the devices, ensuring that the
devices are configured as intended before travel is initiated, and applying specific measures to the device after
travel is completed. Specially configured mobile devices include, for example, computers with sanitized hard
drives, limited applications, and additional hardening (e.g., more stringent configuration settings). Specified
measures applied to mobile devices upon return from travel include, for example, examining the device for
signs of physical tampering and purging/reimaging the hard disk drive. Protecting information residing on
mobile devices is covered in the media protection family. Related controls: MP-4, MP-5.
External information systems are information systems or components of information systems that are outside
of the authorization boundary established by the organization and for which the organization typically has no
direct supervision and authority over the application of required security controls or the assessment of
security control efectiveness. External information systems include, but are not limited to: (i) personally
owned information systems (e.g., computers, cellular telephones, or personal digital assistants); (ii) privately
owned computing and communications devices resident in commercial or public facilities (e.g., hotels,
convention centers, or airports); (iii) information systems owned or controlled by nonfederal governmental
organizations; and (iv) federal information systems that are not owned by, operated by, or under the direct
supervision and authority of the organization. For some external systems, in particular those systems operated
by other federal agencies, including organizations subordinate to those agencies, the trust relationships that
have been established between those organizations and the originating organization may be such, that no
explicit terms and conditions are required. In efect, the information systems of these organizations would not
be considered external. These situations typically occur when, for example, there is some pre-existing sharing
or trust agreement (either implicit or explicit) established between federal agencies and/or organizations
subordinate to those agencies, or such trust agreements are specified by applicable laws, Executive Orders,
directives, or policies. Authorized individuals include organizational personnel, contractors, or any other
individuals with authorized access to the organizational information system and over which the organization
has the authority to impose rules of behavior with regard to system access. The restrictions that an
organization imposes on authorized individuals need not be uniform, as those restrictions are likely to vary
depending upon the trust relationships between organizations. Thus, an organization might impose more
stringent security restrictions on a contractor than on a state, local, or tribal government. This control does not
apply to the use of external information systems to access public interfaces to organizational information
systems and information (e.g., individuals accessing federal information through www.usa.gov). The
organization establishes terms and conditions for the use of external information systems in accordance with
organizational security policies and procedures. The terms and conditions address as a minimum; (i) the types
of applications that can be accessed on the organizational information system from the external information
system; and (ii) the maximum security categorization of information that can be processed, stored, and
transmitted on the external information system. This control defines access authorizations enforced by AC-3,
rules of behavior requirements enforced by PL-4, and session establishment rules enforced by AC-17. Related
controls: AC-3, AC-17, PL-4.
The control applies to information that may be restricted in some manner (e.g., privileged medical, contract-
sensitive, proprietary, personally identifiable information, special access programs/compartments) based on
some formal or administrative determination. Depending on the information-sharing circumstance, the
sharing partner may be defined at the individual, group, or organization level and information may be defined
by specific content, type, or security categorization. Related control: AC-3.
Nonpublic information is any information for which the general public is not authorized access in accordance
with federal laws, Executive Orders, directives, policies, regulations, standards, or guidance. Information
protected under the Privacy Act and vendor proprietary information are examples of nonpublic information.
This control addresses posting information on an organizational information system that is accessible to the
general public, typically without identification or authentication. The posting of information on non-
organization information systems is covered by appropriate organizational policy. Related controls: AC-3, AU-
13.
implementation of selected security controls and control enhancements in the security awareness and training
family. The policy and procedures are consistent with applicable federal laws, Executive Orders, directives,
policies, regulations, standards, and guidance. Existing organizational policies and procedures may make the
need for additional specific policies and procedures unnecessary. The security awareness and training policy
can be included as part of the general information security policy for the organization. Security awareness and
training procedures can be developed for the security program in general and for a particular information
system, when required. The organizational risk management strategy is a key factor in the development of the
security awareness and training policy. Related control: PM-9.
The organization determines the appropriate content of security awareness training and security awareness
techniques based on the specific requirements of the organization and the information systems to which
personnel have authorized access. The content includes a basic understanding of the need for information
security and user actions to maintain security and to respond to suspected security incidents. The content also
addresses awareness of the need for operations security as it relates to the organizations information security
program. Security awareness techniques can include, for example, displaying posters, ofering supplies
inscribed with security reminders, generating email advisories/notices from senior organizational officials,
displaying logon screen messages, and conducting information security awareness events.
The organization determines the appropriate content of security training based on assigned roles and
responsibilities and the specific requirements of the organization and the information systems to which
personnel have authorized access. In addition, the organization provides information system managers, system
and network administrators, personnel performing independent verification and validation activities, security
control assessors, and other personnel having access to system-level software, adequate security-related
technical training to perform their assigned duties. Organizational security training addresses management,
operational, and technical roles and responsibilities covering physical, personnel, and technical safeguards and
countermeasures. The organization also provides the training necessary for these individuals to carry out their
responsibilities related to operations security within the context of the organizations information security
program. Related controls: AT-2, SA-3.
While an organization may deem that organizationally mandated individual training programs and the
development of individual training plans are necessary, this control does not mandate either. Documentation
for specialized training may be maintained by individual supervisors at the option of the organization.
Ongoing contact with security groups and associations is of paramount importance in an environment of rapid
technology changes and dynamic threats. Security groups and associations can include, for example, special
interest groups, specialized forums, professional associations, news groups, and/or peer groups of security
professionals in similar organizations. The groups and associations selected are consistent with the
organizations mission/business requirements. Information-sharing activities regarding threats, vulnerabilities,
and incidents related to information systems are consistent with applicable federal laws, Executive Orders,
directives, policies, regulations, standards, and guidance.
implementation of selected security controls and control enhancements in the audit and accountability family.
The policy and procedures are consistent with applicable federal laws, Executive Orders, directives, policies,
additional specific policies and procedures unnecessary. The audit and accountability policy can be included as
part of the general information security policy for the organization. Audit and accountability procedures can be
developed for the security program in general and for a particular information system, when required. The
organizational risk management strategy is a key factor in the development of the audit and accountability
policy. Related control: PM-9.
The purpose of this control is for the organization to identify events which need to be auditable as significant
and relevant to the security of the information system; giving an overall system requirement in order to meet
ongoing and specific audit needs. To balance auditing requirements with other information system needs, this
control also requires identifying that subset of auditable events that are to be audited at a given point in time.
For example, the organization may determine that the information system must have the capability to log
every file access both successful and unsuccessful, but not activate that capability except for specific
circumstances due to the extreme burden on system performance. In addition, audit records can be generated
at various levels of abstraction, including at the packet level as information traverses the network. Selecting
the right level of abstraction for audit record generation is a critical aspect of an audit capability and can
facilitate the identification of root causes to problems. Related control: AU-3.
Audit record content that may be necessary to satisfy the requirement of this control, includes, for example,
time stamps, source and destination addresses, user/process identifiers, event descriptions, success/fail
indications, filenames involved, and access control or flow control rules invoked. Related controls: AU-2, AU-8.
The organization considers the types of auditing to be performed and the audit processing requirements when
allocating audit storage capacity. Related controls: AU-2, AU-5, AU-6, AU-7, SI-4.
Audit processing failures include, for example, software/hardware errors, failures in the audit capturing
mechanisms, and audit storage capacity being reached or exceeded. Related control: AU-4.
Related control: AU-7.
An audit reduction and report generation capability provides support for near real-time audit review, analysis,
and reporting requirements described in AU-6 and after-the-fact investigations of security incidents. Audit
reduction and reporting tools do not alter original audit records. Related control: AU-6.
Time stamps generated by the information system include both date and time. The time may be expressed in
Coordinated Universal Time (UTC), a modern continuation of Greenwich Mean Time (GMT), or local time with
an ofset from UTC. Related control: AU-3.
Audit information includes all information (e.g., audit records, audit settings, and audit reports) needed to
successfully audit information system activity. Related controls: AC-3, AC-6.
Examples of particular actions taken by individuals include creating information, sending a message, approving
information (e.g., indicating concurrence or signing a contract), and receiving a message. Non-repudiation
protects individuals against later claims by an author of not having authored a particular document, a sender
of not having transmitted a message, a receiver of not having received a message, or a signatory of not having
signed a document. Non-repudiation services can be used to determine if information originated from an
individual, or if an individual took specific actions (e.g., sending an email, signing a contract, approving a
procurement request) or received specific information. Non-repudiation services are obtained by employing
various techniques or mechanisms (e.g., digital signatures, digital message receipts).
The organization retains audit records until it is determined that they are no longer needed for administrative,
legal, audit, or other operational purposes. This includes, for example, retention and availability of audit
records relative to Freedom of Information Act (FOIA) requests, subpoena, and law enforcement actions.
Standard categorizations of audit records relative to such types of actions and standard response processes for
each type of action are developed and disseminated. The National Archives and Records Administration
(NARA) General Records Schedules (GRS) provide federal policy on record retention.
Audits records can be generated from various components within the information system. The list of audited
events is the set of events for which audits are to be generated. This set of events is typically a subset of the
list of all events for which the system is capable of generating audit records (i.e., auditable events). Related
controls: AU-2, AU-3.
None.
Session auditing activities are developed, integrated, and used in consultation with legal counsel in accordance
with applicable federal laws, Executive Orders, directives, policies, or regulations.
implementation of selected security controls and control enhancements in the security assessment and
authorization family. The policies and procedures are consistent with applicable federal laws, Executive Orders,
directives, policies, regulations, standards, and guidance. Existing organizational policies and procedures may
make the need for additional specific policies and procedures unnecessary. The security
assessment/authorization policies can be included as part of the general information security policy for the
organization. Security assessment/authorization procedures can be developed for the security program in
general and for a particular information system, when required. The organizational risk management strategy
is a key factor in the development of the security assessment and authorization policy. Related control: PM-9.
The organization assesses the security controls in an information system as part of: (i) security authorization or
reauthorization; (ii) meeting the FISMA requirement for annual assessments; (iii) continuous monitoring; and
(iv) testing/evaluation of the information system as part of the system development life cycle process. The
assessment report documents the assessment results in sufficient detail as deemed necessary by the
organization, to determine the accuracy and completeness of the report and whether the security controls are
implemented correctly, operating as intended, and producing the desired outcome with respect to meeting
the security requirements of the information system. The FISMA requirement for (at least) annual security
control assessments should not be interpreted by organizations as adding additional assessment requirements
to those requirements already in place in the security authorization process. To satisfy the FISMA annual
assessment requirement, organizations can draw upon the security control assessment results from any of the
following sources, including but not limited to: (i) assessments conducted as part of an information system
authorization or reauthorization process; (ii) continuous monitoring (see CA-7); or (iii) testing and evaluation of
an information system as part of the ongoing system development life cycle (provided that the testing and
evaluation results are current and relevant to the determination of security control efectiveness). Existing
security control assessment results are reused to the extent that they are still valid and are supplemented with
additional assessments as needed. Subsequent to the initial authorization of the information system and in
accordance with OMB policy, the organization assesses a subset of the security controls annually during
continuous monitoring. The organization establishes the security control selection criteria and subsequently
selects a subset of the security controls within the information system and its environment of operation for
assessment. Those security controls that are the most volatile (i.e., controls most afected by ongoing changes
to the information system or its environment of operation) or deemed critical by the organization to protecting
organizational operations and assets, individuals, other organizations, and the Nation are assessed more
frequently in accordance with an organizational assessment of risk. All other controls are assessed at least
once during the information systems three-year authorization cycle. The organization can use the current years
assessment results from any of the above sources to meet the FISMA annual assessment requirement
provided that the results are current, valid, and relevant to determining security control efectiveness. External
audits (e.g., audits conducted by external entities such as regulatory agencies) are outside the scope of this
control. Related controls: CA-6, CA-7, PM-9, SA-11.
This control applies to dedicated connections between information systems and does not apply to transitory,
user-controlled connections such as email and website browsing. The organization carefully considers the risks
that may be introduced when information systems are connected to other systems with diferent security
requirements and security controls, both within the organization and external to the organization. Authorizing
officials determine the risk associated with each connection and the appropriate controls employed. If the
interconnecting systems have the same authorizing official, an Interconnection Security Agreement is not
required. Rather, the interface characteristics between the interconnecting information systems are described
in the security plans for the respective systems. If the interconnecting systems have diferent authorizing
officials but the authorizing officials are in the same organization, the organization determines whether an
Interconnection Security Agreement is required, or alternatively, the interface characteristics between systems
are described in the security plans of the respective systems. Instead of developing an Interconnection
Security Agreement, organizations may choose to incorporate this information into a formal contract,
especially if the interconnection is to be established between a federal agency and a nonfederal (private
sector) organization. In every case, documenting the interface characteristics is required, yet the formality and
approval process vary considerably even though all accomplish the same fundamental objective of managing
the risk being incurred by the interconnection of the information systems. Risk considerations also include
information systems sharing the same networks. Information systems may be identified and authenticated as
devices in accordance with IA-3. Related controls: AC-4, IA-3, SC-7, SA-9.
The plan of action and milestones is a key document in the security authorization package and is subject to
federal reporting requirements established by OMB. Related control: PM-4.
Security authorization is the official management decision, conveyed through the authorization decision
document, given by a senior organizational official or executive (i.e., authorizing official) to authorize operation
of an information system and to explicitly accept the risk to organizational operations and assets, individuals,
other organizations, and the Nation based on the implementation of an agreed-upon set of security controls.
Authorizing officials typically have budgetary oversight for information systems or are responsible for the
mission or business operations supported by the systems. Security authorization is an inherently federal
responsibility and therefore, authorizing officials must be federal employees. Through the security
authorization process, authorizing officials are accountable for the security risks associated with information
system operations. Accordingly, authorizing officials are in management positions with a level of authority
commensurate with understanding and accepting such information system-related security risks. Through the
employment of a comprehensive continuous monitoring process, the critical information contained in the
authorization package (i.e., the security plan (including risk assessment), the security assessment report, and
the plan of action and milestones) is updated on an ongoing basis, providing the authorizing official and the
information system owner with an up-to-date status of the security state of the information system. To reduce
the administrative cost of security reauthorization, the authorizing official uses the results of the continuous
monitoring process to the maximum extent possible as the basis for rendering a reauthorization decision.
OMB policy requires that federal information systems are reauthorized at least every three years or when
there is a significant change to the system. The organization defines what constitutes a significant change to
the information system. Related controls: CA-2, CA-7, PM-9, PM-10.
A continuous monitoring program allows an organization to maintain the security authorization of an

information system over time in a highly dynamic environment of operation with changing threats,
vulnerabilities, technologies, and missions/business processes. Continuous monitoring of security controls
using automated support tools facilitates near real-time risk management and promotes organizational
situational awareness with regard to the security state of the information system. The implementation of a
continuous monitoring program results in ongoing updates to the security plan, the security assessment
report, and the plan of action and milestones, the three principal documents in the security authorization
package. A rigorous and well executed continuous monitoring program significantly reduces the level of efort
required for the reauthorization of the information system. Continuous monitoring activities are scaled in
accordance with the security categorization of the information system. Related controls: CA-2, CA-5, CA-6, CM-
3, CM-4.
implementation of selected security controls and control enhancements in the configuration management
need for additional specific policies and procedures unnecessary. The configuration management policy can be
included as part of the general information security policy for the organization. Configuration management
procedures can be developed for the security program in general and for a particular information system,
when required. The organizational risk management strategy is a key factor in the development of the
configuration management policy. Related control: PM-9.
This control establishes a baseline configuration for the information system and its constituent components
including communications and connectivity-related aspects of the system. The baseline configuration provides
information about the components of an information system (e.g., the standard software load for a
workstation, server, network component, or mobile device including operating system/installed applications
with current version numbers and patch information), network topology, and the logical placement of the
component within the system architecture. The baseline configuration is a documented, up-to-date
specification to which the information system is built. Maintaining the baseline configuration involves creating
new baselines as the information system changes over time. The baseline configuration of the information
system is consistent with the organizations enterprise architecture. Related controls: CM-3, CM-6, CM-8, CM-9.
The organization determines the types of changes to the information system that are configuration controlled.
Configuration change control for the information system involves the systematic proposal, justification,
implementation, test/evaluation, review, and disposition of changes to the system, including upgrades and
modifications. Configuration change control includes changes to components of the information system,
changes to the configuration settings for information technology products (e.g., operating systems,
applications, firewalls, routers), emergency changes, and changes to remediate flaws. A typical organizational
process for managing configuration changes to the information system includes, for example, a chartered
Configuration Control Board that approves proposed changes to the system. Auditing of changes refers to
changes in activity before and after a change is made to the information system and the auditing activities
required to implement the change. Related controls: CM-4, CM-5, CM-6, SI-2.
Security impact analyses are conducted by organizational personnel with information security responsibilities,
including for example, Information System Administrators, Information System Security Officers, Information
System Security Managers, and Information System Security Engineers. Individuals conducting security impact
analyses have the appropriate skills and technical expertise to analyze the changes to information systems and
the associated security ramifications. Security impact analysis may include, for example, reviewing information
system documentation such as the security plan to understand how specific security controls are implemented
within the system and how the changes might afect the controls. Security impact analysis may also include an
assessment of risk to understand the impact of the changes and to determine if additional security controls
are required. Security impact analysis is scaled in accordance with the security categorization of the
information system. Related controls: CA-2, CA-7, CM-3, CM-9, SI-2.
Any changes to the hardware, software, and/or firmware components of the information system can
potentially have significant efects on the overall security of the system. Accordingly, only qualified and
authorized individuals are allowed to obtain access to information system components for purposes of
initiating changes, including upgrades and modifications. Additionally, maintaining records of access is
essential for ensuring that configuration change control is being implemented as intended and for supporting
after-the-fact actions should the organization become aware of an unauthorized change to the information
system. Access restrictions for change also include software libraries. Examples of access restrictions include,
for example, physical and logical access controls (see AC-3 and PE-3), workflow automation, media libraries,
abstract layers (e.g., changes are implemented into a third-party interface rather than directly into the
information system component), and change windows (e.g., changes occur only during specified times, making
unauthorized changes outside the window easy to discover). Some or all of the enforcement mechanisms and
processes necessary to implement this security control are included in other controls. For measures
implemented in other controls, this control provides information to be used in the implementation of the
other controls to cover specific needs related to enforcing authorizations to make changes to the information
system, auditing changes, and retaining and review records of changes. Related controls: AC-3, AC-6, PE-3.
Configuration settings are the configurable security-related parameters of information technology products
that are part of the information system. Security-related parameters are those parameters impacting the
security state of the system including parameters related to meeting other security control requirements.
Security-related parameters include, for example, registry settings; account, file, and directory settings (i.e.,
permissions); and settings for services, ports, protocols, and remote connections. Organizations establish
organization-wide mandatory configuration settings from which the settings for a given information system are
derived. A security configuration checklist (sometimes referred to as a lockdown guide, hardening guide,
security guide, security technical implementation guide [STIG], or benchmark) is a series of instructions or
procedures for configuring an information system component to meet operational requirements. Checklists
can be developed by information technology developers and vendors, consortia, academia, industry, federal
agencies (and other government organizations), and others in the public and private sectors. An example of a
security configuration checklist is the Federal Desktop Core Configuration (FDCC) which potentially afects the
implementation of CM-6 and other controls such as AC-19 and CM-7. The Security Content Automation
Protocol (SCAP) and defined standards within the protocol (e.g., Common Configuration Enumeration) provide
an efective method to uniquely identify, track, and control configuration settings. OMB establishes federal
policy on configuration requirements for federal information systems. Related controls: CM-2, CM-3, SI-4.
Information systems are capable of providing a wide variety of functions and services. Some of the functions
and services, provided by default, may not be necessary to support essential organizational operations (e.g.,
key missions, functions). Additionally, it is sometimes convenient to provide multiple services from a single
component of an information system, but doing so increases risk over limiting the services provided by any
one component. Where feasible, organizations limit component functionality to a single function per device
(e.g., email server or web server, not both). The functions and services provided by organizational information
systems, or individual components of information systems, are carefully reviewed to determine which
functions and services are candidates for elimination (e.g., Voice Over Internet Protocol, Instant Messaging,
auto-execute, file sharing). Organizations consider disabling unused or unnecessary physical and logical ports
and protocols (e.g., Universal Serial Bus [USB], File Transfer Protocol [FTP], Internet Protocol Version 6 [IPv6],
Hyper Text Transfer Protocol [HTTP]) on information system components to prevent unauthorized connection
of devices, unauthorized transfer of information, or unauthorized tunneling. Organizations can utilize network
scanning tools, intrusion detection and prevention systems, and end-point protections such as firewalls and
host-based intrusion detection systems to identify and prevent the use of prohibited functions, ports,
protocols, and services. Related control: RA-5.
Information deemed to be necessary by the organization to achieve efective property accountability can
include, for example, hardware inventory specifications (manufacturer, type, model, serial number, physical
location), software license information, information system/component owner, and for a networked
component/device, the machine name and network address. Related controls: CM-2, CM-6.
Configuration items are the information system items (hardware, software, firmware, and documentation) to
be configuration managed. The configuration management plan satisfies the requirements in the organizations
configuration management policy while being tailored to the individual information system. The configuration
management plan defines detailed processes and procedures for how configuration management is used to
support system development life cycle activities at the information system level. The plan describes how to
move a change through the change management process, how configuration settings and configuration
baselines are updated, how the information system component inventory is maintained, how development,
test, and operational environments are controlled, and finally, how documents are developed, released, and
updated. The configuration management approval process includes designation of key management
stakeholders that are responsible for reviewing and approving proposed changes to the information system,
and security personnel that would conduct an impact analysis prior to the implementation of any changes to
the system. Related control: SA-10.
implementation of selected security controls and control enhancements in the contingency planning family.
additional specific policies and procedures unnecessary. The contingency planning policy can be included as
part of the general information security policy for the organization. Contingency planning procedures can be
organizational risk management strategy is a key factor in the development of the contingency planning policy.
Related control: PM-9.
Contingency planning for information systems is part of an overall organizational program for achieving
continuity of operations for mission/business operations. Contingency planning addresses both information
system restoration and implementation of alternative mission/business processes when systems are
compromised. Information system recovery objectives are consistent with applicable laws, Executive Orders,
directives, policies, standards, or regulations. In addition to information system availability, contingency plans
also address other security-related events resulting in a reduction in mission/business efectiveness, such as
malicious attacks compromising the confidentiality or integrity of the information system. Examples of actions
to call out in contingency plans include, for example, graceful degradation, information system shutdown, fall
back to a manual mode, alternate information flows, or operating in a mode that is reserved solely for when
the system is under attack. Related controls: AC-14, CP-6, CP-7, CP-8, IR-4, PM-8, PM-11.
None.
There are several methods for testing and/or exercising contingency plans to identify potential weaknesses
(e.g., checklist, walk-through/tabletop, simulation: parallel, full interrupt). Contingency plan testing and/or
exercises include a determination of the efects on organizational operations and assets (e.g., reduction in
mission capability) and individuals arising due to contingency operations in accordance with the plan.
Related controls: CP-2, CP-9, MP-4.
Related control: CP-2.

Related control: CP-2.
System-level information includes, for example, system-state information, operating system and application
software, and licenses. Digital signatures and cryptographic hashes are examples of mechanisms that can be
employed by organizations to protect the integrity of information system backups. An organizational
assessment of risk guides the use of encryption for protecting backup information. The protection of system
backup information while in transit is beyond the scope of this control. Related controls: CP-6, MP-4.
Recovery is executing information system contingency plan activities to restore essential missions and business
functions. Reconstitution takes place following recovery and includes activities for returning the information
system to its original functional state before contingency plan activation. Recovery and reconstitution
procedures are based on organizational priorities, established recovery point/time and reconstitution
objectives, and appropriate metrics. Reconstitution includes the deactivation of any interim information
system capability that may have been needed during recovery operations. Reconstitution also includes an
assessment of the fully restored information system capability, a potential system reauthorization and the
necessary activities to prepare the system against another disruption, compromise, or failure. Recovery and
reconstitution capabilities employed by the organization can be a combination of automated mechanisms and
manual procedures. Related controls: CA-2, CA-6, CA-7, SC-24.
implementation of selected security controls and control enhancements in the identification and
authentication family. The policy and procedures are consistent with applicable federal laws, Executive Orders,
make the need for additional specific policies and procedures unnecessary. The identification and
authentication policy can be included as part of the general information security policy for the organization.
Identification and authentication procedures can be developed for the security program in general and for a
particular information system, when required. The organizational risk management strategy is a key factor in
the development of the identification and authentication policy. Related control: PM-9.
Organizational users include organizational employees or individuals the organization deems to have
equivalent status of employees (e.g., contractors, guest researchers, individuals from allied nations). Users are
uniquely identified and authenticated for all accesses other than those accesses explicitly identified and
documented by the organization in AC-14. Unique identification of individuals in group accounts (e.g., shared
privilege accounts) may need to be considered for detailed accountability of activity. Authentication of user
identities is accomplished through the use of passwords, tokens, biometrics, or in the case of multifactor
authentication, some combination thereof. Access to organizational information systems is defined as either
local or network. Local access is any access to an organizational information system by a user (or process acting
on behalf of a user) where such access is obtained by direct connection without the use of a network. Network
access is any access to an organizational information system by a user (or process acting on behalf of a user)
where such access is obtained through a network connection. Remote access is a type of network access
which involves communication through an external network (e.g., the Internet). Internal networks include local
area networks, wide area networks, and virtual private networks that are under the control of the
organization. For a virtual private network (VPN), the VPN is considered an internal network if the organization
establishes the VPN connection between organization-controlled endpoints in a manner that does not require
the organization to depend on any external networks across which the VPN transits to protect the
confidentiality and integrity of information transmitted. Identification and authentication requirements for
information system access by other than organizational users are described in IA-8. The identification and
authentication requirements in this control are satisfied by complying with Homeland Security Presidential
Directive 12 consistent with organization-specific implementation plans provided to OMB. In addition to
identifying and authenticating users at the information-system level (i.e., at logon), identification and
authentication mechanisms are employed at the application level, when necessary, to provide increased
information security for the organization. Related controls: AC-14, AC-17, AC-18, IA-4, IA-5.
The devices requiring unique identification and authentication may be defined by type, by specific device, or
by a combination of type and device as deemed appropriate by the organization. The information system
typically uses either shared known information (e.g., Media Access Control [MAC] or Transmission Control
Protocol/Internet Protocol [TCP/IP] addresses) for identification or an organizational authentication solution
(e.g., IEEE 802.1x and Extensible Authentication Protocol [EAP], Radius server with EAP-Transport Layer
Security [TLS] authentication, Kerberos) to identify and authenticate devices on local and/or wide area
networks. The required strength of the device authentication mechanism is determined by the security
categorization of the information system.
Common device identifiers include media access control (MAC) or Internet protocol (IP) addresses, or device-
unique token identifiers. Management of user identifiers is not applicable to shared information system
accounts (e.g., guest and anonymous accounts). It is commonly the case that a user identifier is the name of
an information system account associated with an individual. In such instances, identifier management is
largely addressed by the account management activities of AC-2. IA-4 also covers user identifiers not
necessarily associated with an information system account (e.g., the identifier used in a physical security
control database accessed by a badge reader system for access to the information system). Related control:
AC-2, IA-2.
User authenticators include, for example, passwords, tokens, biometrics, PKI certificates, and key cards. Initial
authenticator content is the actual content (e.g., the initial password) as opposed to requirements about
authenticator content (e.g., minimum password length). Many information system components are shipped
with factory default authentication credentials to allow for initial installation and configuration. Default
authentication credentials are often well known, easily discoverable, present a significant security risk, and
therefore, are changed upon installation. The requirement to protect user authenticators may be implemented
via control PL-4 or PS-6 for authenticators in the possession of users and by controls AC-3, AC-6, and SC-28 for
authenticators stored within the information system (e.g., passwords stored in a hashed or encrypted format,
files containing encrypted or hashed passwords accessible only with super user privileges). The information
system supports user authenticator management by organization-defined settings and restrictions for various
authenticator characteristics including, for example, minimum password length, password composition,
validation time window for time synchronous one time tokens, and number of allowed rejections during
verification stage of biometric authentication. Measures to safeguard user authenticators include, for example,
maintaining possession of individual authenticators, not loaning or sharing authenticators with others, and
reporting lost or compromised authenticators immediately. Authenticator management includes issuing and
revoking, when no longer needed, authenticators for temporary access such as that required for remote
maintenance. Device authenticators include, for example, certificates and passwords. Related controls: AC-2,
IA-2, PL-4, PS-6.
The feedback from the information system does not provide information that would allow an unauthorized
user to compromise the authentication mechanism. Displaying asterisks when a user types in a password, is an
example of obscuring feedback of authentication information.
None.
Non-organizational users include all information system users other than organizational users explicitly
covered by IA-2. Users are uniquely identified and authenticated for all accesses other than those accesses
explicitly identified and documented by the organization in accordance with AC-14. In accordance with the E-
Authentication E-Government initiative, authentication of non-organizational users accessing federal
information systems may be required to protect federal, proprietary, or privacy-related information (with
exceptions noted for national security systems). Accordingly, a risk assessment is used in determining the
authentication needs of the organization. Scalability, practicality, and security are simultaneously considered in
balancing the need to ensure ease of use for access to federal information and information systems with the
need to protect and adequately mitigate risk to organizational operations, organizational assets, individuals,
other organizations, and the Nation. Identification and authentication requirements for information system
access by organizational users are described in IA-2. Related controls: AC-14, AC-17, AC-18, MA-4.
implementation of selected security controls and control enhancements in the incident response family. The
additional specific policies and procedures unnecessary. The incident response policy can be included as part
of the general information security policy for the organization. Incident response procedures can be developed
for the security program in general and for a particular information system, when required. The organizational
risk management strategy is a key factor in the development of the incident response policy. Related control:
PM-9.
Incident response training includes user training in the identification and reporting of suspicious activities,
both from external and internal sources. Related control: AT-3.
None.
Incident-related information can be obtained from a variety of sources including, but not limited to, audit
monitoring, network monitoring, physical access monitoring, and user/administrator reports. Related controls:
AU-6, CP-2, IR-2, IR-3, PE-6, SC-5, SC-7, SI-3, SI-4, SI-7.
Documenting information system security incidents includes, for example, maintaining records about each
incident, the status of the incident, and other pertinent information necessary for forensics, evaluating
incident details, trends, and handling. Incident information can be obtained from a variety of sources
including, for example, incident reports, incident response teams, audit monitoring, network monitoring,
physical access monitoring, and user/administrator reports.
The intent of this control is to address both specific incident reporting requirements within an organization
and the formal incident reporting requirements for federal agencies and their subordinate organizations. The
types of security incidents reported, the content and timeliness of the reports, and the list of designated
reporting authorities are consistent with applicable federal laws, Executive Orders, directives, policies,
regulations, standards, and guidance. Current federal policy requires that all federal agencies (unless
specifically exempted from such requirements) report security incidents to the United States Computer
Emergency Readiness Team (US-CERT) within specified time frames designated in the US-CERT Concept of
Operations for Federal Cyber Security Incident Handling. Related controls: IR-4, IR-5.
Possible implementations of incident response support resources in an organization include a help desk or an
assistance group and access to forensics services, when required. Related controls: IR-4, IR-6.
It is important that organizations have a formal, focused, and coordinated approach to responding to incidents.
The organizations mission, strategies, and goals for incident response help determine the structure of its
incident response capability.
implementation of selected security controls and control enhancements in the system maintenance family.
additional specific policies and procedures unnecessary. The information system maintenance policy can be
included as part of the general information security policy for the organization. System maintenance
procedures can be developed for the security program in general and for a particular information system,
when required. The organizational risk management strategy is a key factor in the development of the system
maintenance policy. Related control: PM-9.
The control is intended to address the information security aspects of the organizations information system
maintenance program. Related controls: MP-6, SI-2.
The intent of this control is to address the security-related issues arising from the hardware and software
brought into the information system specifically for diagnostic and repair actions (e.g., a hardware or software
packet snifer that is introduced for the purpose of a particular maintenance activity). Hardware and/or
software components that may support information system maintenance, yet are a part of the system (e.g.,
the software implementing ping, ls, ipconfig, or the hardware and software implementing the monitoring port
of an Ethernet switch) are not covered by this control. Related control: MP-6.
Non-local maintenance and diagnostic activities are those activities conducted by individuals communicating
through a network; either an external network (e.g., the Internet) or an internal network. Local maintenance
and diagnostic activities are those activities carried out by individuals physically present at the information
system or information system component and not communicating across a network connection. Identification
and authentication techniques used in the establishment of non-local maintenance and diagnostic sessions are
consistent with the network access requirements in IA-2. Strong authenticators include, for example, PKI
where certificates are stored on a token protected by a password, passphrase, or biometric. Enforcing
requirements in MA-4 is accomplished in part, by other controls. Related controls: AC-2, AC-3, AC-6, AC-17,
AU-2, AU-3, IA-2, IA-8, MA-5, MP-6, SC-7.
Individuals not previously identified in the information system, such as vendor personnel and consultants, may
legitimately require privileged access to the system, for example, when required to conduct maintenance or
diagnostic activities with little or no notice. Based on a prior assessment of risk, the organization may issue
temporary credentials to these individuals. Temporary credentials may be for one-time use or for a very
limited time period. Related controls: IA-8, MA-5.
The organization specifies those information system components that, when not operational, result in
increased risk to organizations, individuals, or the Nation because the security functionality intended by that
component is not being provided. Security-critical components include, for example, firewalls, guards,
gateways, intrusion detection systems, audit repositories, authentication servers, and intrusion prevention
systems. Related control: CP-2.
implementation of selected security controls and control enhancements in the media protection family. The
additional specific policies and procedures unnecessary. The media protection policy can be included as part
of the general information security policy for the organization. Media protection procedures can be developed
for the security program in general and for a particular information system, when required. The organizational
risk management strategy is a key factor in the development of the media protection policy. Related control:
PM-9.
Information system media includes both digital media (e.g., diskettes, magnetic tapes, external/removable
hard drives, flash/thumb drives, compact disks, digital video disks) and non-digital media (e.g., paper,
microfilm). This control also applies to mobile computing and communications devices with information
storage capability (e.g., notebook/laptop computers, personal digital assistants, cellular telephones, digital
cameras, and audio recording devices). An organizational assessment of risk guides the selection of media and
associated information contained on that media requiring restricted access. Organizations document in policy
and procedures, the media requiring restricted access, individuals authorized to access the media, and the
specific measures taken to restrict access. Fewer protection measures are needed for media containing
information determined by the organization to be in the public domain, to be publicly releasable, or to have
limited or no adverse impact if accessed by other than authorized personnel. In these situations, it is assumed
that the physical access controls where the media resides provide adequate protection. Related controls: MP-
4, PE-3.
The term marking is used when referring to the application or use of human-readable security attributes. The
term labeling is used when referring to the application or use of security attributes with regard to internal data
structures within the information system (see AC-16, Security Attributes). Removable information system
media includes both digital media (e.g., diskettes, magnetic tapes, external/removable hard drives,
flash/thumb drives, compact disks, digital video disks) and non-digital media (e.g., paper, microfilm). An
organizational assessment of risk guides the selection of media requiring marking. Marking is generally not
required for media containing information determined by the organization to be in the public domain or to be
publicly releasable. Some organizations, however, may require markings for public information indicating that
the information is publicly releasable. Organizations may extend the scope of this control to include
information system output devices containing organizational information, including, for example, monitors and
printers. Marking of removable media and information system output is consistent with applicable federal
laws, Executive Orders, directives, policies, regulations, standards, and guidance.
Information system media includes both digital media (e.g., diskettes, magnetic tapes, external/removable
hard drives, flash/thumb drives, compact disks, digital video disks) and non-digital media (e.g., paper,
microfilm). This control also applies to mobile computing and communications devices with information
storage capability (e.g., notebook/laptop computers, personal digital assistants, cellular telephones, digital
cameras, and audio recording devices). Telephone systems are also considered information systems and may
have the capability to store information on internal media (e.g., on voicemail systems). Since telephone
systems do not have, in most cases, the identification, authentication, and access control mechanisms typically
employed in other information systems, organizational personnel use extreme caution in the types of
information stored on telephone voicemail systems. A controlled area is any area or space for which the
organization has confidence that the physical and procedural protections are sufficient to meet the
requirements established for protecting the information and/or information system. An organizational
assessment of risk guides the selection of media and associated information contained on that media
requiring physical protection. Fewer protection measures are needed for media containing information
determined by the organization to be in the public domain, to be publicly releasable, or to have limited or no
adverse impact on the organization or individuals if accessed by other than authorized personnel. In these
situations, it is assumed that the physical access controls to the facility where the media resides provide
adequate protection. As part of a defense-in-depth strategy, the organization considers routinely encrypting
information at rest on selected secondary storage devices. The employment of cryptography is at the
discretion of the information owner/steward. The selection of the cryptographic mechanisms used is based
upon maintaining the confidentiality and integrity of the information. The strength of mechanisms is
commensurate with the classification and sensitivity of the information. Related controls: AC-3, AC-19, CP-6,
CP-9, MP-2, PE-3.
Information system media includes both digital media (e.g., diskettes, magnetic tapes, removable hard drives,
flash/thumb drives, compact disks, digital video disks) and non-digital media (e.g., paper, microfilm). This
control also applies to mobile computing and communications devices with information storage capability
(e.g., notebook/laptop computers, personal digital assistants, cellular telephones, digital cameras, and audio
recording devices) that are transported outside of controlled areas. Telephone systems are also considered
information systems and may have the capability to store information on internal media (e.g., on voicemail
systems). Since telephone systems do not have, in most cases, the identification, authentication, and access
control mechanisms typically employed in other information systems, organizational personnel use caution in
the types of information stored on telephone voicemail systems that are transported outside of controlled
areas. A controlled area is any area or space for which the organization has confidence that the physical and
procedural protections provided are sufficient to meet the requirements established for protecting the
information and/or information system. Physical and technical security measures for the protection of digital
and non-digital media are commensurate with the classification or sensitivity of the information residing on
the media, and consistent with applicable federal laws, Executive Orders, directives, policies, regulations,
standards, and guidance. Locked containers and cryptography are examples of security measures available to
protect digital and non-digital media during transport. Cryptographic mechanisms can provide confidentiality
and/or integrity protections depending upon the mechanisms used. An organizational assessment of risk
guides: (i) the selection of media and associated information contained on that media requiring protection
during transport; and (ii) the selection and use of storage containers for transporting non-digital media.
Authorized transport and courier personnel may include individuals from outside the organization (e.g., U.S.
Postal Service or a commercial transport or delivery service). Related controls: AC-19, CP-9.
This control applies to all media subject to disposal or reuse, whether or not considered removable.
Sanitization is the process used to remove information from information system media such that there is
reasonable assurance that the information cannot be retrieved or reconstructed. Sanitization techniques,
including clearing, purging, and destroying media information, prevent the disclosure of organizational
information to unauthorized individuals when such media is reused or released for disposal. The organization
uses its discretion on the employment of sanitization techniques and procedures for media containing
information deemed to be in the public domain or publicly releasable, or deemed to have no adverse impact
on the organization or individuals if released for reuse or disposal.
implementation of selected security controls and control enhancements in the physical and environmental
protection family. The policy and procedures are consistent with applicable federal laws, Executive Orders,
make the need for additional specific policies and procedures unnecessary. The physical and environmental
protection policy can be included as part of the general information security policy for the organization.
Physical and environmental protection procedures can be developed for the security program in general and
for a particular information system, when required. The organizational risk management strategy is a key factor
in the development of the physical and environmental protection policy. Related control: PM-9.
Authorization credentials include, for example, badges, identification cards, and smart cards. Related control:
PE-3, PE-4.
The organization determines the types of guards needed, for example, professional physical security staf or
other personnel such as administrative staf or information system users, as deemed appropriate. Physical
access devices include, for example, keys, locks, combinations, and card readers. Workstations and associated
peripherals connected to (and part of) an organizational information system may be located in areas
designated as publicly accessible with access to such devices being safeguarded. Related controls: MP-2, MP-4,
PE-2
Physical protections applied to information system distribution and transmission lines help prevent accidental
damage, disruption, and physical tampering. Additionally, physical protections are necessary to help prevent
eavesdropping or in transit modification of unencrypted transmissions. Protective measures to control physical
access to information system distribution and transmission lines include: (i) locked wiring closets; (ii)
disconnected or locked spare jacks; and/or (iii) protection of cabling by conduit or cable trays. Related control:
PE-2.
Monitors, printers, and audio devices are examples of information system output devices.
Investigation of and response to detected physical security incidents, including apparent security violations or
suspicious physical access activities, are part of the organizations incident response capability.
Individuals (to include organizational employees, contract personnel, and others) with permanent
authorization credentials for the facility are not considered visitors.
Visitor access records include, for example, name/organization of the person visiting, signature of the visitor,
form(s) of identification, date of access, time of entry and departure, purpose of visit, and name/organization
of person visited.
This control, to include any enhancements specified, may be satisfied by similar requirements fulfilled by
another organizational entity other than the information security program. Organizations avoid duplicating
actions already covered.
This control applies to facilities containing concentrations of information system resources, for example, data
centers, server rooms, and mainframe computer rooms.
Fire suppression and detection devices/systems include, for example, sprinkler systems, handheld fire
extinguishers, fixed fire hoses, and smoke detectors. This control, to include any enhancements specified, may
be satisfied by similar requirements fulfilled by another organizational entity other than the information
security program. Organizations avoid duplicating actions already covered.
Efectively enforcing authorizations for entry and exit of information system components may require
restricting access to delivery areas and possibly isolating the areas from the information system and media
libraries.
Alternate work sites may include, for example, government facilities or private residences of employees. The
organization may define diferent sets of security controls for specific alternate work sites or types of sites.
Physical and environmental hazards include, for example, flooding, fire, tornados, earthquakes, hurricanes,
acts of terrorism, vandalism, electromagnetic pulse, electrical interference, and electromagnetic radiation.
Whenever possible, the organization also considers the location or site of the facility with regard to physical
and environmental hazards. In addition, the organization considers the location of physical entry points where
unauthorized individuals, while not being granted access, might nonetheless be in close proximity to the
information system and therefore, increase the potential for unauthorized access to organizational
communications (e.g., through the use of wireless snifers or microphones). This control, to include any
enhancements specified, may be satisfied by similar requirements fulfilled by another organizational entity
other than the information security program. Organizations avoid duplicating actions already covered.
The security categorization of the information system (with respect to confidentiality) and organizational
security policy guides the application of safeguards and countermeasures employed to protect the information
system against information leakage due to electromagnetic signals emanations.
implementation of selected security controls and control enhancements in the security planning family. The
additional specific policies and procedures unnecessary. The security planning policy addresses the overall
policy requirements for confidentiality, integrity, and availability and can be included as part of the general
information security policy for the organization. Security planning procedures can be developed for the
security program in general and for a particular information system, when required. The organizational risk
management strategy is a key factor in the development of the security planning policy. Related control: PM-9.
The security plan contains sufficient information (including specification of parameters for assignment and
selection statements in security controls either explicitly or by reference) to enable an implementation that is
unambiguously compliant with the intent of the plan and a subsequent determination of risk to organizational
operations and assets, individuals, other organizations, and the Nation if the plan is implemented as intended.
Related controls: PM-1, PM-7, PM-8, PM-9, PM-11.
The organization considers diferent sets of rules based on user roles and responsibilities, for example,
diferentiating between the rules that apply to privileged users and rules that apply to general users. Electronic
signatures are acceptable for use in acknowledging rules of behavior. Related control: PS-6.
None.
Security-related activities include, for example, security assessments, audits, system hardware and software
maintenance, and contingency plan testing/exercises. Organizational advance planning and coordination
includes both emergency and nonemergency (i.e., planned or nonurgent unplanned) situations.
The information security program plan can be represented in a single document or compilation of documents
at the discretion of the organization. The plan documents the organization-wide program management
controls and organization-defined common controls. The security plans for individual information systems and
the organization-wide information security program plan together, provide complete coverage for all security
controls employed within the organization. Common controls are documented in an appendix to the
organizations information security program plan unless the controls are included in a separate security plan for
an information system (e.g., security controls employed as part of an intrusion detection system providing
organization-wide boundary protection inherited by one or more organizational information systems). The
organization-wide information security program plan will indicate which separate security plans contain
descriptions of common controls. Organizations have the flexibility to describe common controls in a single
document or in multiple documents. In the case of multiple documents, the documents describing common
controls are included as attachments to the information security program plan. If the information security
program plan contains multiple documents, the organization specifies in each document the organizational
official or officials responsible for the development, implementation, assessment, authorization, and
monitoring of the respective common controls. For example, the organization may require that the Facilities
Management Office develop, implement, assess, authorize, and continuously monitor common physical and
environmental protection controls from the PE family when such controls are not associated with a particular
information system but instead, support multiple information systems. Related control: PM-8.
The security officer described in this control is an organizational official. For a federal agency (as defined in
applicable federal laws, Executive Orders, directives, policies, or regulations) this official is the Senior Agency
Information Security Officer. Organizations may also refer to this organizational official as the Senior
Information Security Officer or Chief Information Security Officer.
Organizations may designate and empower an Investment Review Board (or similar group) to manage and
provide oversight for the information security-related aspects of the capital planning and investment control
process. Related controls: PM-4, SA-2.
The plan of action and milestones is a key document in the information security program and is subject to
federal reporting requirements established by OMB. The plan of action and milestones updates are based on
the findings from security control assessments, security impact analyses, and continuous monitoring activities.
OMB FISMA reporting guidance contains instructions regarding organizational plans of action and milestones.
Related control: CA-5.
This control addresses the inventory requirements in FISMA. OMB provides guidance on developing
information systems inventories and associated reporting requirements.
Measures of performance are outcome-based metrics used by an organization to measure the efectiveness or
efficiency of the information security program and the security controls employed in support of the program.
The enterprise architecture developed by the organization is aligned with the Federal Enterprise Architecture.
The integration of information security requirements and associated security controls into the organizations
enterprise architecture helps to ensure that security considerations are addressed by organizations early in the
system development life cycle and are directly and explicitly related to the organizations mission/business
processes. This also embeds into the enterprise architecture, an integral security architecture consistent with
organizational risk management and information security strategies. Security requirements and control
integration are most efectively accomplished through the application of the Risk Management Framework and
supporting security standards and guidelines. The Federal Segment Architecture Methodology provides
guidance on integrating information security requirements and security controls into enterprise architectures.
Related controls: PL-2, PM-11, RA-2.
The requirement and guidance for defining critical infrastructure and key resources and for preparing an
associated critical infrastructure protection plan are found in applicable federal laws, Executive Orders,
directives, policies, regulations, standards, and guidance. Related controls: PM-1, PM-9, PM-11, RA-3.
An organization-wide risk management strategy includes, for example, an unambiguous expression of the risk
tolerance for the organization, acceptable risk assessment methodologies, risk mitigation strategies, a process
for consistently evaluating risk across the organization with respect to the organizations risk tolerance, and
approaches for monitoring risk over time. The use of a risk executive function can facilitate consistent,
organization-wide application of the risk management strategy. The organization-wide risk management
strategy can be informed by risk-related inputs from other sources both internal and external to the
organization to ensure the strategy is both broad-based and comprehensive. Related control: RA-3.
The security authorization process for information systems requires the implementation of the Risk
Management Framework and the employment of associated security standards and guidelines. Specific roles
within the risk management process include a designated authorizing official for each organizational
information system. Related control: CA-6.
Information protection needs are technology-independent, required capabilities to counter threats to
organizations, individuals, or the Nation through the compromise of information (i.e., loss of confidentiality,
integrity, or availability). Information protection needs are derived from the mission/business needs defined
by the organization, the mission/business processes selected to meet the stated needs, and the organizational
risk management strategy. Information protection needs determine the required security controls for the
organization and the associated information systems supporting the mission/business processes. Inherent in
defining an organizations information protection needs is an understanding of the level of adverse impact that
could result if a compromise of information occurs. The security categorization process is used to make such
potential impact determinations. Mission/business process definitions and associated information protection
requirements are documented by the organization in accordance with organizational policy and procedure.
Related controls: PM-7, PM-8, RA-2.
implementation of selected security controls and control enhancements in the personnel security family. The
additional specific policies and procedures unnecessary. The personnel security policy can be included as part
of the general information security policy for the organization. Personnel security procedures can be
organizational risk management strategy is a key factor in the development of the personnel security policy.
Position risk designations are consistent with Office of Personnel Management policy and guidance. The
screening criteria include explicit information security role appointment requirements (e.g., training, security
clearance).
Screening and rescreening are consistent with applicable federal laws, Executive Orders, directives, policies,
regulations, standards, guidance, and the criteria established for the risk designation of the assigned position.
The organization may define diferent rescreening conditions and frequencies for personnel accessing the
information system based on the type of information processed, stored, or transmitted by the system.
Information system-related property includes, for example, hardware authentication tokens, system
administration technical manuals, keys, identification cards, and building passes. Exit interviews ensure that
individuals understand any security constraints imposed by being former employees and that proper
accountability is achieved for all information system-related property. Exit interviews may not be possible for
some employees (e.g., in the case of job abandonment, some illnesses, and nonavailability of supervisors). Exit
interviews are important for individuals with security clearances. Timely execution of this control is particularly
essential for employees or contractors terminated for cause.
This control applies when the reassignment or transfer of an employee is permanent or of such an extended
duration as to make the actions warranted. In addition the organization defines the actions appropriate for the
type of reassignment or transfer; whether permanent or temporary. Actions that may be required when
personnel are transferred or reassigned to other positions within the organization include, for example: (i)
returning old and issuing new keys, identification cards, and building passes; (ii) closing previous information
system accounts and establishing new accounts; (iii) changing information system access authorizations; and
(iv) providing for access to official records to which the employee had access at the previous work location and
in the previous information system accounts.
Access agreements include, for example, nondisclosure agreements, acceptable use agreements, rules of
behavior, and conflict-of-interest agreements. Signed access agreements include an acknowledgement that
individuals have read, understand, and agree to abide by the constraints associated with the information
system to which access is authorized. Electronic signatures are acceptable for use in acknowledging access
agreements unless specifically prohibited by organizational policy. Related control: PL-4.
Third-party providers include, for example, service bureaus, contractors, and other organizations providing
information system development, information technology services, outsourced applications, and network and
security management. The organization explicitly includes personnel security requirements in acquisition-
related documents.
The sanctions process is consistent with applicable federal laws, Executive Orders, directives, policies,
regulations, standards, and guidance. The process is described in access agreements and can be included as
part of the general personnel policies and procedures for the organization. Related controls: PL-4, PS-6.
implementation of selected security controls and control enhancements in the risk assessment family. The
additional specific policies and procedures unnecessary. The risk assessment policy can be included as part of
the general information security policy for the organization. Risk assessment procedures can be developed for
the security program in general and for a particular information system, when required. The organizational risk
management strategy is a key factor in the development of the risk assessment policy. Related control: PM-9.
A clearly defined authorization boundary is a prerequisite for an efective security categorization. Security
categorization describes the potential adverse impacts to organizational operations, organizational assets, and
individuals should the information and information system be comprised through a loss of confidentiality,
integrity, or availability. The organization conducts the security categorization process as an organization-wide
activity with the involvement of the chief information officer, senior information security officer, information
system owner, mission owners, and information owners/stewards. The organization also considers potential
adverse impacts to other organizations and, in accordance with the USA PATRIOT Act of 2001 and Homeland
Security Presidential Directives, potential national-level adverse impacts in categorizing the information
system. The security categorization process facilitates the creation of an inventory of information assets, and in
conjunction with CM-8, a mapping to the information system components where the information is processed,
stored, and transmitted. Related controls: CM-8, MP-4, SC-7.
A clearly defined authorization boundary is a prerequisite for an efective risk assessment. Risk assessments
take into account vulnerabilities, threat sources, and security controls planned or in place to determine the
level of residual risk posed to organizational operations and assets, individuals, other organizations, and the
Nation based on the operation of the information system. Risk assessments also take into account risk posed
to organizational operations, organizational assets, or individuals from external parties (e.g., service providers,
contractors operating information systems on behalf of the organization, individuals accessing organizational
information systems, outsourcing entities). In accordance with OMB policy and related E-authentication
initiatives, authentication of public users accessing federal information systems may also be required to
protect nonpublic or privacy-related information. As such, organizational assessments of risk also address
public access to federal information systems. The General Services Administration provides tools supporting
that portion of the risk assessment dealing with public access to federal information systems. Risk assessments
(either formal or informal) can be conducted by organizations at various steps in the Risk Management
Framework including: information system categorization; security control selection; security control
implementation; security control assessment; information system authorization; and security control
monitoring. RA-3 is a noteworthy security control in that the control must be partially implemented prior to
the implementation of other controls in order to complete the first two steps in the Risk Management
Framework. Risk assessments can play an important role in the security control selection process during the
application of tailoring guidance for security control baselines and when considering supplementing the
tailored baselines with additional security controls or control enhancements.
The security categorization of the information system guides the frequency and comprehensiveness of the
vulnerability scans. Vulnerability analysis for custom software and applications may require additional, more
specialized techniques and approaches (e.g., web-based application scanners, source code reviews, source
code analyzers). Vulnerability scanning includes scanning for specific functions, ports, protocols, and services
that should not be accessible to users or devices and for improperly configured or incorrectly operating
information flow mechanisms. The organization considers using tools that express vulnerabilities in the
Common Vulnerabilities and Exposures (CVE) naming convention and that use the Open Vulnerability
Assessment Language (OVAL) to test for the presence of vulnerabilities. The Common Weakness Enumeration
(CWE) and the National Vulnerability Database (NVD) are also excellent sources for vulnerability information.
In addition, security control assessments such as red team exercises are another source of potential
vulnerabilities for which to scan. Related controls: CA-2, CM-6, RA-3, SI-2.
implementation of selected security controls and control enhancements in the system and services acquisition
need for additional specific policies and procedures unnecessary. The system and services acquisition policy
can be included as part of the general information security policy for the organization. System and services
acquisition procedures can be developed for the security program in general and for a particular information
system, when required. The organizational risk management strategy is a key factor in the development of the
system and services acquisition policy. Related control: PM-9.
Related controls: PM-3, PM-11.

The acquisition documents for information systems, information system components, and information system
services include, either explicitly or by reference, security requirements that describe: (i) required security
capabilities (i.e., security needs and, as necessary, specific security controls and other specific FISMA
requirements); (ii) required design and development processes; (iii) required test and evaluation procedures;
and (iv) required documentation. The requirements in the acquisition documents permit updating security
controls as new threats/vulnerabilities are identified and as new technologies are implemented. Acquisition
documents also include requirements for appropriate information system documentation. The documentation
addresses user and system administrator guidance and information regarding the implementation of the
security controls in the information system. The level of detail required in the documentation is based on the
security categorization for the information system. In addition, the required documentation includes security
configuration settings and security implementation guidance. FISMA reporting instructions provide guidance
on configuration requirements for federal information systems.
The inability of the organization to obtain necessary information system documentation may occur, for
example, due to the age of the system and/or lack of support from the vendor/contractor. In those situations,
organizations may need to recreate selected information system documentation if such documentation is
essential to the efective implementation and/or operation of security controls.
Tracking systems can include, for example, simple spreadsheets or fully automated, specialized applications
depending on the needs of the organization.
If provided the necessary privileges, users have the ability to install software. The organization identifies what
types of software installations are permitted (e.g., updates and security patches to existing software) and what
types of installations are prohibited (e.g., software whose pedigree with regard to being potentially malicious
is unknown or suspect). Related control: CM-2.
The application of security engineering principles is primarily targeted at new development information
systems or systems undergoing major upgrades and is integrated into the system development life cycle. For
legacy information systems, the organization applies security engineering principles to system upgrades and
modifications to the extent feasible, given the current state of the hardware, software, and firmware within
the system. Examples of security engineering principles include, for example: (i) developing layered
protections; (ii) establishing sound security policy, architecture, and controls as the foundation for design; (iii)
incorporating security into the system development life cycle; (iv) delineating physical and logical security
boundaries; (v) ensuring system developers and integrators are trained on how to develop secure software; (vi)
tailoring security controls to meet organizational and operational needs; and (vii) reducing risk to acceptable
levels, thus enabling informed risk management decisions.
An external information system service is a service that is implemented outside of the authorization boundary
of the organizational information system (i.e., a service that is used by, but not a part of, the organizational
information system). Relationships with external service providers are established in a variety of ways, for
example, through joint ventures, business partnerships, outsourcing arrangements (i.e., contracts, interagency
agreements, lines of business arrangements), licensing agreements, and/or supply chain exchanges. The
responsibility for adequately mitigating risks arising from the use of external information system services
remains with the authorizing official. Authorizing officials require that an appropriate chain of trust be
established with external service providers when dealing with the many issues associated with information
security. For services external to the organization, a chain of trust requires that the organization establish and
retain a level of confidence that each participating provider in the potentially complex consumer-provider
relationship provides adequate protection for the services rendered to the organization. The extent and nature
of this chain of trust varies based on the relationship between the organization and the external provider.
Where a sufficient level of trust cannot be established in the external services and/or service providers, the
organization employs compensating security controls or accepts the greater degree of risk. The external
information system services documentation includes government, service provider, and end user security roles
and responsibilities, and any service-level agreements. Service-level agreements define the expectations of
performance for each required security control, describe measurable outcomes, and identify remedies and
response requirements for any identified instance of noncompliance.
Related controls: CM-3, CM-4, CM-9.

Developmental security test results are used to the greatest extent feasible after verification of the results and
recognizing that these results are impacted whenever there have been security-relevant modifications to the
information system subsequent to developer testing. Test results may be used in support of the security
authorization process for the delivered information system. Related control: CA-2, SI-2.
A defense-in-breadth approach helps to protect information systems (including the information technology
products that compose those systems) throughout the system development life cycle (i.e., during design and
development, manufacturing, packaging, assembly, distribution, system integration, operations, maintenance,
and retirement). This is accomplished by the identification, management, and elimination of vulnerabilities at
each phase of the life cycle and the use of complementary, mutually reinforcing strategies to mitigate risk.
The intent of this control is to ensure that organizations recognize the importance of trustworthiness and
making explicit trustworthiness decisions when designing, developing, and implementing organizational
information systems. Trustworthiness is a characteristic or property of an information system that expresses
the degree to which the system can be expected to preserve the confidentiality, integrity, and availability of
the information being processed, stored, or transmitted by the system. Trustworthy information systems are
systems that are capable of being trusted to operate within defined levels of risk despite the environmental
disruptions, human errors, and purposeful attacks that are expected to occur in the specified environments of
operation. Two factors afecting the trustworthiness of an information system include: (i) security functionality
(i.e., the security features or functions employed within the system); and (ii) security assurance (i.e., the
grounds for confidence that the security functionality is efective in its application). Appropriate security
functionality for the information system can be obtained by using the Risk Management Framework (Steps 1,
2, and 3) to select and implement the necessary management, operational, and technical security controls
necessary to mitigate risk to organizational operations and assets, individuals, other organizations, and the
Nation. Appropriate security assurance can be obtained by: (i) the actions taken by developers and
implementers of security controls with regard to the design, development, implementation, and operation of
those controls; and (ii) the actions taken by assessors to determine the extent to which the controls are
implemented correctly, operating as intended, and producing the desired outcome with respect to meeting
the security requirements for the information system. Developers and implementers can increase the
assurance in security controls by employing well-defined security policy models, structured, disciplined, and
rigorous hardware and software development techniques, and sound system/security engineering principles.
Assurance is also based on the assessment of evidence produced during the initiation,
acquisition/development, implementation, and operations/maintenance phases of the system development
life cycle. For example, developmental evidence may include the techniques and methods used to design and
develop security functionality. Operational evidence may include flaw reporting and remediation, the results
of security incident reporting, and the results of the ongoing monitoring of security controls. Independent
assessments by qualified assessors may include analyses of the evidence as well as testing, inspections, and
audits. Minimum assurance requirements are described in Appendix E. Explicit trustworthiness decisions
highlight situations where achieving the information system resilience and security capability necessary to
withstand cyber attacks from adversaries with certain threat capabilities may require adjusting the risk
management strategy, the design of mission/business processes with regard to automation, the selection and
implementation rigor of management and operational protections, or the selection of information technology
components with higher levels of trustworthiness. Trustworthiness may be defined on a component-by-
component, subsystem-by-subsystem, or function-by-function basis. It is noted, however, that typically
functions, subsystems, and components are highly interrelated, making separation by trustworthiness perhaps
The underlying assumption is that the list of information technology products defined by the organization
cannot be trusted due to threats from the supply chain that the organization finds unacceptable. The
organization re-implements or custom develops such components to satisfy requirements for high assurance.
Related controls: SA-12, SA-13.
implementation of selected security controls and control enhancements in the system and communications
protection family. The policy and procedures are consistent with applicable federal laws, Executive Orders,
make the need for additional specific policies and procedures unnecessary. The system and communications
protection policy can be included as part of the general information security policy for the organization.
System and communications protection procedures can be developed for the security program in general and
for a particular information system, when required. The organizational risk management strategy is a key factor
in the development of the system and communications protection policy. Related control: PM-9.
Information system management functionality includes, for example, functions necessary to administer
databases, network components, workstations, or servers, and typically requires privileged user access. The
separation of user functionality from information system management functionality is either physical or logical
and is accomplished by using diferent computers, diferent central processing units, diferent instances of the
operating system, diferent network addresses, combinations of these methods, or other methods as
appropriate. An example of this type of separation is observed in web administrative interfaces that use
separate authentication methods for users of any other information system resources. This may include
isolating the administrative interface on a diferent domain and with additional access controls.
The information system isolates security functions from nonsecurity functions by means of an isolation
boundary (implemented via partitions and domains) that controls access to and protects the integrity of, the
hardware, software, and firmware that perform those security functions. The information system maintains a
separate execution domain (e.g., address space) for each executing process. Related control: SA-13.
The purpose of this control is to prevent information, including encrypted representations of information,
produced by the actions of a prior user/role (or the actions of a process acting on behalf of a prior user/role)
from being available to any current user/role (or current process) that obtains access to a shared system
resource (e.g., registers, main memory, secondary storage) after that resource has been released back to the
information system. Control of information in shared resources is also referred to as object reuse. This control
does not address: (i) information remanence which refers to residual representation of data that has been in
some way nominally erased or removed; (ii) covert channels where shared resources are manipulated to
achieve a violation of information flow restrictions; or (iii) components in the information system for which
there is only a single user/role.
A variety of technologies exist to limit, or in some cases, eliminate the efects of denial of service attacks. For
example, boundary protection devices can filter certain types of packets to protect devices on an organizations
internal network from being directly afected by denial of service attacks. Employing increased capacity and
bandwidth combined with service redundancy may reduce the susceptibility to some denial of service attacks.
Related control: SC-7.
Priority protection helps prevent a lower-priority process from delaying or interfering with the information
system servicing any higher-priority process. This control does not apply to components in the information
system for which there is only a single user/role.
Restricting external web traffic only to organizational web servers within managed interfaces and prohibiting
external traffic that appears to be spoofing an internal address as the source are examples of restricting and
prohibiting communications. Managed interfaces employing boundary protection devices include, for
example, proxies, gateways, routers, firewalls, guards, or encrypted tunnels arranged in an efective security
architecture (e.g., routers protecting firewalls and application gateways residing on a protected subnetwork
commonly referred to as a demilitarized zone or DMZ). The organization considers the intrinsically shared
nature of commercial telecommunications services in the implementation of security controls associated with
the use of such services. Commercial telecommunications services are commonly based on network
components and consolidated management systems shared by all attached commercial customers, and may
include third-party provided access lines and other service elements. Consequently, such interconnecting
transmission services may represent sources of increased risk despite contract security provisions. Therefore,
when this situation occurs, the organization either implements appropriate compensating security controls or
explicitly accepts the additional risk. Related controls: AC-4, IR-4, SC-5.
This control applies to communications across internal and external networks. If the organization is relying on
a commercial service provider for transmission services as a commodity item rather than a fully dedicated
service, it may be more difficult to obtain the necessary assurances regarding the implementation of needed
security controls for transmission integrity. When it is infeasible or impractical to obtain the necessary security
controls and assurances of control efectiveness through appropriate contracting vehicles, the organization
either implements appropriate compensating security controls or explicitly accepts the additional risk. Related
controls: AC-17, PE-4.
This control applies to communications across internal and external networks. If the organization is relying on
a commercial service provider for transmission services as a commodity item rather than a fully dedicated
service, it may be more difficult to obtain the necessary assurances regarding the implementation of needed
security controls for transmission confidentiality. When it is infeasible or impractical to obtain the necessary
security controls and assurances of control efectiveness through appropriate contracting vehicles, the
organization either implements appropriate compensating security controls or explicitly accepts the additional
risk. Related controls: AC-17, PE-4.
This control applies to both internal and external networks. Terminating network connections associated with
communications sessions include, for example, de-allocating associated TCP/IP address/port pairs at the
operating-system level, or de-allocating networking assignments at the application level if multiple application
sessions are using a single, operating system-level network connection. The time period of inactivity may, as
the organization deems necessary, be a set of time periods by type of network access or for specific accesses.
A trusted path is employed for high-confidence connections between the security functions of the information
system and the user (e.g., for login).
Cryptographic key management and establishment can be performed using manual procedures or automated
mechanisms with supporting manual procedures. In addition to being required for the efective operation of a
cryptographic mechanism, efective cryptographic key management provides protections to maintain the
availability of the information in the event of the loss of cryptographic keys by users.
None.
The purpose of this control is to ensure that organizations explicitly address the protection needs for public
information and applications with such protection likely being implemented as part of other security controls.
Collaborative computing devices include, for example, networked white boards, cameras, and microphones.
Explicit indication of use includes, for example, signals to users when collaborative computing devices are
activated
Security attributes may be explicitly or implicitly associated with the information contained within the
information system. Related control: AC-16.
For user certificates, each organization attains certificates from an approved, shared service provider, as
required by OMB policy. For federal agencies operating a legacy public key infrastructure cross-certified with
the Federal Bridge Certification Authority at medium assurance or higher, this Certification Authority will
suffice. This control focuses on certificates with a visibility external to the information system and does not
include certificates related to internal system operations, for example, application-specific time services.
Decisions regarding the employment of mobile code within organizational information systems are based on
the potential for the code to cause damage to the system if used maliciously. Mobile code technologies
include, for example, Java, JavaScript, ActiveX, PDF, Postscript, Shockwave movies, Flash animations, and
VBScript. Usage restrictions and implementation guidance apply to both the selection and use of mobile code
installed on organizational servers and mobile code downloaded and executed on individual workstations.
Policy and procedures related to mobile code, address preventing the development, acquisition, or
introduction of unacceptable mobile code within the information system.
None.
This control enables remote clients to obtain origin authentication and integrity verification assurances for the
host/service name to network address resolution information obtained through the service. A domain name
system (DNS) server is an example of an information system that provides name/address resolution service.
Digital signatures and cryptographic keys are examples of additional artifacts. DNS resource records are
examples of authoritative data. Information systems that use technologies other than the DNS to map
between host/service names and network addresses provide other means to assure the authenticity and
integrity of response data. The DNS security controls are consistent with, and referenced from, OMB
Memorandum 08-23.
A recursive resolving or caching domain name system (DNS) server is an example of an information system that
provides name/address resolution service for local clients. Authoritative DNS servers are examples of
authoritative sources. Information systems that use technologies other than the DNS to map between
host/service names and network addresses provide other means to enable clients to verify the authenticity
and integrity of response data.
A domain name system (DNS) server is an example of an information system that provides name/address
resolution service. To eliminate single points of failure and to enhance redundancy, there are typically at least
two authoritative domain name system (DNS) servers, one configured as primary and the other as secondary.
Additionally, the two servers are commonly located in two diferent network subnets and geographically
separated (i.e., not located in the same physical facility). With regard to role separation, DNS servers with an
internal role, only process name/address resolution requests from within the organization (i.e., internal
clients). DNS servers with an external role only process name/address resolution information requests from
clients external to the organization (i.e., on the external networks including the Internet). The set of clients
that can access an authoritative DNS server in a particular role is specified by the organization (e.g., by address
ranges, explicit lists).
This control focuses on communications protection at the session, versus packet, level. The intent of this
control is to establish grounds for confidence at each end of a communications session in the ongoing identity
of the other party and in the validity of the information being transmitted. For example, this control addresses
man-in-the-middle attacks including session hijacking or insertion of false information into a session. This
control is only implemented where deemed necessary by the organization (e.g., sessions in service-oriented
architectures providing web-based services).
Failure in a known state can address safety or security in accordance with the mission/business needs of the
organization. Failure in a known secure state helps prevent a loss of confidentiality, integrity, or availability in
the event of a failure of the information system or a component of the system. Failure in a known safe state
helps prevent systems from failing to a state that may cause injury to individuals or destruction to property.
Preserving information system state information facilitates system restart and return to the operational mode
of the organization with less disruption of mission/business processes.
The deployment of information system components with minimal functionality (e.g., diskless nodes and thin
client technologies) reduces the need to secure every user endpoint, and may reduce the exposure of
information, information systems, and services to a successful attack. Related control: SC-30.
None.
Operating system-independent applications are applications that can run on multiple operating systems. Such
applications promote portability and reconstitution on diferent platform architectures, increasing the
availability for critical functionality within an organization while information systems with a given operating
system are under attack.
This control is intended to address the confidentiality and integrity of information at rest in nonmobile devices
and covers user information and system information. Information at rest refers to the state of information
when it is located on a secondary storage device (e.g., disk drive, tape drive) within an organizational
information system. Configurations and/or rule sets for firewalls, gateways, intrusion detection/prevention
systems, and filtering routers and authenticator content are examples of system information likely requiring
protection. Organizations may choose to employ diferent mechanisms to achieve confidentiality and integrity
protections, as appropriate.
Increasing the diversity of information technologies within the information system reduces the impact of the
exploitation of a specific technology. Organizations that select this control should consider that an increase in
diversity may add complexity and management overhead, both of which have the potential to lead to mistakes
and misconfigurations which could increase overall risk.
Virtualization techniques provide organizations with the ability to disguise information systems, potentially
reducing the likelihood of successful attacks without the cost of having multiple platforms.
Information system developers/integrators are in the best position to identify potential avenues within the
system that might lead to covert channels. Covert channel analysis is a meaningful activity when there is the
potential for unauthorized information flows across security domains, for example, in the case of information
systems containing export-controlled information and having connections to external networks (i.e., networks
not controlled by the organization). Covert channel analysis is also meaningful in the case of multilevel secure
(MLS) systems, multiple security level (MSL) systems, and cross domain systems.
Information system partitioning is a part of a defense-in-depth protection strategy. An organizational

assessment of risk guides the partitioning of information system components into separate physical domains
(or environments). The security categorization also guides the selection of appropriate candidates for domain
partitioning. Managed interfaces restrict or prohibit network access and information flow among partitioned
information system components. Related controls: AC-4, SC-7.
Information can be subjected to unauthorized changes (e.g., malicious and/or unintentional modification) at
information aggregation or protocol transformation points.
In this control, the term operating environment is defined as the code upon which applications are hosted, for
example, a monitor, executive, operating system, or application running directly on the hardware platform.
Hardware-enforced, read-only media include, for example, CD-R/DVD-R disk drives. Use of non-modifiable
storage ensures the integrity of the software program from the point of creation of the read-only image.
implementation of selected security controls and control enhancements in the system and information
integrity family. The policy and procedures are consistent with applicable federal laws, Executive Orders,
make the need for additional specific policies and procedures unnecessary. The system and information
integrity policy can be included as part of the general information security policy for the organization. System
and information integrity procedures can be developed for the security program in general and for a particular
information system, when required. The organizational risk management strategy is a key factor in the
development of the system and information integrity policy. Related control: PM-9.
The organization identifies information systems containing software afected by recently announced software
flaws (and potential vulnerabilities resulting from those flaws) and reports this information to designated
organizational officials with information security responsibilities (e.g., senior information security officers,
information system security managers, information systems security officers). The organization (including any
contractor to the organization) promptly installs security-relevant software updates (e.g., patches, service
packs, and hot fixes). Flaws discovered during security assessments, continuous monitoring, incident response
activities, or information system error handling, are also addressed expeditiously. Organizations are
encouraged to use resources such as the Common Weakness Enumeration (CWE) or Common Vulnerabilities
and Exposures (CVE) databases in remediating flaws discovered in organizational information systems. By
requiring that flaw remediation be incorporated into the organizational configuration management process, it
is the intent of this control that required/anticipated remediation actions are tracked and verified. An example
of expected flaw remediation that would be so verified is whether the procedures contained in US-CERT
guidance and Information Assurance Vulnerability Alerts have been accomplished. Related controls: CA-2, CA-
7, CM-3, MA-2, IR-4, RA-5, SA-11, SI-11.
Information system entry and exit points include, for example, firewalls, electronic mail servers, web servers,
proxy servers, and remote-access servers. Malicious code includes, for example, viruses, worms, Trojan horses,
and spyware. Malicious code can also be encoded in various formats (e.g., UUENCODE, Unicode) or contained
within a compressed file. Removable media includes, for example, USB devices, diskettes, or compact disks. A
variety of technologies and methods exist to limit or eliminate the efects of malicious code attacks. Pervasive
configuration management and strong software integrity controls may be efective in preventing execution of
unauthorized code. In addition to commercial of-the-shelf software, malicious code may also be present in
custom-built software. This could include, for example, logic bombs, back doors, and other types of cyber
attacks that could afect organizational missions and business functions. Traditional malicious code protection
mechanisms are not built to detect such code. In these situations, organizations must rely instead on other risk
mitigation measures to include, for example, secure coding practices, trusted procurement processes,
configuration management and control, and monitoring practices to help ensure that software does not
perform functions other than those intended. Related controls: SA-4, SA-8, SA-12, SA-13, SI-4, SI-7.
Information system monitoring includes external and internal monitoring. External monitoring includes the
observation of events occurring at the system boundary (i.e., part of perimeter defense and boundary
protection). Internal monitoring includes the observation of events occurring within the system (e.g., within
internal organizational networks and system components). Information system monitoring capability is
achieved through a variety of tools and techniques (e.g., intrusion detection systems, intrusion prevention
systems, malicious code protection software, audit record monitoring software, network monitoring software).
Strategic locations for monitoring devices include, for example, at selected perimeter locations and near server
farms supporting critical applications, with such devices typically being employed at the managed interfaces
associated with controls SC-7 and AC-17. The Einstein network monitoring device from the Department of
Homeland Security is an example of a system monitoring device. The granularity of the information collected is
determined by the organization based on its monitoring objectives and the capability of the information
system to support such activities. An example of a specific type of transaction of interest to the organization
with regard to monitoring is Hyper Text Transfer Protocol (HTTP) traffic that bypasses organizational HTTP
proxies, when use of such proxies is required. Related controls: AC-4, AC-8, AC-17, AU-2, AU-6, SI-3, SI-7.
Security alerts and advisories are generated by the United States Computer Emergency Readiness Team (US-
CERT) to maintain situational awareness across the federal government. Security directives are issued by OMB
or other designated organizations with the responsibility and authority to issue such directives. Compliance to
security directives is essential due to the critical nature of many of these directives and the potential
immediate adverse afects on organizational operations and assets, individuals, other organizations, and the
Nation should the directives not be implemented in a timely manner.
The need to verify security functionality applies to all security functions. For those security functions that are
not able to execute automated self-tests, the organization either implements compensating security controls
or explicitly accepts the risk of not performing the verification as required. Information system transitional
states include, for example, startup, restart, shutdown, and abort.
The organization employs integrity verification applications on the information system to look for evidence of
information tampering, errors, and omissions. The organization employs good software engineering practices
with regard to commercial of-the-shelf integrity mechanisms (e.g., parity checks, cyclical redundancy checks,
cryptographic hashes) and uses tools to automatically monitor the integrity of the information system and the
applications it hosts.
Information system entry and exit points include, for example, firewalls, electronic mail servers, web servers,
proxy servers, and remote-access servers. Related controls: SC-5, SI-3.
Restrictions on organizational personnel authorized to input information to the information system may extend
beyond the typical access controls employed by the system and include limitations based on specific
operational/project responsibilities. Related controls: AC-5, AC-6.
Rules for checking the valid syntax and semantics of information system inputs (e.g., character set, length,
numerical range, acceptable values) are in place to verify that inputs match specified definitions for format
and content. Inputs passed to interpreters are prescreened to prevent the content from being unintentionally
interpreted as commands.
The structure and content of error messages are carefully considered by the organization. The extent to which
the information system is able to identify and handle error conditions is guided by organizational policy and
operational requirements. Sensitive information includes, for example, account numbers, social security
numbers, and credit card numbers.
The output handling and retention requirements cover the full life cycle of the information, in some cases
extending beyond the disposal of the information system. The National Archives and Records Administration
provides guidance on records retention. Related controls: MP-2, MP-4.
While mean time to failure is primarily a reliability issue, this control focuses on the potential failure of specific
components of the information system that provide security capability. Mean time to failure rates are
defendable and based on considerations that are installation-specific, not industry-average. The transfer of
responsibilities between active and standby information system components does not compromise safety,
operational readiness, or security (e.g., state variables are preserved). The standby component is available at
all times except where a failure recovery is in progress or for maintenance reasons. Related control: CP-2.
Testing
Procedures
Control Exists
Yes or No
Evidence of Control
Control is Executed Correctly Control Output
Comments Artifact
Function Category


IDENTIFY (ID)





agreements.

PROTECT (PR)



DETECT (DE) Security Continuous Monitoring (DE.CM): The information system

events and verify the effectiveness of protective measures.

anomalous events.


RESPOND (RS)
RESPOND (RS)





and vendors.
Subcategory

inventoried

established
established


forums and sources



appropriate


responsibilities



least functionality

events



accountability

needed

risks


ISO 27001
Controls
,
Testing Guidance
Procedures
Control Exists:
Yes or No
Evidence of Control
HIPPA RULE
45 CFR 164.308 Administrative Safeguards

164.308 (a)(1)(i) Standard: Security Management Process
Implement policies and procedures to prevent, detect, contain, and correct security violations.
164.308 (a)(1)(ii) Implementation Specifications
(A) Risk analysis (Required). Conduct an accurate and thorough assessment of the potential risks
and vulnerabilities to the confidentiality, integrity, and availability of electronic protected health
information held by the covered entity.
(B) Risk management (Required). Implement security measures sufficient to reduce risks and
vulnerabilities to a reasonable and appropriate level to comply with § 164.306(a).
(C) Sanction policy (Required). Apply appropriate sanctions against workforce members who fail to
comply with the security policies and procedures of the covered entity.
(D) Information system activity review. Implement procedures to regularly review records of
information system activity, such as audit logs, access reports, and security incident tracking
reports.
164.308 (a)(2) Standard: Assigned Security Responsibility
Identify the security official who is responsible for the development and implementation of the
policies and procedures required by this subpart for the entity.
164.308 (a)(3)(i) Standard: Workforce Security

Implement policies and procedures to ensure that all members of its workforce have appropriate
access to electronic protected health information, as provided under paragraph (a)(4) of this
section, and to prevent those workforce members who do not have access under paragraph (a)(4)
of this section from obtaining access to electronic protected health information.

(A) Authorization and/or supervision (Addressable). Implement procedures for the authorization
and/or supervision of workforce members who work with electronic protected health information
or in locations where it might be accessed.
(B) Workforce clearance procedure (Addressable). Implement procedures to determine that the
access of a workforce member to electronic protected health information is appropriate.
(C) Termination procedures (Addressable). Implement procedures for terminating access to

electronic protected health information when the employment of a workforce member ends or as
required by determinations made as specified in paragraph (a)(3)(ii)(B) of this section.
164.308 (a)(4)(i) Standard: Information Access Management
Implement policies and procedures for authorizing access to electronic protected health
information that are consistent with the applicable requirements of subpart E of this part.
(A) Isolating health care clearinghouse functions (Required). If a health care clearinghouse is part
of a larger organization, the clearinghouse must implement policies and procedures that protect
the electronic protected health information of the clearinghouse from unauthorized access by the
larger organization.
(B) Access authorization (Addressable). Implement policies and procedures for granting access to
electronic protected health information, for example, through access to a workstation, transaction,
program, process, or other mechanism.
(C) Access establishment and modification (Addressable). Implement policies and procedures that,
based upon the entity’s access authorization policies, establish, document, review, and modify a
user’s right of access to a workstation, transaction, program, or process.
164.308 (a)(5)(i) Standard: Security Awareness and Training

Implement a security awareness and training program for all members of its workforce (including
management).
164.308 (a)(5)(ii) Implementation specifications. Implement
(A) Security reminders (Addressable). Periodic security updates.
(B) Protection from malicious software (Addressable). Procedures for guarding against, detecting,
and reporting malicious software.
(C) Log-in monitoring (Addressable). Procedures for monitoring log-in attempts and reporting
discrepancies.
(D) Password management (Addressable). Procedures for creating, changing, and safeguarding
passwords.
164.308 (a)(6)(i) Standard: Security incident Procedures
Implement policies and procedures to address security incidents.
164.308 (a)(6)(ii) Implementation Specification
Response and reporting. Identify and respond to suspected or known security incidents; mitigate,
to the extent practicable, harmful efects of security incidents that are known to the covered
entity; and document security incidents and outcomes.
Response and reporting. Identify and respond to suspected or known security incidents; mitigate,
to the extent practicable, harmful efects of security incidents that are known to the covered
entity; and document security incidents and outcomes.
164.308 (a)(7)(i) Standard: Contingency Plan

Establish (and implement as needed) policies and procedures for responding to an emergency or
other occurrence (for example, fire, vandalism, system failure, and natural disaster) that damages
systems that contain electronic protected health information.

(A) Data backup plan (Required). Establish and implement procedures to create and maintain
retrievable exact copies of electronic protected health information.
(B) Disaster recovery plan (Required). Establish (and implement as needed) procedures to restore
any loss of data.
(C) Emergency mode operation plan (Required). Establish (and implement as needed) procedures
to enable continuation of critical business processes for protection of the security of electronic
protected health information while operating in emergency mode.
(D) Testing and revision procedures (Addressable). Implement procedures for periodic testing and
revision of contingency plans.
(E) Applications and data criticality analysis (Addressable). Assess the relative criticality of specific
applications and data in support of other contingency plan components.
164.308 (a)(8) Standard: Evaluation
Perform a periodic technical and nontechnical evaluation, based initially upon the standards
implemented under this rule and subsequently, in response to environmental or operational
changes afecting the security of electronic protected health information that establishes the
extent to which an entity’s security policies and procedures meet the requirements of this subpart.
164.308 (b)(1) Standard: Business associate contracts and other arrangements.

A covered entity, in accordance with § 164.306, may permit a business associate to create, receive,
maintain, or transmit electronic protected health information on the covered entity’s behalf only if
the covered entity obtains satisfactory assurances, in accordance with § 164.314(a) that the
business associate will appropriately safeguard the information.
164.308 (b)(2) This standard does not apply with respect to—
(i) The transmission by a covered entity of electronic protected health information to a health care
provider concerning the treatment of an individual.
(ii) The transmission of electronic protected health information by a group health plan or an HMO
or health insurance issuer on behalf of a group health plan to a plan sponsor, to the extent that the
requirements of § 164.314(b) and § 164.504(f) apply and are met; or
(iii) The transmission of electronic protected health information from or to other agencies
providing the services at § 164.502(e)(1)(ii)(C), when the covered entity is a health plan that is
public benefits, if the requirements of § 164.502(e)(1)(ii)(C) are met.
164.308 (b)( 3) Implementation specifications: Written contract or other arrangement

A covered entity that violates the satisfactory assurances it provided as a business associate of
another covered entity will be in noncompliance with the standards, implementation
specifications, and requirements of this paragraph and § 164.314(a).
164.308 (b)(4) Implementation Specifications

Written contract or other arrangement (Required). Document the satisfactory assurances required
by paragraph (b)(1) of this section through a written contract or other arrangement with the
business associate that meets the applicable requirements of § 164.314(a).
45 CFR 164.310 Physical safeguards.

164.310 (a)(1) Standard: Facility Access Controls
Implement policies and procedures to limit physical access to its electronic information systems
and the facility or facilities in which they are housed, while ensuring that properly authorized
access is allowed.
164.310 (a)(2)(i) Implementation Specifications

Contingency operations (Addressable). Establish (and implement as needed) procedures that allow
facility access in support of restoration of lost data under the disaster recovery plan and
emergency mode operations plan in the event of an emergency.
164.310 (a)(2)(ii)
Facility security plan (Addressable). Implement policies and procedures to safeguard the facility
and the equipment therein from unauthorized physical access, tampering, and theft.
164.310 (a)(2)(iii)
Access control and validation procedures (Addressable). Implement procedures to control and
validate a person’s access to facilities based on their role or function, including visitor control, and
control of access to software programs for testing and revision.
164.310 (a)(2)(iv)
Maintenance records (Addressable). Implement policies and procedures to document repairs and
modifications to the physical components of a facility which are related to security (for example,
hardware, walls, doors, and locks).
164.310 (b) Standard: Workstation Use

Implement policies and procedures that specify the proper functions to be performed, the manner
in which those functions are to be performed, and the physical attributes of the surroundings of a
specific workstation or class of workstation that can access electronic protected health
information.
164-310(c) Standard: Workstation Security

Implement physical safeguards for all workstations that access electronic protected health
information, to restrict access to authorized users.
164.310 (d)(1) Standard: Device and Media Controls
Implement policies and procedures that govern the receipt and removal of hardware and
electronic media that contain electronic protected health information into and out of a facility, and
the movement of these items within the facility.
164.310 (d)(2)(i) Implementation specifications:

Disposal (Required). Implement policies and procedures to address the final disposition of
electronic protected health information, and/or the hardware or electronic media on which it is
stored.
164.310 (d)2)(ii)
Media re-use (Required). Implement procedures for removal of electronic protected health
information from electronic media before the media are made available for re-use.
164.310 (d)(2)(iii)
Accountability (Addressable). Maintain a record of the movements of hardware and electronic
media and any person responsible therefore.
164.310 (d)(2)(iv)
Data backup and storage (Addressable). Create a retrievable, exact copy of electronic protected
health information, when needed, before movement of equipment.
45 CFR 164.312 Technical safeguards.
164.312 (a)(1) Standard: Access Control
Implement technical policies and procedures for electronic information systems that maintain
electronic protected health information to allow access only to those persons or software
programs that have been granted access rights as specified in § 164.308(a)(4).
164.312 (a)(2)(i) Implementation Specifications

Unique user identification (Required). Assign a unique name and/or number for identifying and
tracking user identity.
164.312 (a)(2)(ii)
Emergency access procedure (Required). Establish (and implement as needed) procedures for
obtaining necessary electronic protected health information during an emergency.
164.312 (a)(2)(iii)
Automatic logof (Addressable). Implement electronic procedures that terminate an electronic
session after a predetermined time of inactivity.
164.312 (a)(2)(iv)
Encryption and decryption (Addressable). Implement a mechanism to encrypt and decrypt
electronic protected health information.
164-312 (b) Standard: Audit Controls
Implement hardware, software, and/or procedural mechanisms that record and examine activity in
information systems that contain or use electronic protected health information.
164.312 (c)(1) Standard: Integrity
Implement policies and procedures to protect electronic protected health information from
improper alteration or destruction.
164.312 (c)(2) Implementation Specification
Mechanism to authenticate electronic protected health information (Addressable). Implement
electronic mechanisms to corroborate that electronic protected health information has not been
altered or destroyed in an unauthorized manner.
164.312 (d) Standard: Person or Entity Authentication.

Implement procedures to verify that a person or entity seeking access to electronic protected
health information is the one claimed.
164.312 (e)(1) Standard: Transmission Security.
Implement technical security measures to guard against unauthorized access to electronic
protected health information that is being transmitted over an electronic communications
network.
164.312 (e)(2)(i) Implementation Specifications

Integrity controls (Addressable). Implement security measures to ensure that electronically
transmitted electronic protected health information is not improperly modified without detection
until disposed of.
164.312 (e)(2)(ii)
Encryption (Addressable). Implement a mechanism to encrypt electronic protected health
information whenever deemed appropriate.
Recommendation
Well documented policies and procedures provide a baseline for governance, risk, and compliance
processes that ultimately ensure that data and the systems that house it are secure. Policies are
adhered to in accordance to established mandates and controls.
Once documented, unless modified by contractual agreements, policies and procedures are
reviewed annually at a minimum. Typically, these documents are updated due to changes such as
environment updates/upgrades, government mandates etc.
Risk assessments are conducted annually at a minimum (unless modified by contractual

agreements) while implementing and enforcing security awareness for all personnel regarding
HIPAA data security.
As a service provider, we acknowledge to internal and external customers that we are responsible
for security of electronic access to health data and to remain in compliance with privacy
regulations set by HHS.
Detection of security violations is a key requirement to be implemented and observed in a cyber
security environment. Not only detection systems must be in place to monitor anomalies or
suspicious activity, but tracking and identification of abnormal activities should be reported with
the end goal of remediation and eventually preventing future compromising activities.
Documented procedures should include information that is relevant to monitoring and reporting
incidents. Systems should alert personnel of suspicious activity while logging/tracking those
activities for further review by security personnel. Audit trails must have a minimum set of
identifiable data for each event such as user, event type, date and time of occurrance, success or
failure indicator, event origination, name of of afected data, system component, or resource.
Documented policies and procedures must address the implementation of additional security
features for any system component deemed insecure. In addition, these policies and procedures
must address the governance of personnel and locations where protected health information is
accessible.
Personnel access to protected health information must be approved and authorized to access
system components based on a user's need to know. This leads to assignment of privileges to
individuals based on job classification and function resulting in user-authentication management
that validates access to protected health information.
PCI DSS 3.2 Control
PCI REFERENCE
12.1 12.1 Establish, publish, maintain, and disseminate a security policy.

12.1.1 12.1.1 Review the security policy at least annually and update the policy when
the environment changes.
12.1.3 #N/A
12.2 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.),
• 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.6 12.6 Implement a formal security awareness program to make all personnel
aware of the importance of cardholder data security policy and procedures.
12.9 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.
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.9.1 #N/A
12.9.2 #N/A
12.9.3 #N/A
12.9.4 #N/A
#N/A
PCI Does Not #N/A

Specifically
Address Risk
Analysis or
Management
PCI Does Not #N/A

Specifically
Address Risk
Analysis or
Management
PCI Does Not #N/A

Specifically
Address
Sanctions
10.2.7 10.2.7 Creation and deletion of system-level objects

10.3 10.3 Record at least the following audit trail entries for all system components
for each event:
10.3.1 10.3.1 User identification
10.3.2 10.3.2 Type of event
10.3.3 10.3.3 Date and time
10.3.4 10.3.4 Success or failure indication
10.3.5 10.3.5 Origination of event
10.3.6 10.3.6 Identity or name of afected data, system component, or resource.
10.6 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.
11.5 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).
12.9.6 #N/A Is there a 12.9.6??? I don't see it.
PCI Does Not #N/A

Specifically
Address
Identifying
Security Officials
#N/A
2.2.3 2.2.3 Implement additional security features for any required services,
Note: Where SSL/early TLS is used, the requirements in Appendix A2 must be
completed.
7.1.4 7.1.4 Require documented approval by authorized parties specifying required

privileges.
7.2 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.
7.2.3 7.2.3 Default “deny-all” setting.
8.2 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:

8.5.1 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.
Note: This requirement is not intended to apply to shared hosting providers

accessing their own hosting environment, where multiple customer
environments are hosted.
8.5.16 #N/A
10.2.7 10.2.7 Creation and deletion of system- level objects
for each event:
Requirement.

at least weekly.
#N/A



8.5.16 #N/A
#N/A
2.1.1 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.
completed.
6.6 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.

privileges.
12.8.2 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 cardholder data environment.
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.
completed.

privileges.
7.2 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.
7.2.3 7.2.3 Default “deny-all” setting.



8.5.16 #N/A


8.5.16 #N/A
#N/A
#N/A
5.1 5.1 Deploy anti-virus software on all systems commonly afected by malicious
software (particularly personal computers and servers).
5.1.1 5.1.1 Ensure that anti-virus programs are capable of detecting, removing, and
protecting against all known types of malicious software.
5.2 5.2 Ensure that all anti-virus mechanisms are maintained as follows:

• Perform periodic scans
• Generate audit logs which are retained per PCI DSS Requirement 10.7.
10.1 10.1 Implement audit trails to link all access to system components to each
individual user.
10.2 10.2 Implement automated audit trails for all system components to
reconstruct the following events:
10.2.1 10.2.1 All individual user accesses to cardholder data
10.2.5 #N/A
for each event:
10.5.4 10.5.4 Write logs for external-facing technologies onto a secure, centralized,
internal log server or media device.
Requirement.

at least weekly.
2.1 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, point-of-sale (POS) terminals, Simple Network Management
Protocol (SNMP) community strings, etc.).

8.4 8.4 Document and communicate authentication procedures and policies 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.5 8.5 Do not use group, shared, or generic IDs, passwords, or other
authentication methods as follows:

▪ Shared user IDs do not exist for system administration and other critical
functions.
components.
8.5.10 #N/A
8.5.11 #N/A
8.5.12 #N/A
8.5.13 #N/A
8.5.14 #N/A
8.5.2 #N/A
8.5.3 #N/A
8.5.7 #N/A
8.5.8 #N/A
8.5.9 #N/A
#N/A
12.6 12.6 Implement a formal security awareness program to make all personnel
aware of the importance of cardholder data security policy and procedures.
12.9 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
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.9.1 #N/A
12.9.2 #N/A
12.9.3 #N/A
12.9.4 #N/A
12.9.6 #N/A
9.1.1 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.
#N/A
#N/A
#N/A
#N/A
#N/A
11.3 11.3 Implement a methodology for penetration testing that includes 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 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.
12.1 12.1 Establish, publish, maintain, and disseminate a security policy.

12.1.2 #N/A
12.1.3 #N/A
12.2 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.),
• 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.
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
3.2 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

Sensitive authentication data includes the data as cited in the following

Requirements 3.2.1 through 3.2.3:
8.1 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:



8.5.16 #N/A
8.5.8 #N/A
12.3.2 12.3.2 Authentication for use of the technology

privileges.
8.5.15 #N/A
12.3.8 12.3.8 Automatic disconnect of sessions for remote-access technologies after

a specific period of inactivity
3.5 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.
3.5.1 3.5.1 Additional requirement for service providers only: Maintain a

documented description of the cryptographic architecture that includes:
• Details of all algorithms, protocols, and keys used for the protection of
cardholder data, including key strength and expiry date
• Description of the key usage for each key
• Inventory of any HSMs and other SCDs used for key management
Note: This requirement is a best practice until January 31, 2018, after which it
3.5.2 3.5.2 Restrict access to cryptographic keys to the fewest number of custodians
necessary.
3.6 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.1 3.6.1 Generation of strong cryptographic keys

3.6.2 3.6.2 Secure cryptographic key distribution
3.6.3 3.6.3 Secure cryptographic key storage
3.6.4 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.5 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.6 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.7 3.6.7 Prevention of unauthorized substitution of cryptographic keys.

3.6.8 3.6.8 Requirement for cryptographic key custodians to formally acknowledge
that they understand and accept their key-custodian responsibilities.
10.1 10.1 Implement audit trails to link all access to system components to each
individual user.
10.2 10.2 Implement automated audit trails for all system components to
reconstruct the following events:
10.2.1 10.2.1 All individual user accesses to cardholder data
10.2.5 #N/A
for each event:
10.5.4 10.5.4 Write logs for external-facing technologies onto a secure, centralized,
internal log server or media device.
Requirement.
at least weekly.
2.3 2.3 Encrypt all non-console administrative access using strong cryptography.
completed.
4.1 4.1 Use strong cryptography and security protocols to safeguard sensitive
cardholder data during transmission over open, public networks, including the
following:
• The protocol in use only supports secure versions or configurations.
• The encryption strength is appropriate for the encryption methodology in
use.
completed.
• The internet
• General Packet Radio Service (GPRS)
• Satellite communications
4.1.1 4.1.1 Ensure wireless networks transmitting cardholder data or connected to
the cardholder data environment, use industry best practices to implement
strong encryption for authentication and transmission.
#N/A
#N/A
3.2 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

Sensitive authentication data includes the data as cited in the following

Requirements 3.2.1 through 3.2.3:
8.1 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:



8.5.16 #N/A
8.5.8 #N/A
12.3.2 12.3.2 Authentication for use of the technology
#N/A
2.1.1 #N/A
following:
use.
completed.
• The internet

following:
use.
completed.
• The internet

Solution Type
0
0
#N/A
0
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
0
0
0
0
0
0
0
0
0
0
#N/A
#N/A
#N/A
Audit / Interview / Sample Review

#N/A
0
0
0
0
0
0
0
0
#N/A

#N/A
#N/A


#N/A
#N/A
#N/A
#N/A
0
#N/A
0
0
0
0
0
0
0
0
0
0

#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
0
0
#N/A
#N/A
#N/A
#N/A
#N/A
Physical Security
#N/A
#N/A
#N/A
#N/A
#N/A
0
0
#N/A
#N/A
0
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A

#N/A
#N/A
0
#N/A
0


0
#N/A
0
0
0
0
0
0
0
0
0
0

#N/A
#N/A

#N/A
#N/A
0
#N/A
#N/A


Requirement Solution Description
0
0
#N/A
0
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
0
0
0
0
0
0
0
0
0
0
#N/A
#N/A
#N/A
All integrated security features should be well-documented and follow an

established baseline. For situations where an insecure protocol must be used,
this documentation should spell out how a safeguard is being leveraged to
protect the asset
To ensure that this capability exists and is in place, once each new application
or system is stood up an admin needs only to attempt to login via a credential
set that has not been explicitly permitted access. As long as the authentication
attempt is unsuccessful, the test can be deemed a success.
The SOP can easily be reviewed to detect any shortcomings in organizational

policies, as well as confirm principles such as least privilege exist. This artifact
should be revised in accordance with industry standards guidelines
User Access Management policy and processes will set the standards for user
passwords and/or other authentication methods.
Passwords must meet the minimum standards set by the policy:
▪ Length
▪ Not reused
▪ Not matching ID
▪ Non-repeating
Process for distributing and initializing tokens / smart cards
Utilize a random password or pass phrase generators or another industry

accepted method for ensuring unique passwords and pass phrases, even
across multiple customers
#N/A
0
0
0
0
0
0
0
0
#N/A
▪ Length
▪ Not reused
▪ Not matching ID
▪ Non-repeating

#N/A
#N/A
The adoption of CIS benchmarks in the organization is ultimately a

management decision and requires their commitment. The benefits of
leveraging this standard should be considered by all respective teams, and
incorporated by the administrator/engineer prior to the installation of any
software.

protect the asset
The review or internal audit is scheduled.
The review or audit plan is communicated. Stakeholders and responsible
resources are notified. Process documentation and evidence of the
performance of the process is reviewed. Non-conformances are noted and
documented. Results are presented and reviewed. Corrective actions are
identified, planned and assigned. Follow up activities and efectiveness
reviews are completed

protect the asset

▪ Length
▪ Not reused
▪ Not matching ID
▪ Non-repeating

#N/A
▪ Length
▪ Not reused
▪ Not matching ID
▪ Non-repeating

#N/A
#N/A
#N/A
The anti-virus solution is an application to be installed onto the client it is
meant to protect. This can be done manually, as part of an image, or remotely
executed
The anti-virus solution is an application to be installed onto the client it is
meant to protect. This can be done manually, as part of an image, or remotely
executed
A vulnerability scan or pentest on the client is a definite act that should be

carried out by an experienced professional
This capability can either be reviewed in the vendors documentation regarding

their product, or selectively. enabled. The organization can confirm the
existence of a HIDS solution by looking within installed programs on the
endpoint, or reviewing the logs feeding into a SIEM
0
#N/A
0
0
0
0
0
0
0
0
0
0
This configuration change would be made my the admin or engineer

responsible for setting up the WAP.

software.
Policy and Process documentation is published and periodically reviewed and
updated.
Policy and Process documentation is communicated to the appropriate user
community
Policy and Process training is provided during on boarding and periodically
Policy and Process documentation is published to periodically review the

active user list to ensure:
 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.
Automated reporting or manual reviews will be conducted to complete the

review per the client site's capabilities and environment.
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
0
0
#N/A
#N/A
#N/A
#N/A
#N/A
Video surveillance and access logging should be considered in the design of a

data center, computer room, or other physical area with systems in the CDE.
Where these controls are not already in place, facilities upgrades should be
planned and implemented to ensure compliance with Requirement 9 of the
DSS
#N/A
#N/A
#N/A
#N/A
#N/A
0
0
#N/A
#N/A
0
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
For complying to PCI DSS, data that is termed as authentication data should
not be stored beyond the retention period. This data includes magnetic strip
contents, verification code and PIN. The deletion of such data is important as
this data is extremely valuable for scammers as they can make fake duplicate
payment cards based upon this information. If sensitive authentication data is
received, follow the company procedure for safely deleting the data and verify
that no recovery of the data is possible.
User access controls are in place and used by the appropriate user
administrators so that each user ID is uniquely assigned to an individual user.
No "generic" user IDs are created or permitted by policy
▪ Length
▪ Not reused
▪ Not matching ID
▪ Non-repeating

#N/A
#N/A
0
#N/A
0
Keys should remain in a protected key vault at all times. In particular, ensure
that there is a gap between the threat vectors that have direct access to the
data and the threat vectors that have direct access to the keys. This implies
that keys should not be stored on the application or web server (assuming
that application attackers are part of the relevant threat model)
If keys are compromised or an external authority expires them, key changes

will be needed. Application polices or emergency needs will force application
administrators to rotate keys and potentially rekey data at some point. It's best
to be prepared to rapidly handle this need when necessary. Including a key
version and encryption algorithm version with the encrypted data is a useful,
proactive feature. For instance, including a simple prefix string, such as
"{1,1}...", prior to the encrypted data could indicate algorithm version 1, key
version 1. This allows for an "online" change to the encryption algorithm and
key without re-encrypting all existing data all at once.
Access to the keys must be restricted to the smallest amount of users

possible. This group of users will ideally be users who are highly trusted and
trained to perform Key Custodian duties. There will obviously be a
requirement for system/service accounts to access the key data to perform
encryption/decryption of data.
The organization should have a complete understanding of how to securely

store, transmit and update the keys without disclosing them to an
unauthorized entity.
The organization must generate strong keys so that the security of the data
isn't undermined by weak cryptographic keys. A strong key is generated by
using a key length which is sufficient for your data security requirements and
compliant with the PCI DSS. The key size alone isn't a measure of the strength
of a key. The data used to generate the key must be sufficiently random
("sufficient" often being determined by your data security requirements) and
the entropy of the key data itself must be high.
The method used to distribute keys must be secure to prevent the theft of
keys in transit. The use of a protocol such as Diffie Hellman can help secure
the distribution of keys, the use of secure transport such as TLS and SSHv2 can
also secure the keys in transit. Older protocols like SSLv3 should not be used.
Configure key management software to store the merchant key (in encrypted
format) in an external file. Specify a key encryption key in a separate file,
which is used to encrypt the merchant key. Each file should be protected with
file system protection.
The PCI DSS standard mandates that keys used for encryption must be rotated
at least annually. The key rotation process must remove an old key from the
encryption/decryption process and replace it with a new key. All new data
entering the system must encrypted with the new key. While it is
recommended that existing data be rekeyed with the new key, as per the
rekey data at least every one to three years rule above, it is not clear that the
PCI DSS requires this.
The key management processes must cater for archived, retired or

compromised keys. 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.
The requirement for split knowledge and/or dual control for key management
prevents an individual user performing key management tasks such as key
rotation or deletion. The system should require two individual users to
perform an action (i.e. entering a value from their own OTP) which creates to
separate values which are concatenated two create the final key data.
The system put in place to comply with requirement 3.6.6 can go a long way to
preventing unauthorized substitution of key data. In addition to the dual
control process you should implement strong access control, auditing and
logging for key data so that unauthorized access attempts are prevented and
logged.
To perform the strong key management functions we have seen in
requirement 3.6 we must have highly trusted and trained key custodians who
understand how to perform key management duties. The key custodians must
also sign a form stating they understand the responsibilities that come with
this role.
0
#N/A
0
0
0
0
0
0
0
0
0
0
The sys admin or integrator would be responsible for ensuring admin access is
privileged access requiring MFA, and utilizes strong encryption algorithms. On
Windows systems, a reviews of Services will inform us if insecure remote-login
services such as Telnet or prohibited
It is important to keep in mind that some of the authentication protocols such

as TLS 1.0, SSL v2.0 and SSH v1.0 have vulnerabilities known to hackers and
can easily be exploited by them for getting information access or even
diverting the information flowing across a network. Hence, to prevent this
exploitation, protocols should be configured with their secure versions only.
The organization can gauge the efectiveness of this control by reviewing the
wireless access point configuration with an administrator and confirming that
weak encryption schemes are not in use
#N/A
#N/A
User access controls are in place and used by the appropriate user
administrators so that each user ID is uniquely assigned to an individual user.
No "generic" user IDs are created or permitted by policy
▪ Length
▪ Not reused
▪ Not matching ID
▪ Non-repeating

#N/A
#N/A
0
#N/A
#N/A
software.

Control Implementation
0
0
#N/A
0
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
0
0
0
0
0
0
0
0
0
0
#N/A
#N/A
#N/A

protect the asset

No password configuration checks failed
Atos resource working at multiple client engagements will have unique

passwords and pass phrases for each site with no re-use or duplication.
#N/A
0
0
0
0
0
0
0
0
#N/A

#N/A
#N/A
These configuration standards must meet some hardening standards such as

those from SANS or NIST. The Center for Internet Security is the primary
recognized industry-standard for secure configuration guidance, developing
comprehensive, consensus-derived checklists to help identify and mitigate
known security vulnerabilities across a wide range of platforms. CIS
benchmarks provide prescriptive guidance for establishing a secure
configuration posture for your IT Infrastructure, including a detailed
description and rationale of potential vulnerabilities together with clear
auditing and remediation steps. As such, the CIS benchmarks are the
overwhelming option of choice for auditors worldwide.

protect the asset
Provide periodic reviews to ensure that public-facing web applications are
secured via manual or automated application vulnerability security
assessment tools or methods, at least annually and after any changes.
An automated technical solution is in place 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.

protect the asset


#N/A

#N/A
#N/A
#N/A
In order to be assured that anti-virus is installed and protecting the endpoint
or host, a screenshot will suffice as an artifact. This artifact should depict that
the endpoint has the most up to date DAT file.
In order to be assured that anti-virus is installed and protecting the endpoint
or host, a screenshot will suffice as an artifact. This artifact should depict that
the endpoint has the most up to date DAT file.
For systems with distinct operating systems, a formal testing plan should exist
to ensure these systems exude no signs of compromise (vulnerability scans,
internal pentest, etc.)
This capability can either be reviewed in the vendors documentation regarding

their product, or selectively. enabled. The organization can confirm the
existence of a HIDS solution by looking within installed programs on the
endpoint, or reviewing the logs feeding into a SIEM
0
#N/A
0
0
0
0
0
0
0
0
0
0
Most wireless access points on the market today do not ship with default
encryption keys that need to be changed upon arrival. An encryption
algorithm such as WPA2/AES or TKIP should be an option for its configuration.
It's usage is strongly encouraged

Users are familiar with and trained on policy and process related to password
security. Users can locate the appropriate published references.

▪ Shared user IDs do not exist for system administration and other critical
functions.
components.
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
0
0
#N/A
#N/A
#N/A
#N/A
#N/A
All physical user access to the CDE is monitored, recorded, logged, saved and
retrievable for no less than 3 months.
#N/A
#N/A
#N/A
#N/A
#N/A
0
0
#N/A
#N/A
0
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
1 user = 1 User ID

#N/A
#N/A
0
#N/A
0
Strict policies and procedures should be implemented and should ensure the
following:
Keys are only access by the fewest possible individuals

Key-encrypting keys are as strong as the data encrypting keys
Key-encrypting keys and data encrypting keys are stored in separate locations
Keys are stored in fewest possible locations
The efectiveness of this control can be measured by maintaining current

documentation of the cryptographic architecture in a protected space within
the organization
The efectiveness of this control can be measured by reviewing policy around

how encryption keys are maintained as well as the key vault itself
The efectiveness of this control can be measured by reviewing policy

addressing all eight (8) applicable sub-requirements to this control
The efectiveness of this control can be measured by reviewing conducting

internal pen testing to determine if the key is weak. A review of the algorithm
being used will also be beneficial
The efectiveness of this control can be measured by reviewing the key vault
distribution setting to conclude that a secure protocol is being used
The efectiveness of this control can be measured by reviewing the key

management system settings and configuration




The efectiveness of this control can be measured by reviewing the forms
signed by the custodians
0
#N/A
0
0
0
0
0
0
0
0
0
0
The system administrator or integrator would be responsible for ensuring

admin access is privileged access requiring MFA, and utilizes strong encryption
algorithms. On Windows systems, a reviews of Services will inform us if
insecure remote-login services such as Telnet or prohibited
To meet the requirements of the PCI-DSS, you must disable weak keys and
protocol implementations (such as SSL v2.0, SSL v3.0, SSH v1.0 and TLS 1.0)
that have known vulnerabilities. These encryption types are considered too
weak for PCI-DSS compliance. Instead, you should use stronger
implementations like TLS 1.1 or higher
The use of WEP and any other algorithm proven to be inefective as a security
control must be prohibited within wireless networks
#N/A
#N/A
1 user = 1 User ID

#N/A
#N/A
0
#N/A
#N/A
Effectiveness of Control
0
0
#N/A
0
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
0
0
0
0
0
0
0
0
0
0
#N/A
#N/A
#N/A
Running a report from any of these CM tools will produce an artifact that
should satisfy this requirement. A review of the organization's SOP or asset
baseline manual should also exude compliance
As an artifact to exude compliance for this control, a screenshot of the failed

login attempt or a screenshot of a configuration setting depicting an implicit
deny all setting should suffice.
The SOP can be either electronic or physical. Fir compliance purposes, the
section speaking to role-based access, least privileges, and need to know can
simply be provided to the auditor for review
User profile report that indicates that the password complies with the policy
Smart Card / Token issuance logs indicating issue date / return date / user /
manager / etc.
Biometric setup and last update information
Atos policy documentation and personnel interview results.
#N/A
0
0
0
0
0
0
0
0
#N/A
manager / etc.

#N/A
#N/A
A CIS report template can serve as an artifact for compliance, as well as a

recent vulnerability scan report showing that the system is hardened per the
specification of the benchmark
Audit results, actions items and follow up activities are documented and
stored for later reference and review.


The SOP can be either electronic or physical. Fir compliance purposes, the
section speaking to role-based access, least privileges, and need to know can
simply be provided to the auditor for review
manager / etc.
#N/A
manager / etc.
#N/A
#N/A
#N/A
Compliance to this requirement should be achieved by taking a sample of
system components and verifying that an updated version of antivirus is
deployed and fully functional. The Network Access Control (NAC) mechanism
can also help to verify that all individual systems have latest patches applied to
them
To achieve compliance, the following measures need to be taken:
▪ Check up the policies and procedures of the organization to make sure that
they mention the need of updated antivirus software and confirm that it is
applied according to the policies and procedures.
▪ Inspect the anti-virus configuration to verify that anti-virus scans are set to
start H70automatically after certain time periods and are on auto-update
mode.
▪ Verify by checking the anti-virus configuration, that H69log generation of
anti-virus is enabled and are in compliance with requirement 10.7
To achieve compliance, the following measures need to be taken:
▪ Check up the policies and procedures of the organization to make sure that
they mention the need of updated antivirus software and confirm that it is
applied according to the policies and procedures.
▪ Inspect the anti-virus configuration to verify that anti-virus scans are set to
start automatically after certain time periods and are on auto-update mode.
▪ Verify by checking the anti-virus configuration, that log generation of anti-
virus is enabled and are in compliance with requirement 10.7
0
#N/A
0
0
0
0
0
0
0
0
0
0
A running config pulled from the WAP should suffice as an artifact during an
audit

Training Documents
Training system reports
Document repository or library locations.
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
0
0
#N/A
#N/A
#N/A
#N/A
#N/A
Video and access logs including date time stamps are retrievable for the
specified timeframe.
#N/A
#N/A
#N/A
#N/A
#N/A
0
0
#N/A
#N/A
0
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
To verify that no data from magnetic stripe, verification code and Personal
Identification Number is stored even after authorization, examine all data
sources such as incoming and outgoing transaction details, logs, history files,
trace files, database contents, etc.
System User Reports listing the appropriate data to show any instances of
User IDs that are generic in nature or are accessed by more than 1 user
simultaneously.
manager / etc.
#N/A
#N/A
0

#N/A
0
Key Vault Review
Admin Interview
Policy Audit
Key Vault Review

Admin Interview
Policy Audit
Key Vault Review

Admin Interview
Policy Audit
Policy Audit
Internal Pen Test Results

Key Vault Review
Policy Audit
Admin Interview
Key Vault Review
Policy Audit
Admin Interview
Key Vault Review
Policy Audit
Admin Interview
Key Vault Review
Policy Audit
Admin Interview
Key Vault Review
Policy Audit
Admin Interview
Key Vault Review
Policy Audit
Admin Interview
Key Vault Review
Policy Audit
Admin Interview
Key Vault Review
Policy Audit
0
#N/A
0
0
0
0
0
0
0
0
0
0
An interview with the sys admin, as well as watching how he/she

authenticates remotely to any system will help to ensure compliance. The
review of a custom scan using a CM tool targeting running services able to be
accessed remotely will also suffice as an artifact
To carry out a compliance check, all locations of cardholder data transmittal

over public networks should be identified. The actual applied system
configuration setting should then be checked against the documented
procedures to ensure that they are actually being put into practice. The
processes should be verified for recognition of trusted certificates and/or
keys, use of secure version of protocol and a strong encryption methodology.
Verification should be done by selecting a sample of data transmission and
identifying whether strong cryptography is applied on the data during transit
or not, protocol with secured version is being used and only trusted keys are
accepted. For strong cryptography, verify that the wireless networks
transmitting the cardholder data use industry best practices for encryption,
such as IEEE 802.11
Admin Interview
Policy Audit
#N/A
#N/A
To verify that no data from magnetic stripe, verification code and Personal
Identification Number is stored even after authorization, examine all data
sources such as incoming and outgoing transaction details, logs, history files,
trace files, database contents, etc.
System User Reports listing the appropriate data to show any instances of
User IDs that are generic in nature or are accessed by more than 1 user
simultaneously.
manager / etc.

#N/A
#N/A
0
#N/A
#N/A
such as IEEE 802.11
Admin Interview
Policy Audit

such as IEEE 802.11
Admin Interview
Policy Audit
Hardware Configuration
Physical Security
Other Documentation

NIST Requirements

Diunggah oleh

Informasi Dokumen

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

NIST Requirements

Diunggah oleh

Hak Cipta:

Format Tersedia

Function Category

Asset Management (ID.AM): The data, personnel, devices, systems,

Business Environment (ID.BE): The organization’s mission,

Risk Assessment (ID.RA): The organization understands the

Access Control (PR.AC): Access to assets and associated facilities is

Awareness and Training (PR.AT): The organization’s personnel and

Data Security (PR.DS): Information and records (data) are managed

Information Protection Processes and Procedures (PR.IP): Security

Maintenance (PR.MA): Maintenance and repairs of industrial control

Protective Technology (PR.PT): Technical security solutions are

Anomalies and Events (DE.AE): Anomalous activity is detected in a

Security Continuous Monitoring (DE.CM): The information system

Detection Processes (DE.DP): Detection processes and procedures are

Response Planning (RS.RP): Response processes and procedures are

Communications (RS.CO): Response activities are coordinated with

Mitigation (RS.MI): Activities are performed to prevent expansion of

Improvements (RS.IM): Organizational response activities are

Recovery Planning (RC.RP): Recovery processes and procedures are

Improvements (RC.IM): Recovery planning and processes are

Communications (RC.CO): Restoration activities are coordinated with

Communications (RC.CO): Restoration activities are coordinated with

ID.AM-2: Software platforms and applications within the organization are

ID.BE-3: Priorities for organizational mission, objectives, and activities are

ID.GV-3: Legal and regulatory requirements regarding cybersecurity, including

ID.GV-4: Governance and risk management processes address cybersecurity risks

ID.RA-1: Asset vulnerabilities are identified and documented

ID.RA-2: Threat and vulnerability information is received from information sharing

ID.RA-6: Risk responses are identified and prioritized

ID.RM-2: Organizational risk tolerance is determined and clearly expressed

PR.AC-2: Physical access to assets is managed and protected

PR.AC-5: Network integrity is protected, incorporating network segregation where

PR.AT-1: All users are informed and trained

PR.AT-2: Privileged users understand roles & responsibilities

PR.AT-5: Physical and information security personnel understand roles &

PR.DS-4: Adequate capacity to ensure availability is maintained

PR.IP-3: Configuration change control processes are in place

PR.IP-7: Protection processes are continuously improved

PR.IP-8: Effectiveness of protection technologies is shared with appropriate parties

PR.IP-11: Cybersecurity is included in human resources practices (e.g.,

DE.AE-4: Impact of events is determined

DE.CM-2: The physical environment is monitored to detect potential cybersecurity

DE.CM-4: Malicious code is detected

DE.CM-8: Vulnerability scans are performed

DE.DP-2: Detection activities comply with all applicable requirements

DE.DP-4: Event detection information is communicated to appropriate parties

RS.RP-1: Response plan is executed during or after an event

RS.CO-2: Events are reported consistent with established criteria

RS.CO-4: Coordination with stakeholders occurs consistent with response plans

RS.AN-2: The impact of the incident is understood

RC.RP-1: Recovery plan is executed during or after an event

RC.IM-1: Recovery plans incorporate lessons learned

RC.CO-1: Public relations are managed

CM-8 A.8.1.1, A.8.1.2 CM-8

CM-8 A.8.1.1, A.8.1.3 CM-8

AC-4, CA-3, CA-9, PL-8 A.13.2.1 AC-4, CA-3, CA-9, PL-8

CP-2, PS-7, PM-11 A.6.1.1 CP-2, PS-7, PM-11

CP-2, SA-12 A.15.1.3, A.15.2.1, A.15.2.2 CP-2, SA-12

PM-8 Gap PM-8

PM-11, SA-14 Gap PM-11, SA-14

Controls from each family A.5.1.1 Controls from each family

Controls from each family A.18.1 Controls from each family

PM-9, PM-11 Gap PM-9, PM-11

PM-15, PM-16, SI-5 A.6.1.4 PM-15, PM-16, SI-5

RA-3, SI-5, PM-12, PM-16 Gap RA-3, SI-5, PM-12, PM-16