AWS Enterprise Accelerator - Compliance: Quick Start

Standardized Architecture for PCI-DSS on the AWS Cloud

Security Requirements Reference, v1.2, December 1, 2016

This document describes the PCI-DSS v3.2 Security Requirements that are directly addressed by th
those for which there is an inheritance of security features from the AWS-managed products and s
the Description of AWS Implementation details and Additional Guidance in this document are no
evaluated, assessed, and approved by the customer organization, and layered with other security
scope systems and applications for a holistic solution to meet overall security requirements.

PCI DSS Requirements v3.2 Milestone Applicable in AWS Reference

Architecture

Requirement 1: Install and maintain a firewall configuration to protect cardholder data

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 6 N
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 Y

1.1.3 Current diagram that shows all cardholder data

flows across systems and networks. 1 Y
1.1.4 Requirements for a firewall at each Internet
connection and between any demilitarized zone (DMZ)
and the Internal network zone
2 Y

1.1.5 Description of groups, roles, and responsibilities

for management of network components.
6 Y

1.1.6 Documentation of business

justification and approval for use of all
services, protocols, and ports allowed,
including documentation of security 2 N
features implemented for those
protocols considered to be insecure.
1.1.7 Requirement to review firewall and router rule
sets at least every six months. 6 N
1.2 Build firewall and router configurations that restrict
connections between untrusted networks and any
system components in the cardholder data
environment.

Note: An “untrusted network” is any network that is

external to the networks belonging to the entity under
review, and/or which is out of the entity's ability to
control or manage.

1.2.1 Restrict inbound and outbound traffic to that

which is necessary for the cardholder data
environment, and specifically deny all other traffic.
2 Y

1.2.2 Secure and synchronize router configuration files.

2 Y

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 2 N
purposes, permit only authorized traffic
between the wireless environment and
the cardholder data environment.

1.3 Prohibit direct public access between the Internet

and any system component in the cardholder data
environment.
1.3.1 Implement a DMZ to limit inbound traffic to only
system components that provide authorized publicly
accessible services, protocols, and ports.

2 Y
1.3.2 Limit inbound Internet traffic to IP addresses
within the DMZ.

2 Y

1.3.3 Implement anti-spoofing measures to detect and

block forged source IP addresses from entering the
network.
2 Y
(For example, block traffic originating from the Internet
with an internal source address.)

1.3.4 Do not allow unauthorized outbound traffic from

the cardholder data environment to the Internet.

2 Y

1.3.5 Permit only “established” connections into the

network. 2 Y
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.
2 Y

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 or content caches, 2 Y
• Removal or filtering of route advertisements for
private networks that employ registered addressing,
• Internal use of RFC1918 address space instead of
registered addresses.
1.4 Install personal firewall software 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. 2 N
• 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 Ensure that security policies and operational

procedures for managing firewalls are documented, in 2 N
use, and known to all affected parties

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 2 N
that provides security services, application and system
accounts, point-of-sale (POS) terminals, Simple
Network Management Protocol (SNMP) community
strings, etc.)

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 2 N
limited to default wireless encryption
keys, passwords, and SNMP
community strings.

2.2 Develop configuration standards for all system

components. Assure that these standards address all
known security vulnerabilities and are consistent with
industry-accepted system hardening standards.
Sources of industry-accepted system hardening
standards may include, but are not limited to: 3 with changes
• Center for Internet Security (CIS)
• International Organization for Standardization (ISO)
• SysAdmin Audit Network Security (SANS) Institute
• National Institute of Standards Technology (NIST)
2.2.1 Implement only one primary function per server
to prevent functions that require different security levels
from co-existing on the same server. (For example,
web servers, database servers, and DNS should be
implemented on separate servers.)
3 Y
Note: Where virtualization technologies are in use,
implement only one primary function per virtual system
component.

2.2.2 Enable only necessary services, protocols,

daemons, etc., as required for the function of the 3 N
system.
2.2.3 Implement additional security features for any
required services, protocols, or daemons that are
considered to be insecure.

Note: Where SSL/early TLS is used, the requirements 3 Y

in Appendix A2 must be completed.

2.2.4 Configure system security parameters to prevent

misuse.
3 Y

2.2.5 Remove all unnecessary functionality, such as

scripts, drivers, features, subsystems, file systems, and 3 N/A
unnecessary web servers.
2.3 Encrypt all non-console administrative access using
strong cryptography.

Note: Where SSL/early TLS is used, the 2 Y

requirements in Appendix A2 must be
completed.

2.4 Maintain an inventory of system components that

are in scope for PCI DSS.
2 Y

2.5 Ensure that security policies and operational

procedures for managing vendor defaults and other
security parameters are documented, in use, and 2 N
known to all affected parties
2.6 Shared hosting providers must protect each entity’s
hosted environment and cardholder data. These
providers must meet specific requirements as detailed N
3
in Appendix A1: Additional PCI DSS Requirements for
Shared Hosting Providers.

Requirement 3: Protect stored 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/or
business requirements
• Specific retention requirements for cardholder data 1 N
• 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.

3.2 Do not store sensitive authentication data after

authorization (even if encrypted). If sensitive
authentication data is received, render all data
irretrievable 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 1 N
• The data is stored securely.
Sensitive authentication data includes the data as cited
in the following Requirements 3.2.1 through 3.2.3:

3.2.1 Do not store the full contents of any track (from

the magnetic stripe located on the back of a card,
equivalent data contained on a chip, or elsewhere) after
authorization. This data is alternatively called full track,
track, track 1, track 2, and magnetic-stripe data.

Note: In the normal course of business, the following

data elements from the magnetic stripe may need to be
retained:
• The cardholder’s name 1 N
• 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 1 N
transactions) after authorization.
3.2.3 Do not store the personal identification number
(PIN) or the encrypted PIN block after authorization. 1 N
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.
5 N
Note: This requirement does not supersede stricter
requirements in place for displays of cardholder data—
for example, legal or payment card brand requirements
for point-of-sale (POS) receipts.

3.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.
5 N
Note: It is a relatively trivial effort for a malicious
individual to reconstruct original PAN data if they have
access to both the truncated and hashed version of a
PAN. Where hashed and truncated versions of the
same PAN are present in an entity’s environment,
additional controls must be in place to ensure that the
hashed and truncated versions cannot be correlated to
reconstruct the original PAN.

3.4.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. 5 N

Note: This requirement applies in addition to all other

PCI DSS encryption and key-management
requirements.

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 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 5 N
management

Note: This requirement is a best practice until January

31, 2018, after which it becomes a requirement.

3.5.2 Restrict access to cryptographic keys to the

fewest number of custodians necessary. 5 N
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) 5 N
• 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.

3.5.4 Store cryptographic keys in the fewest possible

locations. 5 N
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 Generation of strong cryptographic keys 5 N

3.6.2 Secure cryptographic key distribution. 5 N
3.6.3 Secure cryptographic key storage. 5 N
3.6.4 Cryptographic key changes for keys that have
reached the end of their crypto period (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 5 N
vendor or key owner, and based on industry best
practices and guidelines (for example, NIST Special
Publication 800-57).
3.6.5 Retirement or replacement (for example,
archiving, destruction, and/or revocation) of keys as
deemed necessary when the integrity of the key has
been weakened (for example, departure of an
employee with knowledge of a clear-text key
component), or keys are suspected of being
compromised.
5 N
Note: If retired or replaced cryptographic keys need to
be retained, these keys must be securely archived (for
example, by using a key encryption key). Archived
cryptographic keys should only be used for
decryption/verification purposes.

3.6.6 If manual clear-text cryptographic key-

management operations are used, these operations
must be managed using split knowledge and dual
control.

Note: Examples of manual key management 5 N

operations include, but are not limited to: key
generation, transmission, loading, storage and
destruction.

3.6.7 Prevention of unauthorized substitution of

cryptographic keys. 5 N
3.6.8 Requirement for cryptographic key custodians to
formally acknowledge that they understand and accept 5 N
their key-custodian responsibilities.
3.7 Ensure that security policies and operational
procedures for protecting stored cardholder data are
documented, in use, and known to all affected parties. 5 N

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 Appendix A2 must be completed. Examples of open,
public networks include but are not limited to:
• The Internet 2 Y
• Wireless technologies, including 802.11 and Bluetooth
• Cellular technologies, for example, Global System for
Mobile communications (GSM), Code division multiple
access (CDMA)
• General Packet Radio Service (GPRS)
• Satellite communications

4.1.1 Ensure wireless networks transmitting cardholder

data or connected to the cardholder data environment,
use industry best practices to implement strong 2 N
encryption for authentication and transmission.

4.2 Never send unprotected PANs by enduser

messaging technologies (for example, email, instant 2 N
messaging, SMS, chat, etc.).
4.3 Ensure that security policies and operational
procedures for encrypting transmissions of cardholder
data are documented, in use, and known to all affected 2 N
parties.

Requirement 5: Protect all systems against malware and regularly update anti-virus software or programs

5.1 Deploy anti-virus software on all systems commonly

affected by malicious software (particularly personal 2 N
computers and servers).
5.1.1 Ensure that all anti-virus programs are capable of
detecting, removing, and protecting against all known 2 N
types of malicious software.
5.1.2 For systems considered to be not commonly
affected by malicious software, perform periodic
evaluations to identify and evaluate evolving malware
threats in order to confirm 2 N
whether such systems continue to not require anti-virus
software.
5.2  Ensure that all anti-virus mechanisms are
maintained as follows:
• Are kept current,
• Perform periodic scans 2 N
• Generate audit logs which are retained per PCI DSS
Requirement 10.7

5.3 Ensure that anti-virus mechanisms are actively

running and cannot be disabled or altered by users,
unless specifically authorized by management on a
case-by-case basis for a limited time period.

Note: Anti-virus solutions may be temporarily disabled

only if there is legitimate technical need, as authorized
by management on a case-by-case basis. If anti-virus 2 N
protection needs to be disabled for a specific purpose,
it must be formally authorized. Additional security
measures may also need to be implemented for the
period of time during which anti-virus protection is not
active.

5.4 Ensure that security policies and operational

procedures for protecting systems against malware are
documented, in use, and known to all affected parties. 2 N

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 3 N
rankings should, at a minimum, identify all
vulnerabilities considered to be a “high risk” to the
environment. In addition to the risk ranking,
vulnerabilities may be considered “critical” if they pose
an imminent threat to the environment, impact critical
systems, and/or would result in a potential compromise
if not addressed. Examples of critical systems may
include security systems, public-facing devices and
systems, databases, and other systems that store,
process, or transmit cardholder data.
6.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.
3 N
Note: Critical security patches should be identified
according to the risk ranking process defined in
Requirement 6.1.

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

Note: this applies to all software developed internally

as well as bespoke or custom software developed by a
third party.

6.3.1 Remove development, test and/or custom

application accounts, user IDs, and passwords before
applications become active or are released to 3 N
customers.
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
3 N
Note: This requirement for code reviews applies to all
custom code (both internal and public-facing), as part of
the system development life cycle. Code reviews can
be conducted by knowledgeable internal personnel or
third parties. Public-facing web applications are also
subject to additional controls, to address ongoing
threats and vulnerabilities after implementation, as
defined at PCI DSS Requirement 6.6.

6.4 Follow change control processes and procedures

for all changes to system components. The processes 3 N
must include the following:
6.4.1 Separate development/test environments from
production environments, and enforce the separation
with access controls.

3 with changes

6.4.2 Separation of duties between development/test

and production environment.

3 with changes

6.4.3 Production data (live PANs) are not used for

testing or development. 3 N
6.4.4 Removal of test data and accounts from system
components before the system becomes active / goes 3 N
into production.
6.4.5 Change control procedures must include the
following: 6 N
6.4.5.1 Documentation of impact. 6 N
6.4.5.2 Documented change approval by authorized
parties. 6 N
6.4.5.3 Functionality testing to verify that the change
does not adversely impact the security of the system. 6 N

6.4.5.4 Back-out procedures. 6 N

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.
6 N
Note: This requirement is a best practice until January
31, 2018, after which it becomes a requirement.
6.5 Address common coding vulnerabilities in software-
development processes as follows:
• Train developers at least annually in up-to-date
secure coding techniques, including how to avoid
common coding vulnerabilities.
• Develop applications based on secure coding
guidelines.

Note: The vulnerabilities listed at 6.5.1 through 6.5.10 3 N

were current with industry best practices when this
version of PCI DSS was published. However, as
industry best practices for vulnerability management
are updated (for example, the OWASP Guide, SANS
CWE Top 25, CERT Secure Coding, etc.), the current
best practices must be used for these requirements.

6.5.1 Injection flaws, particularly SQL injection. Also

consider OS Command Injection, LDAP and XpPath 3 N
injection flaws as well as other injection flaws.
6.5.2 Buffer overflows. 3 N
6.5.3 Insecure cryptographic storage. 3 N
6.5.4 Insecure communications. 3 N
6.5.5 Improper error handling. 3 N
6.5.6 All “high risk” vulnerabilities identified in the
vulnerability identification process (as defined in PCI 3 N
DSS Requirement 6.1).

Note: Requirements 6.5.7 through 6.5.9, below, apply to web applications and application interfaces (internal or external):

6.5.7 Cross-site scripting (XSS). 3 N

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 3 N
functions).
6.5.9 Cross-site request forgery (CRSF). 3 N
6.5.10 Broken authentication and session
management. 3 N
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 3 with changes

vulnerability scans performed for Requirement 11.2.

• Installing an automated technical solution that detects

and prevents web based attacks (for example, a web
application firewall) in front of public facing web
applications, to continually check all traffic.

6.7 Ensure that security policies and operational

procedures for developing and maintaining secure
systems and applications are documented, in use, and 3 N
known to all affected parties.

Requirement 7: Restrict access to cardholder data by business need to know

7.1 Limit access to system components and cardholder

data to only those individuals whose job requires such
access.
7.1.1 Define access needs for each role, including:
• System components and data resources that each
role needs to access for their job function
• Level of privilege required (for example, user, 4 Y
administrator, etc.) for accessing resources

7.1.2 Restrict access to privileged user IDs to least

privileges necessary to perform job responsibilities.
4 Y

7.1.3 Assign access based on individual personnel’s

job classification and function 4 N
7.1.4 Require documented approval by authorized
parties specifying required privileges. 4 N
7.2 Establish an access control system(s) for systems
components that restricts access based on a user’s
need to know, and is set to “deny all” unless specifically
allowed. This access control system(s) must include the
following:
7.2.1 Coverage of all system components.

4 Y

7.2.2 Assignment of privileges to individuals based on

job classification and function. 4 N
7.2.3 Default “deny-all” setting.
4 Y

7.3 Ensure that security policies and operational

procedures for restricting access to cardholder data are
documented, in use, and known to all affected parties. 4 N

Requirement 8: Identify and authenticate access to system components

8.1 Define and implement policies and procedures to
ensure proper user identification management for
nonconsumer users and administrators on all system
components as follows:
8.1.1 Assign all users a unique ID before allowing them
to access system components or cardholder data.

4 N

8.1.2 Control addition, deletion, and modification of

user IDs, credentials, and other identifier objects.

4 N

8.1.3 Immediately revoke access for any terminated

users.

4 N

8.1.4 Remove/disable inactive user accounts within 90

days.

4 N
8.1.5 Manage IDs used by third parties to access,
support, or maintain system components via remote
access as follows:
• Enabled only during the time period needed and 4 N
disabled when not in use.
• Monitored when in use.

8.1.6 Limit repeated access attempts by locking out the

user ID after not more than six attempts.

4 N

8.1.7 Set the lockout duration to a minimum of 30

minutes or until an administrator enables the user ID.

4 N

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

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 4 N
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 credentials (such as passwords/phrases)
unreadable during transmission and storage on all 4 Y
system component.
8.2.2 Verify user identity before modifying any
authentication credential—for example, performing
password resets, provisioning new tokens, or
generating new keys. 4 N

8.2.3 Passwords/phrases must meet the following:

• Require a minimum length of at least seven
characters.
• Contain both numeric and alphabetic characters.
4 with changes
Alternatively, the passwords/phrases must have
complexity and strength at least equivalent to the
parameters specified above.
8.2.4 Change user passwords/passphrases at least
every 90 days.
4 with changes

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. 4 with changes

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. 4 with changes

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 2 with changes
twice (for example, using two separate passwords) is
not considered multi-factor authentication.

8.3.1 Incorporate multi-factor authentication for all non-

console access into the CDE for personnel with
administrative access.

Note: This requirement is a best practice until January 2 with changes

31, 2018, after which it becomes a requirement.

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 from outside the entity’s 2 with changes
network.

8.4 Document and communicate authentication policies

and procedures to all users including:
• Guidance on selecting strong authentication
credentials
• Guidance for how users should protect their 4 N
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 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. 4 Y
• Shared and generic user IDs are not used to
administer any system components

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

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

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

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. 4 Y
• Only database administrators have the ability to
directly access or query databases.
• Application IDs for database applications can only be
used by the applications (and not by individual users or
other non-application processes)

8.8 Ensure that security policies and operational

procedures for identification and authentication are
documented, in use, and known to all affected parties. 4 N

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 2 N
data environment.
9.1.1 Use either video cameras or access control
mechanisms (or both) 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 2 N
store, process, or transmit cardholder data. This
excludes public-facing areas where only point-of-sale
terminals are present, such as the cashier areas in a
retail store.

9.1.2 Implement physical and/or logical controls to

restrict access to publicly accessible network jacks.

For example, network jacks located in public areas and

areas accessible to visitors could be disabled and only
enabled when network access is explicitly authorized. 2 N
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 2 N
telecommunications lines.

9.2 Develop procedures to easily distinguish between

onsite personnel and visitors, to include:
• Identifying onsite personnel and visitors (for example,
assigning badges) 5 N
• 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 areas as follows:
• Access must be authorized and based on individual
job function.
• Access is revoked immediately upon termination, and 2 N
all physical access mechanisms, such as keys, access
cards, etc., are returned or disabled

9.4 Implement procedures to identify and authorize

visitors.
Procedures should include the following:
9.4.1 Visitors are authorized before entering, and
escorted at all times within, areas where cardholder 5 N
data is processed or maintained.
9.4.2 Visitors are identified and given a badge or other
identification that expires and that visibly 5 N
distinguishesthe visitors from onsite personnel.
9.4.3 Visitors are asked to surrender the badge or
identification before leaving the facility or at the date of 5 N
expiration.
9.4.4 A visitor log is used to maintain a physical audit
trail of visitor activity to the facility as well as computer
rooms and data centers where cardholder data is
stored or transmitted. Document the visitor’s name,
the firm represented, and the onsite personnel 5 N
authorizing physical access on the log. Retain this log
for a minimum of three months, unless otherwise
restricted by law.

9.5 Physically secure all media. 5 N

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 5 N
the location’s security at least annually.
9.6 Maintain strict control over the internal or external
distribution of any kind of media, including the following:

9.6.1 Classify media so the sensitivity of the data can

be determined. 5 N
9.6.2 Send the media by secured courier or other
delivery method that can be accurately tracked. 5 N
9.6.3 Ensure management approves any and all media
that is moved from a secured area (including when 5 N
media is distributed to individuals).
9.7 Maintain strict control over the storage and
accessibility of media.
9.7.1 Properly maintain inventory logs of all media and
conduct media inventories at least annually. 5 N
9.8 Destroy media when it is no longer needed for
business or legal reasons as follows:

9.8.1 Shred, incinerate, or pulp hardcopy materials so

that cardholder data cannot be reconstructed. Secure
storage containers used for materials that are to be 1 N
destroyed.
9.8.2 Render cardholder data on electronic media
unrecoverable so that cardholder data cannot be 1 N
reconstructed.
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.
9.9.1 Maintain an up-to-date list of devices. The list
should include the following:

• Make, model of device

• Location of device (for example, the address of the 2 N
site or facility where the device is located)
• Device serial number or other method of unique
identification

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 2 N
attachments or cables plugged into the device, missing
or changed security labels, broken or differently colored
casing, or changes to the serial number or other
external markings.

9.9.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 2 N
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)

9.10 Ensure that security policies and operational

procedures for restricting physical access to cardholder
data are documented, in use, and known to all affected 5 N
parties.

Requirement 10: Track and monitor all access to network resources and cardholder data

10.1 Implement audit trails to link all access to system

components to each individual user.
4 Y

10.2 Implement automated audit trails for all system

components to reconstruct the following events:
10.2.1 All individual user accesses to cardholder data.
4 Y
10.2.2 All actions taken by any individual with root or
administrative privileges.
4 Y

10.2.3 Access to all audit trails.

4 Y

10.2.4 Invalid logical access attempts.

4 Y

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— 4 Y
and all changes, additions, or deletions to accounts
with root or administrative privileges.

10.2.6 Initialization, stopping, or pausing of the audit

logs

4 Y

10.2.7 Creation and deletion of system level objects

4 Y

10.3 Record at least the following audit trail entries for

all system components for each event:

10.3.1 User identification. 4 Y

10.3.2 Type of event. 4 Y

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

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. 4 Y
Note: One example of time synchronization technology
is Network Time Protocol (NTP).
10.4.1 Critical systems have the correct and consistent
time.
4 Y

10.4.2 Time data is protected. 4 N

10.4.3 Time settings are received from industry-
accepted time sources.
4 Y

10.5 Secure audit trails so they cannot be altered.

10.5.1 Limit viewing of audit trails to those with a job-

related need.
4 Y

10.5.2 Protect audit trail files from unauthorized

modifications.
4 Y
10.5.3 Promptly back up audit trail files to a centralized
log server or media that is difficult to alter. 4 Y

10.5.4 Write logs for external-facing technologies onto

a secure, centralized, internal log server or media 4 Y
device.

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
4 Y
data being added should not cause an alert).

10.6 Review logs and security events for all system

components to identify anomalies or suspicious activity.

Note: Log harvesting, parsing, and alerting tools may

be used to meet this Requirement.

10.6.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 4 N
perform security functions (for example, firewalls,
intrusion-detection systems/intrusion-prevention
systems (IDS/IPS), authentication servers, e-commerce
redirection servers, etc.).

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 4 N
organization’s annual risk assessment.
10.6.3 Follow up exceptions and anomalies identified
during the review process.
4 N
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 4 Y
from backup).
10.8 Additional requirement for service providers
only: 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
• Physical access controls
• Logical access controls 4 N
• Audit logging mechanisms
• Segmentation controls (if used)

Note: This requirement is a best practice until January

31, 2018, after which it becomes a requirement.

10.8.1 Additional requirement for service providers

only: 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
• Performing a risk assessment to determine whether
further actions are required as a result of the security 4 N
failure
• Implementing controls to prevent cause of failure from
reoccurring
• Resuming monitoring of security controls

Note: This requirement is a best practice until January

31, 2018, after which it becomes a requirement.

10.9 Ensure that security policies and operational

procedures for monitoring all access to network
resources and cardholder data are documented, in use,
4 N
and known to all affected parties.

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 4 N
infrastructure, network access control (NAC), or
wireless IDS/IPS. Whichever methods are used, they
must be sufficient to detect and identify both authorized
and unauthorized devices.

11.1.1 Maintain an inventory of authorized wireless

access points including a documented business 4 N
justification.
11.1.2 Implement incident response procedures in the
event unauthorized wireless access points are 2 N
detected.
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 2 N
assessor verifies 1) the most recent scan result was a
passing scan, 2) the entity has documented policies
and procedures requiring quarterly scanning, and 3)
vulnerabilities noted in the scan results have been
corrected as shown in a re-scan(s). For subsequent
years after the initial PCI DSS review, four quarters of
passing scans must have occurred.

11.2.1 Perform quarterly internal vulnerability scans.

Address vulnerabilities and perform rescans to verify all
“high risk” vulnerabilities are resolved in accordance
with the entity’s vulnerability ranking (per Requirement 2 N
6.1). Scans must be performed by qualified personnel.
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), 2 N
approved by the Payment Card Industry Security
Standards Council (PCI SSC). Refer to the ASV
Program Guide published on the PCI SSC website for
scan customer responsibilities, scan preparation, etc.

11.2.3 Perform internal and external scans, and

rescans as needed, after any significant change. Scans 2 N
must be performed by qualified personnel.
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 2 N
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 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 2 N
environment, or a web server added to the
environment).

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 2 N
environment, or a web server added to the
environment)

11.3.3 Exploitable vulnerabilities found during

penetration testing are corrected and testing is 2 N
repeated to verify the corrections.
11.3.4 If segmentation is used to isolate the CDE from
other networks, perform penetration tests at least
annually and after any changes to segmentation
controls/methods to verify that the segmentation 2 N
methods are operational and effective, and isolate all
out-of-scope systems from systems in the CDE.

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.
2 N
Note: This requirement is a best practice until January
31, 2018, after which it becomes a requirement.

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 2 N
suspected compromises. Keep all intrusion-detection
and prevention engines, baselines, and signatures up
to date.

11.5 Deploy a change-detection mechanism (for

example, file-integrity monitoring tools) to alert
personnel to unauthorized modification of critical
system files, configuration files, or content files; and
configure the software to perform critical file
comparisons at least weekly.

Note: For 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 4 N
mechanisms such as file-integrity monitoring products
usually come preconfigured 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.
4 N
11.6 Ensure that security policies and operational
procedures for security monitoring and testing are
documented, in use, and known to all affected parties. 4 N

Requirement 12: Maintain a policy that addresses information security for all personnel

12.1 Establish, publish, maintain, and disseminate a

security policy. 6 N
12.1.1 Review the security policy at least annually and
update the policy when the environment changes. 6 N

12.2 Implement a risk-assessment process that:

• Is performed at least annually and upon significant

changes to the environment (for example, acquisition,
merger, relocation, etc.),
• Identifies critical assets, threats, and vulnerabilities,
and
• Results in a formal, documented analysis of risk. 1 N

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, tablets, removable electronic 6 N
media, email usage and Internet usage.

Ensure these usage policies require the following:

12.3.1 Explicit approval by authorized parties 6 N

12.3.2 Authentication for use of the technology. 6 N
12.3.3 A list of all such devices and personnel with
access.
6 N
12.3.4 A method to accurately and readily determine
owner, contact information, and purpose (for example,
labeling, coding, and/or inventorying of devices. 6 N

12.3.5 Acceptable uses of the technology. 6 N

12.3.6 Acceptable network locations for the
technologies.
6 N
12.3.7 List of company-approved products. 6 N
12.3.8 Automatic disconnect of sessions for remote-
access technologies after a specific period of inactivity.
6 N

12.3.9 Activation of remote-access technologies for

vendors and business partners only when needed by
vendors and business partners, with immediate 6 N
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 business need.
6 N
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 define information security responsibilities for all 6 N
personnel.
12.4.1 Additional requirement for service providers
only: Executive management shall establish
responsibility for the protection of cardholder data and a
PCI DSS compliance program to include:
• Overall accountability for maintaining PCI DSS
compliance
• Defining a charter for a PCI DSS compliance program
and communication to executive management
6 N
Note: This requirement is a best practice until January
31, 2018, after which it becomes a requirement.

12.5 Assign to an individual or team the following

information security management responsibilities:
6 N
12.5.1 Establish, document, and distribute security
policies and procedures. 6 N
12.5.2 Monitor and analyze security alerts and
information, and distribute to appropriate personnel. 6 N
12.5.3 Establish, document, and distribute security
incident response and escalation procedures to ensure 2 N
timely and effective handling of all situations.
12.5.4 Administer user accounts, including additions,
deletions, and modifications.
6 N
12.5.5 Monitor and control all access to data. 6 N
12.6 Implement a formal security awareness program
to make all personnel aware of the cardholder data 6 N
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

6 N
personnel and their level of access to the cardholder
data.
12.6.2 Require personnel to acknowledge at least
annually that they have read and understood the 6 N
security policy and procedures.
12.7 Screen potential personnel prior to hire to
minimize the risk of attacks from internal sources.
(Examples of background checks include previous
employment history, criminal record, credit history and
reference checks.)

Note: For those potential personnel to be hired for 6 N

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 could affect the security of 2 N
cardholder data, as follows:
12.8.1 Maintain a list of service providers including a
description of the service provided. 2 N
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 2 N

depend on the agreement between the two parties, the
details of the service being provided, and the
responsibilities assigned to each party. The
acknowledgement does not have to include the exact
wording provided in this requirement.

12.8.3 Ensure there is an established process for

engaging service providers including proper due 2 N
diligence prior to engagement.

12.8.4 Maintain a program to monitor service providers’

PCI DSS compliance status at least annually.
2 N

12.8.5 Maintain information about which PCI DSS

requirements are managed by each service provider, 2 N
and which are managed by the entity.
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: The exact wording of an acknowledgement will 2 N

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.10 Implement an incident response plan. Be

prepared to 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
§  Data back-up processes 2 Y
§   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 Requirement 12.10.1, at least annually. 2 N

12.10.3 Designate specific personnel to be available on

a 24/7 basis to respond to alerts. 2 N
12.10.4 Provide appropriate training to staff with
security breach response responsibilities. 2 N
12.10.5 Include alerts from security monitoring
systems, including but not limited to intrusion-detection,
intrusion-prevention, firewalls, and file-integrity 2 N
monitoring systems.
12.10.6 Develop a process to modify and evolve the
incident response plan according to lessons learned 2 N
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
• Responding to security alerts 2 N
• Change management processes

Note: This requirement is a best practice until January

31, 2018, after which it becomes a requirement.

12.11.1 Additional requirement for service

providers only: 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
2 N
Note: This requirement is a best practice until January
31, 2018, after which it becomes a requirement.

Appendix A1: 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 meet these 3 N

requirements, the compliance of the entity that uses the
hosting provider is not guaranteed. Each entity must
comply with the PCI DSS and validate compliance as
applicable.

A1.1 Ensure that each entity only runs processes that

have access to that entity’s cardholder data 3 N
environment.
A.1.2 Restrict each entity’s access and privileges to its
own cardholder data environment only. 3 N
A.1.3 Ensure logging and audit trails are enabled and
unique to each entity’s cardholder data environment 3 N
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 3 N
hosted merchant or service provider.
Appendix A2: Additional PCI DSS Requirements for Entities using SSL/early TLS

A2.1 Where POS POI terminals (and the SSL/TLS

termination points to which they connect) use SSL
and/or early TLS, the entity must either:

• Confirm the devices are not susceptible to any known

exploits for those protocols. 3 N
Or:
• Have a formal Risk Mitigation and Migration Plan in
place.

A2.2 Entities with existing implementations (other than

as allowed in A2.1) that use SSL and/or early TLS must
have a formal Risk Mitigation and Migration Plan in 3 N
place.
A2.3 Additional Requirement for Service Providers
Only: All service providers must provide a secure
service offering by June 30, 2016.

Note: Prior to June 30, 2016, the service provider must

either have a secure protocol option included in their
service offering, or have a documented Risk Mitigation
and Migration Plan (per A2.2) that includes a target 3 N
date for provision of a secure protocol option no later
than June 30, 2016. After this date, all service providers
must offer a secure protocol option for their service.

Appendix A3: Designated Entities Supplemental Validation (DESV)

A3.1 Implement a PCI DSS compliance

program

A3.1.1 Executive management shall establish

responsibility for the protection of cardholder data and a
PCI DSS compliance program to include:

• Overall accountability for maintaining PCI DSS

compliance
• Defining a charter for a PCI DSS compliance program
• Providing updates to executive management and
board of directors on PCI DSS compliance initiatives 3 N
and issues, including remediation activities, at least
annually

PCI DSS Reference: Requirement 12

A3.1.2 A formal PCI DSS compliance program must be
in place to include:

• Definition of activities for maintaining and monitoring

overall PCI DSS compliance, including business-as-
usual activities
• Annual PCI DSS assessment processes
• Processes for the continuous validation of PCI DSS
requirements (for example: daily, weekly, quarterly, etc. 3 N
as applicable per requirement)
• A process for performing business-impact analysis to
determine potential PCI DSS impacts for strategic
business decisions

PCI DSS Reference: Requirements 1-12

A3.1.3 PCI DSS compliance roles and responsibilities

must be specifically defined and formally assigned to
one or more personnel, including at least the following:

• Managing PCI DSS business-as-usual activities

• Managing annual PCI DSS assessments
• Managing continuous validation of PCI DSS
requirements (for example: daily, weekly, quarterly, etc.
as applicable per requirement) 3 N
• Managing business-impact analysis to determine
potential PCI DSS impacts for strategic business
decisions

PCI DSS Reference: Requirement 12

A3.1.4 Provide up-to-date PCI DSS and/or information

security training at least annually to personnel with PCI
DSS compliance responsibilities (as identified in
A3.1.3). 3 N
PCI DSS Reference: Requirement 12

A3.2.1 Document and confirm the accuracy of PCI DSS

scope at least quarterly and upon significant changes to
the in-scope environment. At a minimum, the quarterly
scoping validation should include:
• Identifying all in-scope networks and system
components
• Identifying all out-of-scope networks and justification
for networks being out of scope, including descriptions
of all segmentation controls implemented 3 N
• Identifying all connected entities—e.g., third-party
entities with access to the cardholder data environment
(CDE)

PCI DSS Reference: Scope of PCI DSS Requirements

A3.2.2 Determine PCI DSS scope impact for all
changes to systems or networks, including additions of
new systems and new network connections. Processes
must include:
• Performing a formal PCI DSS impact assessment
• Identifying applicable PCI DSS requirements to the
system or network
• Updating PCI DSS scope as appropriate
• Documented sign-off of the results of the impact 3 N
assessment by responsible personnel (as defined in
A3.1.3)

PCI DSS Reference: Scope of PCI DSS

Requirements; Requirements 1-12

A3.2.2.1 Upon completion of a change, all relevant PCI

DSS requirements must be verified on all new or
changed systems and networks, and documentation
must be updated as applicable. Examples of PCI DSS
requirements that should be verified include, but are not
limited to:
• Network diagram is updated to reflect changes.
• Systems are configured per configuration standards,
with all default passwords changed and unnecessary 3 N
services disabled.
• Systems are protected with required controls—e.g.,
file-integrity monitoring (FIM), anti-virus, patches, audit
logging.
• Verify that sensitive authentication data (SAD) is not
stored and that 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.

PCI DSS Reference: Scope of PCI DSS Requirements;

Requirement 1-12

A3.2.3 Changes to organizational structure— for

example, a company merger or acquisition, change or
reassignment of personnel with responsibility for
security controls—result in a formal (internal) review of 3 N
the impact to PCI DSS scope and applicability of
controls.

PCI DSS Reference: Requirement 12

A3.2.4 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. 3 N
PCI DSS Reference: Requirement 11
A3.2.5 Implement a data-discovery methodology to
confirm PCI DSS scope and to locate all sources and
locations of clear-text PAN at least quarterly and upon
significant changes to the cardholder environment or 3 N
processes. Data-discovery methodology must take into
consideration the potential for clear-text PAN to reside
on systems and networks outside of the currently
defined CDE.

PCI DSS Reference: Scope of PCI DSS Requirements

A3.2.5.1 Ensure effectiveness of methods used for data

discovery—–e.g., methods must be able to discover
clear-text PAN on all types of system components (for 3 N
example, on each operating system or platform) and file
formats in use. The effectiveness of data-discovery
methods must be confirmed at least annually.

PCI DSS Reference: Scope of PCI DSS Requirements

A3.2.5.2 Implement response procedures to be initiated

upon the detection of clear-text PAN outside of the
CDE to include:
•Procedures for determining what to do if clear-text
PAN is discovered outside of the CDE, including its
retrieval, secure deletion and/or migration into the
currently defined CDE, as applicable 3 N
• Procedures for determining how the data ended up
outside of the CDE
• Procedures for remediating data leaks or process
gaps that resulted in the data being outside of the CDE
• Procedures for identifying the source of the data
• Procedures for identifying whether any track data is
stored with the PANs

A3.2.6 Implement mechanisms for detecting and

preventing clear-text PAN from leaving the CDE via an 3 N
unauthorized channel, method, or process, including
generation of audit logs and alerts.

PCI DSS Reference: Scope of PCI DSS Requirements

A3.2.6.1 Implement response procedures to be initiated

upon the detection of attempts to remove clear-text
PAN from the CDE via an unauthorized channel,
method, or process. Response procedures must
include: 3 N
• Procedures for the timely investigation of alerts by
responsible personnel
• Procedures for remediating data leaks or process
gaps, as necessary, to prevent any data loss
A3.3 Validate PCI DSS is incorporated into business-as-usual (BAU) activities

A3.3.1 Implement a process to immediately detect and

alert on critical security control failures. Examples of
critical security controls include, but are not limited to:
• Firewalls
• IDS/IPS
• FIM
• Anti-virus 3 N
• Physical access controls
• Logical access controls
• Audit logging mechanisms
• Segmentation controls (if used)

PCI DSS Reference: Requirements 1-12

A3.3.1.1 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
• Performing a risk assessment to determine whether
further actions are required as a result of the security 3 N
failure
• Implementing controls to prevent cause of failure from
reoccurring
• Resuming monitoring of security controls

PCI DSS Reference: Requirements 1-12

A3.3.2 Review hardware and software technologies at

least annually to confirm whether they continue to meet
the organization’s PCI DSS requirements. (For
example, a review of technologies that are no longer
supported by the vendor and/or no longer meet the
security needs of the organization.)

The process includes a plan for remediating 3 N

technologies that no longer meet the organization’s PCI
DSS requirements, up to and including replacement of
the technology, as appropriate.

PCI DSS Reference: Requirements 2, 6

A3.3.3 Perform reviews at least quarterly to verify BAU
activities are being followed. Reviews must be
performed by personnel assigned to the PCI DSS
compliance program (as identified in A3.1.3), and
include the following:
• Confirmation that all BAU activities (e.g., A3.2.2,
A3.2.6, and A3.3.1) are being performed
• Confirmation that personnel are following security
policies and operational procedures (for example, daily
log reviews, firewall rule-set reviews, configuration
standards for new systems, etc.)
• Documenting how the reviews were completed, 3 N
including how all BAU activities were verified as being
in place.
• Collection of documented evidence as required for the
annual PCI DSS assessment
• Review and sign-off of results by personnel assigned
responsibility for the PCI DSS compliance program (as
identified in A3.1.3)
• Retention of records and documentation for at least
12 months, covering all BAU activities

PCI DSS Reference: Requirements 1-12

A3.4 Control and manage logical access to the cardholder data environment

A3.4.1 Review user accounts and access privileges to

in-scope system components at least every six months
to ensure user accounts and access remain appropriate
based on job function, and authorized.
3 N

PCI DSS Reference: Requirement 7

A3.5 Identify and respond to suspicious events

A3.5.1 Implement a methodology for the timely

identification of attack patterns and undesirable
behavior across systems—for example, using
coordinated manual reviews and/or centrally managed
or automated log correlation tools—to include at least
the following:
• Identification of anomalies or suspicious activity as it
occurs
3 N
• Issuance of timely alerts upon detection of suspicious
activity or anomaly to responsible personnel
• Response to alerts in accordance with documented
response procedures

PCI DSS Reference: Requirements 10, 12

 at are directly addressed by this AWS Quick Start package, including
AWS-managed products and services. It is important to note that
dance in this document are not exhaustive, and must be reviewed,
nd layered with other security features that address all of the in-
ll security requirements.

AWS CloudFormation
Description of AWS Implementation AWS Resource Type(s)
Template Name (Stack)

dholder data

N/A N/A N/A

Architecture Diagram in the Deployment

N/A N/A
Guide

Architecture Diagram in the Deployment

N/A N/A
Guide

AWS::EC2::SecurityGroup
Segmented using Security Groups in VPC, use
AWS::EC2::NetworkAcl template-vpc-management
of a VPC public subnet to simulate a
AWS::EC2::NetworkAclEn template-vpc-production
traditional DMZ network zone
try

IAM configuration description and template All resources in template template-iam

N/A N/A N/A

 N/A N/A N/A

AWS::EC2::SecurityGroup
Security Groups, NACLs used to limit traffic to AWS::EC2::NetworkAcl template-vpc-management
the CDE AWS::EC2::NetworkAclEn template-vpc-production
try

AWS architecture provided as JSON templates

All resources in template All templates
and deployed via AWS CloudFormation

N/A N/A N/A

AWS::EC2::SecurityGroup
AWS::EC2::NetworkAcl
AWS::EC2::NetworkAclEn
Segmented Public/Private Subnets in VPC, try
template-vpc-management
Security Groups and NACLs limit external AWS::EC2::Route
template-vpc-production
traffic to only required ports AWS::EC2::RouteTable
AWS::EC2::RouteTableAss
ociation
AWS::EC2::Subnet
 AWS::EC2::SecurityGroup
AWS::EC2::NetworkAcl
AWS::EC2::NetworkAclEn
Segmented Public/Private Subnets in VPC, try
template-vpc-management
Security Groups and NACLs limit external AWS::EC2::Route
template-vpc-production
traffic to only required ports AWS::EC2::RouteTable
AWS::EC2::RouteTableAss
ociation
AWS::EC2::Subnet

Use of VPC restricts layer two broadcasts and All resources in template template-vpc-management
ARP spoofing template-vpc-production

AWS::EC2::SecurityGroup
Restricting traffic with inbound/outbound
AWS::EC2::NetworkAcl template-vpc-management
rules in Security Groups and NACLs, NAT for template-vpc-production
authorized external connections. AWS::EC2::NetworkAclEn template-application
try

Restricting traffic with inbound/outbound template-vpc-management

AWS::EC2::SecurityGroup
rules in Security Groups template-vpc-production

AWS::EC2::Route
AWS::EC2::RouteTable
Placement of DBs and EC2 instances for AWS::EC2::RouteTableAss
ociation template-application
application in private-only subnets
AWS::EC2::Subnet
AWS::AutoScaling::AutoS
calingGroup

AWS::EC2::Route
AWS::EC2::RouteTable
AWS::EC2::RouteTableAss
Placement of DBs and EC2 instances for ociation template-vpc-production
application in private-only subnets AWS::EC2::Subnet template-application
AWS::AutoScaling::AutoS
calingGroup
AWS::RDS::DBInstance
 N/A N/A N/A

N/A N/A N/A

s and other security parameters

N/A N/A N/A

N/A N/A N/A

N/A N/A N/A

 AWS::AutoScaling::AutoS
Separating Application and Web/Proxy calingGroup
functions between different AutoScaling AWS::AutoScaling::Launc template-application
Group Instances hConfiguration
AWS::RDS::DBInstance

N/A N/A N/A

AWS::ElasticLoadBalancin
The use of HTTPS load balancers for secure g::LoadBalancer template-application
communications, S3 bucket policies

IAM Configuration and Policies which AWS::IAM::Role,

implement separation of duties and least AWS::IAM::Policy template-iam
privilege, S3 bucket policies AWS::IAM::Group

N/A N/A N/A

The use of HTTPS load balancers for secure AWS::ElasticLoadBalancin template-vpc-management

communications, Bastion hosts with SSH g::LoadBalancer template-vpc-production
enabled AWS::EC2:: template-application

AWS architecture provided as JSON templates

All resources in template All templates
and deployed via AWS CloudFormation

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

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

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

N/A N/A N/A

N/A N/A N/A

blic networks
 AWS::ElasticLoadBalancin
Use of HTTPS Elastic Load Balancers (ELBs)
g::LoadBalancer
with compliant w/TLS Policies, Enforcement AWS::EC2::SecurityGroup template-application
of AES256 encryption for HTTPS S3
s
connections
AWS::S3::BucketPolicy

N/A N/A N/A

N/A N/A N/A

N/A N/A N/A

anti-virus software or programs

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

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

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

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

N/A N/A N/A

ces (internal or external):

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

ow

AWS::IAM::ManagedPolic
IAM Roles, Policies, Groups y template-iam
AWS::IAM::Group

AWS::IAM::ManagedPolic
IAM Roles, Policies, Groups y template-iam
AWS::IAM::Group

N/A N/A N/A

N/A N/A N/A

 AWS::IAM::ManagedPolic
IAM Roles, Policies, Groups y template-iam
AWS::IAM::Group

N/A N/A N/A

AWS::IAM::ManagedPolic
IAM will designed to deny access by default y template-iam
AWS::IAM::Group

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

N/A N/A N/A

N/A N/A N/A

N/A N/A N/A

IAM by default handles credentials in a secure

manner, SSH is configured on the Bastion N/A N/A
Hosts for operating system access

N/A N/A N/A

Password Policy (IAM) N/A N/A

Password Policy (IAM) N/A N/A

Password Policy (IAM) N/A N/A

Password Policy (IAM) N/A N/A

Manually set MFA for new IAM users N/A N/A

Manually set MFA for new IAM users N/A N/A

Manually set MFA for new IAM users N/A N/A

N/A N/A N/A

 AWS::IAM::ManagedPolic
IAM groups and roles used in place of generic y
template-iam
"root" AWS user, activity with root is notified AWS::IAM::Group
template-logging
to SNS topic AWS::IAM::Role
AWS::Logs::MetricFilter

N/A N/A N/A

N/A N/A N/A

Use of security groups and NACLs restrict only

App servers to query RDS DB and prevent
AWS::RDS::DBInstance
possibility of any external or unauthorized template-application
access, single RDS user/password is setup in AWS::EC2::SecurityGroup
sample DB

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

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

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

N/A N/A N/A

N/A N/A N/A

ardholder data

AWS CloudTrail enabled and logging AWS::CloudTrail:::Trail template-logging

AWS CloudTrail enabled and logging AWS::CloudTrail:::Trail template-logging

AWS CloudTrail records these actions,
AWS::CloudWatch::Alarm
CloudWatch Alarm will notify if root admin template-logging
user makes any API calls AWS::Logs::MetricFilter

AWS CloudTrail logs to a protected S3 bucket AWS::S3::Bucket

exclusively for CloudTrail logs, ArchiveLog AWS::S3::BucketPolicy template-logging
bucket can also be used for application logs AWS::CloudTrail::Trail

CloudWatch Alarms detect unauthorized AWS::CloudTrail::Trail

AWS::CloudWatch::Alarm template-logging
access attempts and send to SNS topic AWS::Logs::MetricFilter

CloudTrail Logs these actions, IAM activity and AWS::CloudTrail::Trail

creation of AccessKeys send notifications with AWS::CloudWatch::Alarm template-logging
CloudWatch Alarms AWS::Logs::MetricFilter

IAM policies prevent start/stop of CloudTrail, AWS::CloudTrail::Trail

S3 bucket policies protect access to log data, AWS::CloudWatch::Alarm template-iam
Alerts are sent if CloudTrail is disabled, Config AWS::Logs::MetricFilter template-logging
rule in global-02 provides monitoring of AWS::IAM::Policy template-config-rules
CloudTrail enabled AWS::Config::ConfigRule

AWS::CloudTrail::Trail
AWS::CloudWatch::Alarm template-iam
AWS CloudTrail records API calls to create,
delete and modify resources AWS::Logs::MetricFilter template-logging
AWS::IAM::Policy template-config-rules
AWS::Config::ConfigRule

CloudTrail records all API events and logs

AWS::CloudTrail::Trail template-logging
which user, time/date, action, and result
Recorded as EventName in CloudTrail AWS::CloudTrail::Trail template-logging
Event time in CloudTrail AWS::CloudTrail::Trail template-logging
ErrorCode in CloudTrail AWS::CloudTrail::Trail template-logging
CloudTrail AWS::CloudTrail::Trail template-logging
CloudTrail AWS::CloudTrail::Trail template-logging

template-vpc-management
All instances launched in VPC are synced with NTP AWS::EC2::Instance
template-vpc-production
 All instances launched in VPC are synced with NTP, all template-vpc-management
AWS::EC2::Instance
log data has timestamp provided by NTP template-vpc-production
N/A N/A N/A
All instances launched in VPC are synced with AWS NTP template-vpc-management
AWS::EC2::Instance
servers which in turn obtain time from NTP.org template-vpc-production

IAM with custom policies provide restrictions

on which roles can access CloudTrail and log AWS::IAM::Policy template-iam
data
AWS::S3::Bucket
IAM Restrictions to Log Data template-logging
AWS::S3::BucketPolicy
CloudTrail and Log S3 buckets use versioning, AWS::S3::Bucket
template-logging
lifecycle policies, and deny delete capability AWS::S3::BucketPolicy

CloudTrail and Log S3 buckets use versioning, AWS::S3::Bucket

template-logging
lifecycle policies, and deny delete capability AWS::S3::BucketPolicy

LogFileValidation is enabled for CloudTrail AWS::CloudTrail::Trail template-logging

N/A N/A N/A

N/A N/A N/A

The bucket storing theN/Alog data does not have N/A N/A
life cycle policy attached to it, to allow
organizations control over their log storage. A
AWS::S3::Bucket
sample lifecycle policy to move logs to glacier AWS::S3::BucketPolicy template-logging
after 90days and to delete them after 7 years
is included in the package as
"rArchiveLogBucket".
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

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

 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

all personnel

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

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

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

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

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

Isolated FORENSICS VPC can be deployed as

N/A optional
part of an incident response plan

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

ders

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

rly TLS

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

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

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

N/A N/A N/A

N/A N/A N/A

Additional AWS Guidance

N/A

Applies to operational
procedures/practices

Applies to operational
procedures/practices

N/A

N/A

N/A
 N/A

N/A

Applies to operational
procedures/practices

N/A

N/A
N/A

N/A

N/A

N/A

N/A

N/A
 N/A

N/A

N/A

N/A

Customers can adhere to this requirement by

creating hardened templates for all the
components in their CDE, following best
practices from CIS and other standard industry
accepted sources. CIS also provides hardened
AMI's on the AWS marketplace which can be
incorporated into this template.
 N/A

N/A

N/A

N/A

N/A

N/A

Applies to operational
procedures/practices

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

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
 The AWS deployment provides logically
separated Management and Production
processing domains to allow finer-grained
access of AWS IAM users to those
environments, through the use of separate
Management and Production VPCs, with the
expectation of separate Development VPCs to
be added as needed. Access is controlled by
user membership in IAM groups in
conjunction with AWS Security Group rules,
NACLs, and route tables.

The AWS deployment provides logically

separated Management and Production
processing domains to allow finer-grained
access of AWS IAM users to those
environments, through the use of separate
Management and Production VPCs, with the
expectation of separate Development VPCs to
be added as needed. Access is controlled by
user membership in IAM groups in
conjunction with AWS Security Group rules,
NACLs, and route tables.

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
The template provides NGINX proxies
in the public subnet for application
load balancing purposes. The NAXSI
project has developed a web
application filtering module for
NGINX that could help meet this
requirement.

N/A

N/A

N/A

N/A

N/A
AWS IAM only provides the means to
manage access on AWS resources.
Other components such as operating
systems will require their own access
management solutions.

N/A

N/A

N/A

Identity Federation can help meet

these requirements
http://docs.aws.amazon.com/IAM/la
test/UserGuide/id_roles_providers.ht
ml

Identity Federation can help meet

these requirements
http://docs.aws.amazon.com/IAM/la
test/UserGuide/id_roles_providers.ht
ml

Identity Federation can help meet

these requirements
http://docs.aws.amazon.com/IAM/la
test/UserGuide/id_roles_providers.ht
ml

Identity Federation can help meet

these requirements
http://docs.aws.amazon.com/IAM/la
test/UserGuide/id_roles_providers.ht
ml
 Identity Federation can help meet
these requirements
http://docs.aws.amazon.com/IAM/la
test/UserGuide/id_roles_providers.ht
ml

Identity Federation can help meet

these requirements
http://docs.aws.amazon.com/IAM/la
test/UserGuide/id_roles_providers.ht
ml

Identity Federation can help meet

these requirements
http://docs.aws.amazon.com/IAM/la
test/UserGuide/id_roles_providers.ht
ml

Identity Federation can help meet

these requirements
http://docs.aws.amazon.com/IAM/la
test/UserGuide/id_roles_providers.ht
ml

Identity Federation can help meet

these requirements
http://docs.aws.amazon.com/IAM/la
test/UserGuide/id_roles_providers.ht
ml

N/A

Identity Federation can help meet

these requirements
http://docs.aws.amazon.com/IAM/la
test/UserGuide/id_roles_providers.ht
ml

Password policy cannot be

automated but can be set in the
console:
http://docs.aws.amazon.com/IAM/la
test/UserGuide/id_credentials_passw
ords_account-policy.html
Password policy cannot be automated but can
be set in the console:
http://docs.aws.amazon.com/IAM/latest/Use
rGuide/id_credentials_passwords_account-
policy.html

Password policy cannot be automated but can

be set in the console:
http://docs.aws.amazon.com/IAM/latest/Use
rGuide/id_credentials_passwords_account-
policy.html

Password policy cannot be automated but can

be set in the console:
http://docs.aws.amazon.com/IAM/latest/Use
rGuide/id_credentials_passwords_account-
policy.html

When an IAM user is added to existing IAM

groups MFA should be enabled
http://docs.aws.amazon.com/IAM/latest/Use
rGuide/id_credentials_mfa.html In addition,
MFA may be able to be provided by an
identity provider using federation

When an IAM user is added to existing IAM

groups MFA should be enabled
http://docs.aws.amazon.com/IAM/latest/Use
rGuide/id_credentials_mfa.html In addition,
MFA may be able to be provided by an
identity provider using federation

When an IAM user is added to existing IAM

groups MFA should be enabled
http://docs.aws.amazon.com/IAM/latest/Use
rGuide/id_credentials_mfa.html In addition,
MFA may be able to be provided by an
identity provider using federation

N/A
 Applies to operational
procedures/practices.
AWS security best practices
recommend the use of IAM for
routine access to AWS.

N/A

N/A

N/A

N/A

Inherited control from the AWS

global infrastructure
Inherited control from the AWS
global infrastructure

Inherited control from the AWS

global infrastructure

Inherited control from the AWS

global infrastructure

Inherited control from the AWS

global infrastructure

Inherited control from the AWS

global infrastructure

Inherited control from the AWS

global infrastructure

Inherited control from the AWS

global infrastructure

Inherited control from the AWS

global infrastructure
Inherited control from the AWS
global infrastructure

Inherited control from the AWS

global infrastructure

Inherited control from the AWS

global infrastructure

Inherited control from the AWS

global infrastructure
Inherited control from the AWS
global infrastructure
Inherited control from the AWS
global infrastructure

Inherited control from the AWS

global infrastructure

Inherited control from the AWS

global infrastructure

Inherited control from the AWS

global infrastructure
 N/A

N/A

N/A

N/A

AWS CloudTrail logs access to the AWS APIs.

You will need to account for audit trails from
other components in the CDE such as the
operating system logs.

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

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

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

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

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

N/A

N/A

N/A

N/A
N/A

N/A

N/A
N/A

N/A

N/A