apply. - google cloud › files › pci_dss_shared... · works. ions ore zone, ed works. been...

PCI DSS Requirements 3.1 Testing Procedures 3.1 GCP (Google Cloud Platform) Responsibility Customer Responsibility

1.1 Establish and implement firewall and routerconfiguration standards that include thefollowing:

1.1 Inspect the firewall and router configurationstandards and other documentation specifiedbelow and verify that standards are completeand implemented as follows:

1.1.1 A formal process for approving and testingall network connections and changes to thefirewall and router configurations

1.1.1.a Examine documented procedures toverify there is a formal process for testing andapproval of all: * Network connections and * Changes to firewall and router configurations

Google's internal production network andsystems have been assessed against andcomply with this requirement.

GCP customers are responsible forimplementing processes and proceduresnecessary to ensure that all networkconnections, inbound and outbound traffic onany customer instances deployed on GCPcomply the requirements of Section 1 of PCIDSS.

1.1.1.b For a sample of network connections,interview responsible personnel and examinerecords to verify that network connections wereapproved and tested.



1.1.1.c Identify a sample of actual changesmade to firewall and router configurations,compare to the change records, and interviewresponsible personnel to verify the changeswere approved and tested.



1.1.2 Current network diagram that identifies allconnections between the cardholder dataenvironment and other networks, including anywireless networks

1.1.2.a Examine diagram(s) and observenetwork configurations to verify that a currentnetwork diagram exists and that it documents allconnections to cardholder data, including anywireless networks.

Google's internal production network andsystems have been assessed against andcomply with this requirement


PCI DSS Shared Responsibility of Google Cloud Platform

When payment card data is stored or processed by customers on GCP (Google Cloud Platform), the requirements of PCI DSS (Payment Card Industry Data Security Standard) will apply.Complying to the requirements of PCI DSS is a shared responsibility between Customers and Google.

The allocation of responsibility between Google and customer for managing security controls does not exempt the customer from the responsibly of ensuring that their CHD (CardHolder Data) isproperly secured according to applicable PCI DSS requirements. Refer information supplement from PCI Security Standards Council.

GCP was designed with security as a major design component. Google uses a variety of technologies and processes to secure information stored on Google servers. Google has performedindependent validation on PCI DSS requirements that apply to GCP technologies and infrastructure managed by Google.

Google offers customers a great deal of control over their instances running on Google’s infrastructure. Google does not control security on the operating system, packages or applications that aredeployed by customers on GCP. It is the customer’s responsibility to comply with requirements of PCI DSS that relate to operating systems packages and applications deployed by customer.

1.1.2.b Interview responsible personnel to verifythat the diagram is kept current.

Google's internal production network andsystems have been assessed against andcomply with this requirement


1.1.3 Current diagram that shows all cardholderdata flows across systems and networks

1.1.3 Examine data-flow diagram and interviewpersonnel to verify the diagram: * Shows all cardholder data flows acrosssystems and networks. * Is kept current and updated as needed uponchanges to the environment.

Firewalls that comply with this requirement havebeen implemented by Google to control accessto Google production network and to GCPproducts and services implemented by Google.


1.1.4 Requirements for a firewall at eachInternet connection and between anydemilitarized zone (DMZ) and the internalnetwork zone

1.1.4.a Examine the firewall configurationstandards and verify that they includerequirements for a firewall at each Internetconnection and between any DMZ and theinternal network zone.



1.1.4.b Verify that the current network diagramis consistent with the firewall configurationstandards.



1.1.4.c Observe network configurations to verifythat a firewall is in place at each Internetconnection and between any demilitarized zone(DMZ) and the internal network zone, per thedocumented configuration standards andnetwork diagrams.



1.1.5 Description of groups, roles, andresponsibilities for management of networkcomponents

1.1.5.a Verify that firewall and routerconfiguration standards include a description ofgroups, roles, and responsibilities formanagement of network components.



1.1.5.b Interview personnel responsible formanagement of network components to confirmthat roles and responsibilities are assigned asdocumented.



1.1.6 Documentation and business justificationfor use of all services, protocols, and portsallowed, including documentation of securityfeatures implemented for those protocolsconsidered to be insecure.

Examples of insecure services, protocols, orports include but are not limited to FTP, Telnet,POP3, IMAP, and SNMP v1 and v2.

1.1.6.a Verify that firewall and routerconfiguration standards include a documentedlist of all services, protocols and ports, includingbusiness justification for each —for example,hypertext transfer protocol (HTTP) and SecureSockets Layer (SSL), Secure Shell (SSH), andVirtual Private Network (VPN) protocols.



1.1.6.b Identify insecure services, protocols, andports allowed; and verify that security featuresare documented for each service.



1.1.6.c Examine firewall and routerconfigurations to verify that the documentedsecurity features are implemented for eachinsecure service, protocol, and port.



1.1.7 Requirement to review firewall and routerrule sets at least every six months

1.1.7.a Verify that firewall and routerconfiguration standards require review of firewalland router rule sets at least every six months.



1.1.7.b Examine documentation relating to ruleset reviews and interview responsible personnelto verify that the rule sets are reviewed at leastevery six months.



1.2 Build firewall and router configurations thatrestrict connections between untrusted networksand any system components in the cardholderdata environment.

Note: An “untrusted network” is any network thatis external to the networks belonging to theentity under review, and/or which is out of theentity's ability to control or manage.

1.2 Examine firewall and router configurationsand perform the following to verify thatconnections are restricted between untrustednetworks and system components in thecardholder data environment:

1.2.1 Restrict inbound and outbound traffic tothat which is necessary for the cardholder dataenvironment, and specifically deny all othertraffic.

1.2.1.a Examine firewall and router configurationstandards to verify that they identify inbound andoutbound traffic necessary for the cardholderdata environment.


GCP customers are responsible for ensuringthat firewalls that meet Section 1 requirementsare implemented on inbound and outboundtraffic to and from any customer instancesdeployed on GCP meet the requirements ofSection 1 of PCI DSS. Referhttps://cloud.google.com/compute/docs/networking for the capabilities provided by GCP to thecustomer.

1.2.1.b Examine firewall and routerconfigurations to verify that inbound andoutbound traffic is limited to that which isnecessary for the cardholder data environment.



1.2.1.c Examine firewall and routerconfigurations to verify that all other inboundand outbound traffic is specifically denied, forexample by using an explicit “deny all” or animplicit deny after allow statement.



1.2.2 Secure and synchronize routerconfiguration files.

1.2.2.a Examine router configuration files toverify they are secured from unauthorizedaccess.

Firewalls, routers that comply with thisrequirement have been implemented by Googleto control access to Google production networkand to GCP products and services implementedby Google.


1.2.2.b Examine router configurations to verifythey are synchronized —for example, therunning (or active) configuration matches thestart-up configuration (used when machines arebooted).

Firewalls, routers that comply with thisrequirement have been implemented by Googleto control access to Google production networkand to GCP products and services implementedby Google.


1.2.3 Install perimeter firewalls between allwireless networks and the cardholder dataenvironment, and configure these firewalls todeny or, if traffic is necessary for businesspurposes, permit only authorized traffic betweenthe wireless environment and the cardholderdata environment.

1.2.3.a Examine firewall and routerconfigurations to verify that there are perimeterfirewalls installed between all wireless networksand the cardholder data environment.



1.2.3.b Verify that the firewalls deny or, if trafficis necessary for business purposes, permit onlyauthorized traffic between the wirelessenvironment and the cardholder dataenvironment.



1.3 Prohibit direct public access between theInternet and any system component in thecardholder data environment.

1.3 Examine firewall and router configurations—including but not limited to the choke router atthe Internet, the DMZ router and firewall, theDMZ cardholder segment, the perimeter router,and the internal cardholder network segment—and perform the following to determine thatthere is no direct access between the Internetand system components in the internalcardholder network segment:

1.3.1 Implement a DMZ to limit inbound traffic toonly system components that provide authorizedpublicly accessible services, protocols, andports.

1.3.1 Examine firewall and router configurationsto verify that a DMZ is implemented to limitinbound traffic to only system components thatprovide authorized publicly accessible services,protocols, and ports.



1.3.2 Limit inbound Internet traffic to IPaddresses within the DMZ.

1.3.2 Examine firewall and router configurationsto verify that inbound Internet traffic is limited toIP addresses within the DMZ.



1.3.3 Do not allow any direct connectionsinbound or outbound for traffic between theInternet and the cardholder data environment.

1.3.3 Examine firewall and router configurationsto verify direct connections inbound or outboundare not allowed for traffic between the Internetand the cardholder data environment.



1.3.4 Implement anti-spoofing measures todetect and block forged source IP addressesfrom entering the network.

(For example, block traffic originating from theInternet with an internal source address.)

1.3.4 Examine firewall and router configurationsto verify that anti-spoofing measures areimplemented, for example internal addressescannot pass from the Internet into the DMZ.



1.3.5 Do not allow unauthorized outbound trafficfrom the cardholder data environment to theInternet.

1.3.5 Examine firewall and router configurationsto verify that outbound traffic from thecardholder data environment to the Internet isexplicitly authorized.



1.3.6 Implement stateful inspection, also knownas dynamic packet filtering. (That is, only“established” connections are allowed into thenetwork.)

1.3.6 Examine firewall and router configurationsto verify that the firewall performs statefulinspection (dynamic packet filtering). (Onlyestablished connections should be allowed in,and only if they are associated with a previouslyestablished session.)



1.3.7 Place system components that storecardholder data (such as a database) in aninternal network zone, segregated from the DMZand other untrusted networks.

1.3.7 Examine firewall and router configurationsto verify that system components that storecardholder data are on an internal network zone,segregated from the DMZ and other untrustednetworks.

Google infrastructure underlying GCP has beenassessed to comply with this requirement

GCP customers are responsible for ensuringthat any cardholder data stored within virtualmachines, appliations, services or databasesare appropriately segregated from untrustednetworks.

1.3.8 Do not disclose private IP addresses androuting information to unauthorized parties.

Note: Methods to obscure IP addressing mayinclude, but are not limited to: * Network Address Translation (NAT) * Placing servers containing cardholder databehind proxy servers/firewalls, * Removal or filtering of route advertisementsfor private networks that employ registeredaddressing, * Internal use of RFC1918 address spaceinstead of registered addresses.

1.3.8.a Examine firewall and routerconfigurations to verify that methods are in placeto prevent the disclosure of private IP addressesand routing information from internal networks tothe Internet.



1.3.8.b Interview personnel and examinedocumentation to verify that any disclosure ofprivate IP addresses and routing information toexternal entities is authorized.



1.4 Install personal firewall software on anymobile and/or employee-owned devices thatconnect to the Internet when outside thenetwork (for example, laptops used byemployees), and which are also used to accessthe network.

Firewall configurations include: * Specific configuration settings are defined forpersonal firewall software. * Personal firewall software is actively running. * Personal firewall software is not alterable byusers of mobile and/or employee-owneddevices.

1.4.a Examine policies and configurationstandards to verify: * Personal firewall software is required for allmobile and/or employee-owned devices thatconnect to the Internet (for example, laptopsused by employees) when outside the network,and which are also used to access the network. * Specific configuration settings are defined forpersonal firewall software. * Personal firewall software is configured toactively run. * Personal firewall software is configured to notbe alterable by users of mobile and/oremployee-owned devices.

This requirement was determined as out ofscope by the QSA for Google Cloud PCIAssessment

GCP customers are responsible for ensuringthat any of customer's devices/systems that fallwithin the scope this requirement comply withthis requirement.

1.4.b Inspect a sample of mobile and/oremployee-owned devices to verify that: * Personal firewall software is installed andconfigured per the organization’s specificconfiguration settings. * Personal firewall software is actively running. * Personal firewall software is not alterable byusers of mobile and/or employee-owneddevices.

This requirement was determined as out ofscope by the QSA for Google Cloud PCIAssessment

GCP customers are responsible for ensuringthat devices/systems that fall within the scopethis requirement comply with this requirement.

2.1 Always change vendor-supplied defaults andremove or disable unnecessary default accountsbefore installing a system on the network.

This applies to ALL default passwords, includingbut not limited to those used by operatingsystems, software that provides securityservices, application and system accounts,point-of-sale (POS) terminals, Simple NetworkManagement Protocol (SNMP) communitystrings, etc.).

2.1.a Choose a sample of system components,and attempt to log on (with system administratorhelp) to the devices and applications usingdefault vendor-supplied accounts andpasswords, to verify that ALL default passwords(including those on operating systems, softwarethat provides security services, application andsystem accounts, POS terminals, and SimpleNetwork Management Protocol (SNMP)community strings) have been changed. (Usevendor manuals and sources on the Internet tofind vendor-supplied accounts/passwords.)

It is Google's responsibility to comply with therequirements of this control in security theinfrastructure underlying GCP. Google is notresponsible for any configuration withincustomer deployed instances on GCP forcompliance with requirements of section 2.

GCP customers are responsible for ensuringthat all customer deployed instances areconfigured in a secure manner in compliancewith the requirements within section 2.

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, POSterminals, SNMP, etc.) are removed or disabled.



2.1.c Interview personnel and examinesupporting documentation to verify that: * All vendor defaults (including defaultpasswords on operating systems, softwareproviding security services, application andsystem accounts, POS terminals, SimpleNetwork Management Protocol (SNMP)community strings, etc.) are changed before asystem is installed on the network. * Unnecessary default accounts (includingaccounts used by operating systems, securitysoftware, applications, systems, POS terminals,SNMP, etc.) are removed or disabled before asystem is installed on the network.



2.1.1 For wireless environments connected tothe cardholder data environment or transmittingcardholder data, change ALL wireless vendordefaults at installation, including but not limitedto default wireless encryption keys, passwords,and SNMP community strings.

2.1.1.a Interview responsible personnel andexamine supporting documentation to verifythat: * Encryption keys were changed from default atinstallation * Encryption keys are changed anytime anyonewith knowledge of the keys leaves the companyor changes positions.

No wireless networks are connected to theCardholder Data Environment relating to GCP

GCP customer are responsible for complyingwith this requirement for any wireless networkthat may fall within the scope of their PCI DSSassessments.

2.1.1.b Interview personnel and examinepolicies and procedures to verify: * Default SNMP community strings arerequired to be changed upon installation. * Default passwords/phrases on access pointsare required to be changed upon installation.



2.1.1.c Examine vendor documentation andlogin to wireless devices, with systemadministrator help, to verify: * Default SNMP community strings are notused. * Default passwords/passphrases on accesspoints are not used.



2.1.1.d Examine vendor documentation andobserve wireless configuration settings to verifyfirmware on wireless devices is updated tosupport strong encryption for: * Authentication over wireless networks * Transmission over wireless networks.



2.1.1.e Examine vendor documentation andobserve wireless configuration settings to verifyother security-related wireless vendor defaultswere changed, if applicable.



2.2 Develop configuration standards for allsystem components. Assure that thesestandards address all known securityvulnerabilities and are consistent with industry-accepted system hardening standards.

Sources of industry-accepted system hardeningstandards may include, but are not limited to: * Center for Internet Security (CIS) * International Organization for Standardization(ISO) * SysAdmin Audit Network Security (SANS)Institute * National Institute of Standards Technology(NIST).

2.2.a Examine the organization’s systemconfiguration standards for all types of systemcomponents and verify the system configurationstandards are consistent with industry- acceptedhardening standards.

Google has implemented configurationstandards that comply with requirements insection 2.2 for the infrastructure underlying GCPproducts in scope for PCI.

GCP customers are responsible for complyingwith this requirement for any virtual machines,applications, services or databases deployed bythem on GCP.

2.2.b Examine policies and interview personnelto verify that system configuration standards areupdated as new vulnerability issues areidentified, as defined in Requirement 6.1.



2.2.c Examine policies and interview personnelto verify that system configuration standards areapplied when new systems are configured andverified as being in place before a system isinstalled on the network.



2.2.d Verify that system configuration standardsinclude the following procedures for all types ofsystem components: * Changing of all vendor-supplied defaults andelimination of unnecessary default accounts * Implementing only one primary function perserver to prevent functions that require differentsecurity levels from co-existing on the sameserver * Enabling only necessary services, protocols,daemons, etc., as required for the function of thesystem * Implementing additional security features forany required services, protocols or daemonsthat are considered to be insecure * Configuring system security parameters toprevent misuse * Removing all unnecessary functionality, suchas scripts, drivers, features, subsystems, filesystems, and unnecessary web servers.



2.2.1 Implement only one primary function perserver to prevent functions that require differentsecurity levels from co-existing on the sameserver. (For example, web servers, databaseservers, and DNS should be implemented onseparate servers.) Note: Where virtualizationtechnologies are in use, implement only oneprimary function per virtual system component.

2.2.1.a Select a sample of system componentsand inspect the system configurations to verifythat only one primary function is implementedper server.



2.2.1.b If virtualization technologies are used,inspect the system configurations to verify thatonly one primary function is implemented pervirtual system component or device.

This requirement was determined by GoogleQSA

GCP customers are responsible for ensuringthat their virtual guest machines have only oneprimary function per virtual server.

2.2.2 Enable only necessary services, protocols,daemons, etc., as required for the function of thesystem.

2.2.2.a Select a sample of system componentsand inspect enabled system services, daemons,and protocols to verify that only necessaryservices or protocols are enabled.



2.2.2.b Identify any enabled insecure services,daemons, or protocols and interview personnelto verify they are justified per documentedconfiguration standards.



2.2.3 Implement additional security features forany required services, protocols, or daemonsthat are considered to be insecure —forexample, use secured technologies such asSSH, S-FTP, TLS, or IPSec VPN to protectinsecure services such as NetBIOS, file-sharing,Telnet, FTP, etc.

Note: SSL and early TLS are not consideredstrong cryptography and cannot be used as asecurity control after June 30, 2016. Prior to thisdate, existing implementations that use SSLand/or early TLS must have a formal RiskMitigation and Migration Plan in place.Effective immediately, new implementationsmust not use SSL or early TLS.POS POI terminals (and the SSL/TLStermination points to which they connect) thatcan be verified as not being susceptible to anyknown exploits for SSL and early TLS maycontinue using these as a security control afterJune 30, 2016.

2.2.3.a Inspect configuration settings to verifythat security features are documented andimplemented for all insecure services, daemons,or protocols.



2.2.3.b For POS POI terminals (and theSSL/TLS termination points to which theyconnect) using SSL and/or early TLS and forwhich the entity asserts are not susceptible toany known exploits for those protocols:Confirm the entity has documentation (forexample, vendor documentation,system/network configuration details, etc.) thatverifies the devices are not susceptible to anyknown exploits for SSL/early TLS.



2.2.3.c For all other environments using SSLand/or early TLS:Review the documented Risk Mitigation andMigration Plan to verify it includes: * Description of usage, including what data isbeing transmitted, types and number of systemsthat use and/or support SSL/early TLS, type ofenvironment; * Risk-assessment results and risk-reductioncontrols in place; * Description of processes to monitor for newvulnerabilities associated with SSL/early TLS; * Description of change control processes thatare implemented to ensure SSL/early TLS is notimplemented into new environments; * Overview of migration project plan includingtarget migration completion date no later thanJune 30, 2016.



2.2.4 Configure system security parameters toprevent misuse.

2.2.4.a Interview system administrators and/orsecurity managers to verify that they haveknowledge of common security parametersettings for system components.



2.2.4.b Examine the system configurationstandards to verify that common securityparameter settings are included.



2.2.4.c Select a sample of system componentsand inspect the common security parameters toverify that they are set appropriately and inaccordance with the configuration standards.



2.2.5 Remove all unnecessary functionality,such as scripts, drivers, features, subsystems,file systems, and unnecessary web servers.

2.2.5.a Select a sample of system componentsand inspect the configurations to verify that allunnecessary functionality (for example, scripts,drivers, features, subsystems, file systems, etc.)is removed.



2.2.5.b. Examine the documentation andsecurity parameters to verify enabled functionsare documented and support secureconfiguration.



2.2.5.c. Examine the documentation andsecurity parameters to verify that onlydocumented functionality is present on thesampled system components.



2.3 Encrypt all non-console administrativeaccess using strong cryptography. Usetechnologies such as SSH, VPN, or TLS forweb-based management and other non-consoleadministrative access.

Note: SSL and early TLS are not consideredstrong cryptography and cannot be used as asecurity control after June 30, 2016. Prior to thisdate, existing implementations that use SSLand/or early TLS must have a formal RiskMitigation and Migration Plan in place.Effective immediately, new implementationsmust not use SSL or early TLS.POS POI terminals (and the SSL/TLStermination points to which they connect) thatcan be verified as not being susceptible to anyknown exploits for SSL and early TLS maycontinue using these as a security control afterJune 30, 2016.

2.3 Select a sample of system components andverify that non- console administrative access isencrypted by performing the following:

2.3.a Observe an administrator log on to eachsystem and examine system configurations toverify that a strong encryption method is invokedbefore the administrator’s password isrequested.

Google has implemented controls for secureadministrative access for the Google productioninfrastructure underlying GCP

GCP customers are responsible for complyingwith this requirement for secure administrativeaccess to machines, applications, services ordatabases deployed by them on GCP.

2.3.b Review services and parameter files onsystems to determine that Telnet and otherinsecure remote-login commands are notavailable for non-console access.

Google has implemented controls for secureadministrative access for the Google productioninfrastructure underlying GCP.


2.3.c Observe an administrator log on to eachsystem to verify that administrator access to anyweb-based management interfaces is encryptedwith strong cryptography.

All web administration interfaces to GCPrequires HTTPS with strong cryptography.


2.3.d Examine vendor documentation andinterview personnel to verify that strongcryptography for the technology in use isimplemented according to industry bestpractices and/or vendor recommendations.



2.3.e For POS POI terminals (and the SSL/TLStermination points to which they connect) usingSSL and/or early TLS and for which the entityasserts are not susceptible to any knownexploits for those protocols:Confirm the entity has documentation (forexample, vendor documentation,system/network configuration details, etc.) thatverifies the devices are not susceptible to anyknown exploits for SSL/early TLS.

N/A. Google does not provide POS POIterminals as part of its GCP infrastructure.

GCP customers are responsible for using strongcryptography and security protocols (forexample TLS, IPSEC etc) on POS POI terminalsto safeguard sensitive cardholder data duringtransmission over open, public networks.

2.3.f For all other environments using SSLand/or early TLS:Review the documented Risk Mitigation andMigration Plan to verify it includes:Description of usage, including what data isbeing transmitted, types and number of systemsthat use and/or support SSL/early TLS, type ofenvironment;Risk-assessment results and risk-reductioncontrols in place;Description of processes to monitor for newvulnerabilities associated with SSL/early TLS;Description of change control processes that areimplemented to ensure SSL/early TLS is notimplemented into new environments;Overview of migration project plan includingtarget migration completion date no later thanJune 30, 2016.



2.4 Maintain an inventory of system componentsthat are in scope for PCI DSS.

2.4.a Examine system inventory to verify that alist of hardware and software components ismaintained and includes a description offunction/use for each.

Google maintains inventory of of theinfrastructure underlying GCP products in scopefor PCI.


2.4.b Interview personnel to verify thedocumented inventory is kept current.

2.5 Ensure that security policies and operationalprocedures for managing vendor defaults andother security parameters are documented, inuse, and known to all affected parties.

2.5 Examine documentation and interviewpersonnel to verify that security policies andoperational procedures for managing vendordefaults and other security parameters are: * Documented, * In use, and * Known to all affected parties.

Google has implemented policies andprocedures that comply with requirements insection 2.5 for the infrastructure underlying GCPproducts in scope for PCI.

GCP customers are responsible for complyingwith this requirement for any virtual machines,applications, services or databases deployed bythem on GCP. Refer -https://cloud.google.com/docs/

2.6 Shared hosting providers must protect eachentity’s hosted environment and cardholderdata. These providers must meet specificrequirements as detailed in Appendix A:Additional PCI DSS Requirements for SharedHosting Providers.

2.6 Perform testing procedures A.1.1 throughA.1.4 detailed in Appendix A: Additional PCIDSS Requirements for Shared HostingProviders for PCI DSS assessments of sharedhosting providers, to verify that shared hostingproviders protect their entities’ (merchants andservice providers) hosted environment and data.

Compliance Covered in Appendix-A ControlsSection

N/A

3.1 Keep cardholder data storage to a minimumby implementing data retention and disposalpolicies, procedures and processes that includeat least the following for all cardholder data(CHD) storage: * Limiting data storage amount and retentiontime to that which is required for legal,regulatory, and business requirements * Processes for secure deletion of data whenno longer needed * Specific retention requirements for cardholderdata * A quarterly process for identifying andsecurely deleting stored cardholder data thatexceeds defined retention.

3.1.a Examine the data retention and disposalpolicies, procedures and processes to verifythey include at least the following: * Legal, regulatory, and business requirementsfor data retention, including * Specific requirements for retention ofcardholder data (for example, cardholder dataneeds to be held for X period for Y businessreasons). * Secure deletion of cardholder data when nolonger needed for legal, regulatory, or businessreasons * Coverage for all storage of cardholder data * A quarterly process for identifying andsecurely deleting stored cardholder data thatexceeds defined retention requirements.

N/A. It is outside of Google's scope of PCIassessment to comply with requirements ofsection 3 for any card holder data stored withinany customer instances on GCP.

GCP customers are responsible for meetingrequirements of section 3 for any card holderdata transmitted to or stored within theirinstances, applications or databases on GCP.

3.1.b Interview personnel to verify that: * All locations of stored cardholder data areincluded in the data retention and disposalprocesses. * Either a quarterly automatic or manualprocess is in place to identify and securelydelete stored cardholder data. * The quarterly automatic or manual process isperformed for all locations of cardholder data.



3.1.c For a sample of system components thatstore cardholder data: * Examine files and system records to verifythat the data stored does not exceed therequirements defined in the data retention policy * Observe the deletion mechanism to verifydata is deleted securely.



3.2 Do not store sensitive authentication dataafter authorization (even if encrypted). Ifsensitive authentication data is received, renderall data unrecoverable upon completion of theauthorization process.

It is permissible for issuers and companies thatsupport issuing services to store sensitiveauthentication data if: * There is a business justification and * The data is stored securely.

Sensitive authentication data includes the dataas cited in the following Requirements 3.2.1through 3.2.3:

3.2.a For issuers and/or companies that supportissuing services and store sensitiveauthentication data, review policies andinterview personnel to verify there is adocumented business justification for thestorage of sensitive authentication data.



3.2.b For issuers and/or companies that supportissuing services and store sensitiveauthentication data, examine data stores andsystem configurations to verify that the sensitiveauthentication data is secured.



3.2.c For all other entities, if sensitiveauthentication data is received, review policiesand procedures, and examine systemconfigurations to verify the data is not retainedafter authorization.



3.2.d For all other entities, if sensitiveauthentication data is received, reviewprocedures and examine the processes forsecurely deleting the data to verify that the datais unrecoverable.



3.2.1 Do not store the full contents of any track(from the magnetic stripe located on the back ofa card, equivalent data contained on a chip, orelsewhere) after authorization. This data isalternatively called full track, track, track 1, track2, and magnetic-stripe data.

Note: In the normal course of business, thefollowing data elements from the magnetic stripemay need to be retained: * The cardholder’s name * Primary account number (PAN) * Expiration date * Service code

To minimize risk, store only these data elementsas needed for business.

3.2.1 For a sample of system components,examine data sources including but not limitedto the following, and verify that the full contentsof any track from the magnetic stripe on theback of card or equivalent data on a chip are notstored 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 Do not store the card verification code orvalue (three-digit or four-digit number printed onthe front or back of a payment card used toverify card-not-present transactions) afterauthorization.

3.2.2 For a sample of system components,examine data sources, including but not limitedto the following, and verify that the three-digit orfour-digit card verification code or value printedon the front of the card or the signature panel(CVV2, CVC2, CID, CAV2 data) is not storedafter authorization: * Incoming transaction data * All logs (for example, transaction, history,debugging, error) * History files * Trace files * Several database schemas * Database contents.



3.2.3 Do not store the personal identificationnumber (PIN) or the encrypted PIN block afterauthorization.

3.2.3 For a sample of system components,examine data sources, including but not limitedto the following and verify that PINs andencrypted PIN blocks are not stored afterauthorization: * Incoming transaction data * All logs (for example, transaction, history,debugging, error) * History files * Trace files * Several database schemas * Database contents.



3.3 Mask PAN when displayed (the first six andlast four digits are the maximum number ofdigits to be displayed), such that only personnelwith a legitimate business need can see the fullPAN. Note: This requirement does notsupersede stricter requirements in place fordisplays of cardholder data —for example, legalor payment card brand requirements for point-of-sale (POS) receipts.

3.3.a Examine written policies and proceduresfor masking the display of PANs to verify: * A list of roles that need access to displays offull PAN is documented, together with alegitimate business need for each role to havesuch access. * PAN must be masked when displayed suchthat only personnel with a legitimate businessneed can see the full PAN. * All other roles not specifically authorized tosee the full PAN must only see masked PANs.



3.3.b Examine system configurations to verifythat full PAN is only displayed for users/roleswith a documented business need, and thatPAN is masked for all other requests.



3.3.c Examine displays of PAN (for example, onscreen, on paper receipts) to verify that PANsare masked when displaying cardholder data,and that only those with a legitimate businessneed are able to see full PAN.



3.4 Render PAN unreadable anywhere it isstored (including on portable digital media,backup media, and in logs) by using any of thefollowing approaches: * One-way hashes based on strongcryptography, (hash must be of the entire PAN) * Truncation (hashing cannot be used toreplace the truncated segment of PAN) * Index tokens and pads (pads must besecurely stored) * Strong cryptography with associated key-management processes and procedures.

Note: It is a relatively trivial effort for a maliciousindividual to reconstruct original PAN data if theyhave access to both the truncated and hashedversion of a PAN. Where hashed and truncatedversions of the same PAN are present in anentity’s environment, additional controls must bein place to ensure that the hashed and truncatedversions cannot be correlated to reconstruct theoriginal PAN.

3.4.a Examine documentation about the systemused to protect the PAN, including the vendor,type of system/process, and the encryptionalgorithms (if applicable) to verify that the PANis rendered unreadable using any of thefollowing methods: * One-way hashes based on strongcryptography, * Truncation * Index tokens and pads, with the pads beingsecurely stored * Strong cryptography, with associated key-management processes and procedures.



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



3.4.c Examine a sample of removable media (forexample, back-up tapes) to confirm that thePAN is rendered unreadable.



3.4.d Examine a sample of audit logs to confirmthat the PAN is rendered unreadable orremoved from the logs.



3.4.e If hashed and truncated versions of thesame PAN are present in the environment,examine implemented controls to verify that thehashed and truncated versions cannot becorrelated to reconstruct the original PAN.



3.4.1 If disk encryption is used (rather than file-or column-level database encryption), logicalaccess must be managed separately andindependently of native operating systemauthentication and access control mechanisms(for example, by not using local user accountdatabases or general network login credentials).Decryption keys must not be associated withuser accounts.

3.4.1.a If disk encryption is used, inspect theconfiguration and observe the authenticationprocess to verify that logical access to encryptedfile systems is implemented via a mechanismthat is separate from the native operatingsystem’s authentication mechanism (forexample, not using local user accountdatabases or general network login credentials).



3.4.1.b Observe processes and interviewpersonnel to verify that cryptographic keys arestored securely (for example, stored onremovable media that is adequately protectedwith strong access controls).



3.4.1.c Examine the configurations and observethe processes to verify that cardholder data onremovable media is encrypted wherever stored.Note: If disk encryption is not used to encryptremovable media, the data stored on this mediawill need to be rendered unreadable throughsome other method.



3.5 Document and implement procedures toprotect keys used to secure stored cardholderdata against disclosure and misuse:

Note: This requirement applies to keys used toencrypt stored cardholder data, and also appliesto key-encrypting keys used to protect data-encrypting keys — such key-encrypting keysmust be at least as strong as the data-encrypting key.

3.5 Examine key-management policies andprocedures to verify processes are specified toprotect keys used for encryption of cardholderdata against disclosure and misuse and includeat least the following: * Access to keys is restricted to the fewestnumber of custodians necessary. * Key-encrypting keys are at least as strong asthe data- encrypting keys they protect. * Key-encrypting keys are stored separatelyfrom data- encrypting keys. * Keys are stored securely in the fewestpossible locations and forms.

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

3.5.1 Examine user access lists to verify thataccess to keys is restricted to the fewestnumber of custodians necessary.



3.5.2 Store secret and private keys used toencrypt/decrypt cardholder data in one (or more)of the following forms at all times: * Encrypted with a key-encrypting key that is atleast as strong as the data-encrypting key, andthat is stored separately from the data-encrypting key * Within a secure cryptographic device (suchas a hardware (host) security module (HSM) orPTS-approved point-of-interaction device) * As at least two full-length key components orkey shares, in accordance with an industry-accepted method

Note: It is not required that public keys be storedin one of these forms.

3.5.2.a Examine documented procedures toverify that cryptographic keys used toencrypt/decrypt cardholder data must only existin one (or more) of the following forms at alltimes. * Encrypted with a key-encrypting key that is atleast as strong as the data-encrypting key, andthat is stored separately from the data-encrypting key * Within a secure cryptographic device (suchas a hardware (host) security module (HSM) orPTS-approved point-of- interaction device) * As key components or key shares, inaccordance with an industry-accepted method



3.5.2.b Examine system configurations and keystorage locations to verify that cryptographickeys used to encrypt/decrypt cardholder dataexist in one (or more) of the following form at alltimes. * Encrypted with a key-encrypting key * Within a secure cryptographic device (suchas a hardware (host) security module (HSM) orPTS-approved point-of- interaction device) * As key components or key shares, inaccordance with an industry-accepted method



3.5.2.c Wherever key-encrypting keys are used,examine system configurations and key storagelocations to verify: * Key-encrypting keys are at least as strong asthe data- encrypting keys they protect * Key-encrypting keys are stored separatelyfrom data- encrypting keys.



3.5.3 Store cryptographic keys in the fewestpossible locations.

3.5.3 Examine key storage locations andobserve processes to verify that keys are storedin the fewest possible locations.



3.6 Fully document and implement all key-management processes and procedures forcryptographic keys used for encryption ofcardholder data, including the following:

Note: Numerous industry standards for keymanagement are available from variousresources including NIST, which can be found athttp://csrc.nist.gov.

3.6.a Additional testing procedure for serviceproviders assessments only: If the serviceprovider shares keys with their customers fortransmission or storage of cardholder data,examine the documentation that the serviceprovider provides to their customers to verifythat it includes guidance on how to securelytransmit, store, and update customer s’ keys, inaccordance with Requirements 3.6.1 through3.6.8 below.



3.6.b Examine the key-management proceduresand processes for keys used for encryption ofcardholder data and perform the following:



3.6.1 Generation of strong cryptographic keys 3.6.1.a Verify that key-management proceduresspecify how to generate strong keys.



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



3.6.2 Secure cryptographic key distribution 3.6.2.a Verify that key-management proceduresspecify how to securely distribute keys.



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



3.6.3 Secure cryptographic key storage 3.6.3.a Verify that key-management proceduresspecify how to securely store keys.



GCP customers should store cryptographic keysoutside GCP; within GCP, they should storekeys only within GAE static file storage or GCEpersistent disk. Cryptographic keys storedelsewhere within GCP should be encrypted witha separate key-encrypting key.

3.6.3.b Observe the method for storing keys toverify that keys are stored securely.



3.6.4 Cryptographic key changes for keys thathave reached the end of their cryptoperiod (forexample, after a defined period of time haspassed and/or after a certain amount of cipher-text has been produced by a given key), asdefined by the associated application vendor orkey owner, and based on industry best practicesand guidelines (for example, NIST SpecialPublication 800-57).

3.6.4.a Verify that key-management proceduresinclude a defined cryptoperiod for each key typein use and define a process for key changes atthe end of the defined cryptoperiod(s).



3.6.4.b Interview personnel to verify that keysare changed at the end of the definedcryptoperiod(s).



3.6.5 Retirement or replacement (for example,archiving, destruction, and/or revocation) of keysas deemed necessary when the integrity of thekey has been weakened (for example, departureof an employee with knowledge of a clear-textkey component), or keys are suspected of beingcompromised. Note: If retired or replacedcryptographic keys need to be retained, thesekeys must be securely archived (for example, byusing a key-encryption key). Archivedcryptographic keys should only be used fordecryption/verification purposes.

3.6.5.a Verify that key-management proceduresspecify processes for the following: * The retirement or replacement of keys whenthe integrity of the key has been weakened * The replacement of known or suspectedcompromised keys. * Any keys retained after retiring or replacingare not used for encryption operations



3.6.5.b Interview personnel to verify thefollowing processes are implemented: * Keys are retired or replaced as necessarywhen the integrity of the key has beenweakened, including when someone withknowledge of the key leaves the company. * Keys are replaced if known or suspected tobe compromised. * Any keys retained after retiring or replacingare not used for encryption operations.



3.6.6 If manual clear-text cryptographic key-management operations are used, theseoperations must be managed using splitknowledge and dual control.

Note: Examples of manual key- managementoperations include, but are not limited to: keygeneration, transmission, loading, storage anddestruction.

3.6.6.a Verify that manual clear-text key-management procedures specify processes forthe use of the following: * Split knowledge of keys, such that keycomponents are under the control of at least twopeople who only have knowledge of their ownkey components; AND * Dual control of keys, such that at least twopeople are required to perform any key-management operations and no one person hasaccess to the authentication materials (forexample, passwords or keys) of another.



3.6.6 b Interview personnel and/or observeprocesses to verify that manual clear-text keysare managed with: * Split knowledge, AND * Dual control



3.6.7 Prevention of unauthorized substitution ofcryptographic keys.

3.6.7.a Verify that key-management proceduresspecify processes to prevent unauthorizedsubstitution of keys.



3.6.7.b Interview personnel and/or observeprocesses to verify that unauthorizedsubstitution of keys is prevented.



3.6.8 Requirement for cryptographic keycustodians to formally acknowledge that theyunderstand and accept their key-custodianresponsibilities.

3.6.8.a Verify that key-management proceduresspecify processes for key custodians toacknowledge (in writing or electronically) thatthey understand and accept their key- custodianresponsibilities.



3.6.8.b Observe documentation or otherevidence showing that key custodians haveacknowledged (in writing or electronically) thatthey understand and accept their key- custodianresponsibilities.



3.7 Ensure that security policies and operationalprocedures for protecting stored cardholder dataare documented, in use, and known to allaffected parties.

3.7 Examine documentation interview personnelto verify that security policies and operationalprocedures for protecting stored cardholder dataare: * Documented, * In use, and * Known to all affected parties.



4.1 Use strong cryptography and securityprotocols (for example, SSL/TLS, IPSEC, SSH,etc.) to safeguard sensitive cardholder dataduring transmission over open, public networks,including the following: * Only trusted keys and certificates areaccepted. * The protocol in use only supports secureversions or configurations. * The encryption strength is appropriate for theencryption methodology in use.

Examples of open, public networks include butare not limited to: * The Internet * Wireless technologies, including 802.11 andBluetooth * Cellular technologies, for example, GlobalSystem for Mobile communications (GSM),Code division multiple access (CDMA) * General Packet Radio Service (GPRS). * Satellite communications.

4.1.a Identify all locations where cardholder datais transmitted or received over open, publicnetworks. Examine documented standards andcompare to system configurations to verify theuse of security protocols and strongcryptography for all locations.

N/A, It is outside of Google's scope of PCIassessment to ensure that any inbound andoutbound transmission of payment card data aresecured in compliance with the requirements insection 4.

GCP customers are responsible for ensuringthat appropriate security protocols in compliancewith section 4 is implemented for alltransmission of CHD over public networks in toGCP.

4.1.b Review documented policies andprocedures to verify processes are specified forthe following: * For acceptance of only trusted keys and/orcertificates * For the protocol in use to only support secureversions and configurations (that insecureversions or configurations are not supported) * For implementation of proper encryptionstrength per the encryption methodology in use



4.1.c Select and observe a sample of inboundand outbound transmissions as they occur toverify that all cardholder data is encrypted withstrong cryptography during transit.



4.1.d Examine keys and certificates to verify thatonly trusted keys and/or certificates areaccepted.



4.1.e Examine system configurations to verifythat the protocol is implemented to use onlysecure configurations and does not supportinsecure versions or configurations.



4.1.f Examine system configurations to verifythat the proper encryption strength isimplemented for the encryption methodology inuse. (Check vendor recommendations/bestpractices.)



4.1.g For SSL/TLS implementations, examinesystem configurations to verify that SSL/TLS isenabled whenever cardholder data istransmitted or received. For example, forbrowser-based implementations: * “HTTPS” appears as the browser UniversalRecord Locator (URL) protocol, and * Cardholder data is only requested if “HTTPS”appears as part of the URL.



4.1.1 Ensure wireless networks transmittingcardholder data or connected to the cardholderdata environment, use industry best practices(for example, IEEE 802.11i) to implement strongencryption for authentication and transmission.

Note: The use of WEP as a security control isprohibited.

4.1.1 Identify all wireless networks transmittingcardholder data or connected to the cardholderdata environment. Examine documentedstandards and compare to system configurationsettings to verify the following for all wirelessnetworks identified: * Industry best practices (for example, IEEE802.11i) are used to implement strongencryption for authentication and transmission. * Weak encryption (for example, WEP, SSLversion 2.0 or older) is not used as a securitycontrol for authentication or transmission.



4.2 Never send unprotected PANs by end-usermessaging technologies (for example, e-mail,instant messaging, chat, etc.).

4.2.a If end-user messaging technologies areused to send cardholder data, observeprocesses for sending PAN and examine asample of outbound transmissions as they occurto verify that PAN is rendered unreadable orsecured with strong cryptography whenever it issent via end-user messaging technologies.



4.2.b Review written policies to verify theexistence of a policy stating that unprotectedPANs are not to be sent via end-user messagingtechnologies.



4.3 Ensure that security policies and operationalprocedures for encrypting transmissions ofcardholder data are documented, in use, andknown to all affected parties.

4.3 Examine documentation interview personnelto verify that security policies and operationalprocedures for encrypting transmissions ofcardholder data are: * Documented, * In use, and * Known to all affected parties.



5.1 Deploy anti-virus software on all systemscommonly affected by malicious software(particularly personal computers and servers).

5.1 For a sample of system componentsincluding all operating system types commonlyaffected by malicious software, verify that anti-virus software is deployed if applicable anti-virustechnology exists.

Google is responsible for implementation ofmalware protection in the infrastructureunderlying GCP in compliance with section 5requirements. Google is not responsible forimplementation of malware protection within anycustomer deployed instances on GCP.

GCP customers are responsible forimplementing malware protection on anycustomer deployed instances within GCP incompliance with section 5 requirements.

5.1.1 Ensure that anti-virus programs arecapable of detecting, removing, and protectingagainst all known types of malicious software.

5.1.1 Review vendor documentation andexamine anti-virus configurations to verify thatanti-virus programs; * Detect all known types of malicious software, * Remove all known types of malicioussoftware, and * Protect against all known types of malicioussoftware.

Examples of types of malicious software includeviruses, Trojans, worms, spyware, adware, androotkits.



5.1.2 For systems considered to be notcommonly affected by malicious software,perform periodic evaluations to identify andevaluate evolving malware threats in order toconfirm whether such systems continue to notrequire anti-virus software.

5.1.2 Interview personnel to verify that evolvingmalware threats are monitored and evaluatedfor systems not currently considered to becommonly affected by malicious software, inorder to confirm whether such systems continueto not require anti-virus software.



5.2 Ensure that all anti-virus mechanisms aremaintained as follows: * Are kept current, * Perform periodic scans * Generate audit logs which are retained perPCI DSS Requirement 10.7.

5.2.a Examine policies and procedures to verifythat anti-virus software and definitions arerequired to be kept up to date.



5.2.b Examine anti-virus configurations,including the master installation of the softwareto 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 commonlyaffected by malicious software, to verify that: * The anti-virus software and definitions arecurrent. * Periodic scans are performed.



5.2.d Examine anti-virus configurations,including the master installation of the softwareand a sample of system components, to verifythat: * Anti-virus software log generation is enabled,and * Logs are retained in accordance with PCIDSS Requirement 10.7.



5.3 Ensure that anti-virus mechanisms areactively running and cannot be disabled oraltered by users, unless specifically authorizedby management on a case-by-case basis for alimited time period.

Note: Anti-virus solutions may be temporarilydisabled only if there is legitimate technicalneed, as authorized by management on a case-by-case basis. If anti-virus protection needs tobe disabled for a specific purpose, it must beformally authorized. Additional securitymeasures may also need to be implemented forthe period of time during which anti-virusprotection is not active.

5.3.a Examine anti-virus configurations,including the master installation of the softwareand a sample of system components, to verifythe anti-virus software is actively running.



5.3.b Examine anti-virus configurations,including the master installation of the softwareand a sample of system components, to verifythat the anti-virus software cannot be disabledor altered by users.



5.3.c Interview responsible personnel andobserve processes to verify that anti-virussoftware cannot be disabled or altered by users,unless specifically authorized by managementon a case-by-case basis for a limited timeperiod.



5.4 Ensure that security policies and operationalprocedures for protecting systems againstmalware are documented, in use, and known toall affected parties.

5.4 Examine documentation and interviewpersonnel to verify that security policies andoperational procedures for protecting systemsagainst malware are: * Documented, * In use, and * Known to all affected parties.



6.1 Establish a process to identify securityvulnerabilities, using reputable outside sourcesfor security vulnerability information, and assigna risk ranking (for example, as “high,” “medium,”or “low”) to newly discovered securityvulnerabilities.

Note: Risk rankings should be based on industrybest practices as well as consideration ofpotential impact. For example, criteria forranking vulnerabilities may include considerationof the CVSS base score, and/or theclassification by the vendor, and/or type ofsystems affected.

Methods for evaluating vulnerabilities andassigning risk ratings will vary based on anorganization’s environment and risk-assessment strategy. Risk rankings should, at aminimum, identify all vulnerabilities consideredto be a “high risk” to the environment. In additionto the risk ranking, vulnerabilities may beconsidered “critical” if they pose an imminentthreat to the environment, impact criticalsystems, and/or would result in a potentialcompromise if not addressed. Examples ofcritical systems may include security systems,public-facing devices and systems, databases,and other systems that store, process, ortransmit cardholder data.

6.1.a Examine policies and procedures to verifythat processes are defined for the following: * To identify new security vulnerabilities * To assign a risk ranking to vulnerabilities thatincludes identification of all “high risk” and“critical” vulnerabilities. * To use reputable outside sources for securityvulnerability information.

Google is responsible for protecting the systemsand infrastructure underlying GCP fromvulnerabilities in compliance with therequirements in section 6.

GCP customers are responsible for protectingcustomer deployed instances and software onGCP from vulnerabilities in compliance withsection 6 requirements.

6.1.b Interview responsible personnel andobserve processes to verify that: * New security vulnerabilities are identified. * A risk ranking is assigned to vulnerabilitiesthat includes identification of all “high” risk and“critical” vulnerabilities. * Processes to identify new securityvulnerabilities include using reputable outsidesources for security vulnerability information.



6.2 Ensure that all system components andsoftware are protected from knownvulnerabilities by installing applicable vendor-supplied security patches. Install critical securitypatches within one month of release.

Note: Critical security patches should beidentified according to the risk ranking processdefined in Requirement 6.1.

6.2.a Examine policies and procedures relatedto security- patch installation to verify processesare defined for: * Installation of applicable critical vendor-supplied security patches within one month ofrelease. * Installation of all applicable vendor-suppliedsecurity patches within an appropriate timeframe (for example, within three months).



6.2.b For a sample of system components andrelated software, compare the list of securitypatches installed on each system to the mostrecent vendor security-patch list, to verify thefollowing: * That applicable critical vendor-suppliedsecurity patches are installed within one monthof release. * All applicable vendor-supplied securitypatches are installed within an appropriate timeframe (for example, within three months).



6.3 Develop internal and external softwareapplications (including web-based administrativeaccess to applications) securely, as follows: * In accordance with PCI DSS (for example,secure authentication and logging) * Based on industry standards and/or bestpractices. * Incorporating information security throughoutthe software-development life cycle

Note: this applies to all software developedinternally as well as bespoke or custom softwaredeveloped by a third party.

6.3.a Examine written software-developmentprocesses to verify that the processes are basedon industry standards and/or best practices.



6.3.b Examine written software-developmentprocesses to verify that information security isincluded throughout the life cycle.



6.3.c Examine written software-developmentprocesses to verify that software applicationsare developed in accordance with PCI DSS.



6.3.d Interview software developers to verify thatwritten software-development processes areimplemented.



6.3.1 Remove development, test and/or customapplication accounts, user IDs, and passwordsbefore applications become active or arereleased to customers.

6.3.1 Examine written software-developmentprocedures and interview responsible personnelto verify that pre- production and/or customapplication accounts, user IDs and/or passwordsare removed before an application goes intoproduction or is released to customers.



6.3.2 Review custom code prior to release toproduction or customers in order to identify anypotential coding vulnerability (using eithermanual or automated processes) to include atleast the following: * Code changes are reviewed by individualsother than the originating code author, and byindividuals knowledgeable about code-reviewtechniques and secure coding practices. * Code reviews ensure code is developedaccording to secure coding guidelines * Appropriate corrections are implementedprior to release. * Code-review results are reviewed andapproved by management prior to release.

Note: This requirement for code reviews appliesto all custom code (both internal and public-facing), as part of the system development lifecycle. Code reviews can be conducted byknowledgeable internal personnel or thirdparties. Public-facing web applications are alsosubject to additional controls, to addressongoing threats and vulnerabilities afterimplementation, as defined at PCI DSSRequirement 6.6.

6.3.2.a Examine written software-developmentprocedures and interview responsible personnelto verify that all custom application codechanges must be reviewed (using either manualor automated processes) as follows: * Code changes are reviewed by individualsother than the originating code author, and byindividuals who are knowledgeable in code-review techniques and secure coding practices. * Code reviews ensure code is developedaccording to secure coding guidelines (see PCIDSS Requirement 6.5). * Appropriate corrections are implementedprior to release. * Code-review results are reviewed andapproved by management prior to release.



6.3.2.b Select a sample of recent customapplication changes and verify that customapplication code is reviewed according to6.3.2.a, above.



6.4 Follow change control processes andprocedures for all changes to systemcomponents. The processes must include thefollowing:

6.4 Examine policies and procedures to verifythe following are defined: * Development/test environments are separatefrom production environments with accesscontrol in place to enforce separation. * A separation of duties between personnelassigned to the development/test environmentsand those assigned to the productionenvironment. * Production data (live PANs) are not used fortesting or development. * Test data and accounts are removed before aproduction system becomes active. * Change control procedures related toimplementing security patches and softwaremodifications are documented.

6.4.1 Separate development/test environmentsfrom production environments, and enforce theseparation with access controls.

6.4.1.a Examine network documentation andnetwork device configurations to verify that thedevelopment/test environments are separatefrom the production environment(s).



6.4.1.b Examine access controls settings toverify that access controls are in place toenforce separation between thedevelopment/test environments and theproduction environment(s).



6.4.2 Separation of duties betweendevelopment/test and production environments

6.4.2 Observe processes and interviewpersonnel assigned to development/testenvironments and personnel assigned toproduction environments to verify thatseparation of duties is in place betweendevelopment/test environments and theproduction environment.



6.4.3 Production data (live PANs) are not usedfor testing or development

6.4.3.a Observe testing processes and interviewpersonnel to verify procedures are in place toensure production data (live PANs) are not usedfor testing or development.

6.4.3.b Examine a sample of test data to verifyproduction data (live PANs) is not used fortesting or development.



6.4.4 Removal of test data and accounts beforeproduction systems become active

6.4.4.a Observe testing processes and interviewpersonnel to verify test data and accounts areremoved before a production system becomesactive.

6.4.4.b Examine a sample of data and accountsfrom production systems recently installed orupdated to verify test data and accounts areremoved before the system becomes active.



6.4.5 Change control procedures for theimplementation of security patches and softwaremodifications must include the following:

6.4.5.a Examine documented change controlprocedures related to implementing securitypatches and software modifications and verifyprocedures are defined for: * Documentation of impact * Documented change approval by authorizedparties * Functionality testing to verify that the changedoes not adversely impact the security of thesystem * Back-out procedures



6.4.5.b For a sample of system components,interview responsible personnel to determinerecent changes/security patches. Trace thosechanges back to related change controldocumentation. For each change examined,perform the following:

6.4.5.1 Documentation of impact. 6.4.5.1 Verify that documentation of impact isincluded in the change control documentationfor each sampled change.



6.4.5.2 Documented change approval byauthorized parties.

6.4.5.2 Verify that documented approval byauthorized parties is present for each sampledchange.



6.4.5.3 Functionality testing to verify that thechange does not adversely impact the securityof the system.

6.4.5.3.a For each sampled change, verify thatfunctionality testing is performed to verify thatthe change does not adversely impact thesecurity of the system.



6.4.5.3.b For custom code changes, verify thatall updates are tested for compliance with PCIDSS Requirement 6.5 before being deployedinto production.



6.4.5.4 Back-out procedures. 6.4.5.4 Verify that back-out procedures areprepared for each sampled change.



6.5 Address common coding vulnerabilities insoftware-development processes as follows: * Train developers in secure codingtechniques, including how to avoid commoncoding vulnerabilities, and understanding howsensitive data is handled in memory. * Develop applications based on secure codingguidelines.

Note: The vulnerabilities listed at 6.5.1 through6.5.10 were current with industry best practiceswhen this version of PCI DSS was published.However, as industry best practices forvulnerability management are updated (forexample, the OWASP Guide, SANS CWE Top25, CERT Secure Coding, etc.), the current bestpractices must be used for these requirements.

6.5.a Examine software-development policiesand procedures to verify that training in securecoding techniques is required for developers,based on industry best practices and guidance.



6.5.b Interview a sample of developers to verifythat they are knowledgeable in secure codingtechniques



6.5.c Examine records of training to verify thatsoftware developers received training on securecoding techniques, including how to avoidcommon coding vulnerabilities, andunderstanding how sensitive data is handled inmemory.



6.5.d. Verify that processes are in place toprotect applications from, at a minimum, thefollowing vulnerabilities:

6.5.1 Injection flaws, particularly SQL injection.Also consider OS Command Injection, LDAPand XPath injection flaws as well as otherinjection flaws.

6.5.1 Examine software-development policiesand procedures and interview responsiblepersonnel to verify that injection flaws areaddressed by coding techniques that include: * Validating input to verify user data cannotmodify meaning of commands and queries. * Utilizing parameterized queries.



6.5.2 Buffer overflows 6.5.2 Examine software-development policiesand procedures and interview responsiblepersonnel to verify that buffer overflows areaddressed by coding techniques that include: * Validating buffer boundaries. * Truncating input strings.



6.5.3 Insecure cryptographic storage 6.5.3 Examine software-development policiesand procedures and interview responsiblepersonnel to verify that insecure cryptographicstorage is addressed by coding techniques that: * Prevent cryptographic flaws. * Use strong cryptographic algorithms andkeys.



6.5.4 Insecure communications 6.5.4 Examine software-development policiesand procedures and interview responsiblepersonnel to verify that insecurecommunications are addressed by codingtechniques that properly authenticate andencrypt all sensitive communications.



6.5.5 Improper error handling 6.5.5 Examine software-development policiesand procedures and interview responsiblepersonnel to verify that improper error handlingis addressed by coding techniques that do notleak information via error messages (forexample, by returning generic rather thanspecific error details.



6.5.6 All “high risk” vulnerabilities identified inthe vulnerability identification process (asdefined in PCI DSS Requirement 6.1).

6.5.6 Examine software-development policiesand procedures and interview responsiblepersonnel to verify that coding techniquesaddress any “high risk” vulnerabilities that couldaffect the application, as identified in PCI DSSRequirement 6.1.



6.5.7 Cross-site scripting (XSS) 6.5.7 Examine software-development policiesand procedures and interview responsiblepersonnel to verify that cross-site scripting(XSS) is addressed by coding techniques thatinclude * Validating all parameters before inclusion * Utilizing context-sensitive escaping.



6.5.8 Improper access control (such as insecuredirect object references, failure to restrict URLaccess, directory traversal, and failure to restrictuser access to functions).

6.5.8 Examine software-development policiesand procedures and interview responsiblepersonnel to verify that improper access control—such as insecure direct object references,failure to restrict URL access, and directorytraversal —is addressed by coding techniquethat includes: * Proper authentication of users * Sanitizing input * Not exposing internal object references tousers * User interfaces that do not permit access tounauthorized functions.



6.5.9 Cross-site request forgery (CSRF) 6.5.9 Examine software development policiesand procedures and interview responsiblepersonnel to verify that cross-site requestforgery (CSRF) is addressed by codingtechniques that ensure applications do not relyon authorization credentials and tokensautomatically submitted by browsers.



6.5.10 Broken authentication and sessionmanagement

Note: Requirement 6.5.10 is a best practice untilJune 30, 2015, after which it becomes arequirement.

6.5.10 Examine software development policiesand procedures and interview responsiblepersonnel to verify that broken authenticationand session management are addressed viacoding techniques that commonly include: * Flagging session tokens (for examplecookies) as “secure” * Not exposing session IDs in the URL * Incorporating appropriate time-outs androtation of session IDs after a successful login.



6.6 For public-facing web applications, addressnew threats and vulnerabilities on an ongoingbasis and ensure these applications areprotected against known attacks by either of thefollowing methods: * Reviewing public-facing web applications viamanual or automated application vulnerabilitysecurity assessment tools or methods, at leastannually and after any changes Note: This assessment is not the same as thevulnerability scans performed for Requirement11.2. * Installing an automated technical solution thatdetects and prevents web-based attacks (forexample, a web-application firewall) in front ofpublic-facing web applications, to continuallycheck all traffic.

6.6 For public-facing web applications, ensurethat either one of the following methods is inplace as follows: * Examine documented processes, interviewpersonnel, and examine records of applicationsecurity assessments to verify that public-facingweb applications are reviewed —using eithermanual or automated vulnerability securityassessment tools or methods —as follows: - At least annually - After any changes - By an organization that specializes inapplication security - That, at a minimum, all vulnerabilities inRequirement 6.5 are included in the assessment - That all vulnerabilities are corrected - That the application is re-evaluated after thecorrections.

* Examine the system configuration settingsand interview responsible personnel to verifythat an automated technical solution that detectsand prevents web-based attacks (for example, aweb-application firewall) is in place as follows: - Is situated in front of public-facing webapplications to detect and prevent web-basedattacks. - Is actively running and up to date asapplicable. - Is generating audit logs. - Is configured to either block web-basedattacks, or generate an alert.



6.7 Ensure that security policies and operationalprocedures for developing and maintainingsecure systems and applications aredocumented, in use, and known to all affectedparties.

6.7 Examine documentation and interviewpersonnel to verify that security policies andoperational procedures for developing andmaintaining secure systems and applicationsare: * Documented, * In use, and * Known to all affected parties.



7.1 Limit access to system components andcardholder data to only those individuals whosejob requires such access.

7.1 Examine written policy for access control,and verify that the policy incorporates 7.1.1through 7.1.4 as follows: * Defining access needs and privilegeassignments for each role * Restriction of access to privileged user IDs toleast privileges necessary to perform jobresponsibilities * Assignment of access based on individualpersonnel’s job classification and function * Documented approval (electronically or inwriting) by authorized parties for all access,including listing of specific privileges approved.

Google provides apps for work customers theability manage user accounts and passwordsrequirements which can be leveraged bycustomers in relation to section 7 and 8 of thestandard. Refer -https://support.google.com/a/topic/14588?hl=en&ref_topic=2425090

7.1.1 Define access needs for each role,including: * System components and data resources thateach role needs to access for their job function * Level of privilege required (for example, user,administrator, etc.) for accessing resources.

7.1.1 Select a sample of roles and verify accessneeds for each role are defined and include: * System components and data resources thateach role needs to access for their job function * Identification of privilege necessary for eachrole to perform their job function.

Google is responsible for implementing accesscontrols in compliance with requirements ofsection 7 and 8 for the systems andinfrastructure underlying GCP.

GCP customers are responsible forimplementing access controls on customerinstances and applications in compliance withsection 7 and 8 requirements.

7.1.2 Restrict access to privileged user IDs toleast privileges necessary to perform jobresponsibilities.

7.1.2.a Interview personnel responsible forassigning access to verify that access toprivileged user IDs is: * Assigned only to roles that specifically requiresuch privileged access * Restricted to least privileges necessary toperform job responsibilities.



7.1.2.b Select a sample of user IDs withprivileged access and interview responsiblemanagement personnel to verify that privilegesassigned are: * Necessary for that individual’s job function * Restricted to least privileges necessary toperform job responsibilities.



7.1.3 Assign access based on individualpersonnel’s job classification and function.

7.1.3 Select a sample of user IDs and interviewresponsible management personnel to verifythat privileges assigned are based on thatindividual’s job classification and function.



7.1.4 Require documented approval byauthorized parties specifying required privileges.

7.1.4 Select a sample of user IDs and comparewith documented approvals to verify that: * Documented approval exists for the assignedprivileges * The approval was by authorized parties * That specified privileges match the rolesassigned to the individual.



7.2 Establish an access control system forsystems components that restricts access basedon a user’s need to know, and is set to “deny all”unless specifically allowed. This access controlsystem must include the following:

7.2 Examine system settings and vendordocumentation to verify that an access controlsystem is implemented as follows:

7.2.1 Coverage of all system components 7.2.1 Confirm that access control systems are inplace on all system components.



7.2.2 Assignment of privileges to individualsbased on job classification and function.

7.2.2 Confirm that access control systems areconfigured to enforce privileges assigned toindividuals based on job classification andfunction.



7.2.3 Default “deny-all” setting. 7.2.3 Confirm that the access control systemshave a default “deny-all” setting.



7.3 Ensure that security policies and operationalprocedures for restricting access to cardholderdata are documented, in use, and known to allaffected parties.

7.3 Examine documentation interview personnelto verify that security policies and operationalprocedures for restricting access to cardholderdata are: * Documented, * In use, and * Known to all affected parties.



8.1 Define and implement policies andprocedures to ensure proper user identificationmanagement for non- consumer users andadministrators on all system components asfollows:

8.1.a Review procedures and confirm theydefine processes for each of the items below at8.1.1 through 8.1.8



8.1.b Verify that procedures are implemented foruser identification management, by performingthe following:

8.1.1 Assign all users a unique ID beforeallowing them to access system components orcardholder data.

8.1.1 Interview administrative personnel toconfirm that all users are assigned a unique IDfor access to system components or cardholderdata.



8.1.2 Control addition, deletion, and modificationof user IDs, credentials, and other identifierobjects.

8.1.2 For a sample of privileged user IDs andgeneral user IDs, examine associatedauthorizations and observe system settings toverify each user ID and privileged user ID hasbeen implemented with only the privilegesspecified on the documented approval.



8.1.3 Immediately revoke access for anyterminated users.

8.1.3.a Select a sample of users terminated inthe past six months, and review current useraccess lists —for both local and remote access—to verify that their IDs have been deactivatedor removed from the access lists.



8.1.3.b Verify all physical authenticationmethods —such as, smart cards, tokens, etc.—have been returned or deactivated.



8.1.4 Remove/disable inactive user accountswithin 90 days.

8.1.4 Observe user accounts to verify that anyinactive accounts over 90 days old are eitherremoved or disabled.



8.1.5 Manage IDs used by vendors to access,support, or maintain system components viaremote access as follows: * Enabled only during the time period neededand disabled when not in use. * Monitored when in use.

8.1.5.a Interview personnel and observeprocesses for managing accounts used byvendors to access, support, or maintain systemcomponents to verify that accounts used byvendors for remote access are: * Disabled when not in use * Enabled only when needed by the vendor,and disabled when not in use.



8.1.5.b Interview personnel and observeprocesses to verify that vendor remote accessaccounts are monitored while being used.



8.1.6 Limit repeated access attempts by lockingout the user ID after not more than six attempts.

8.1.6.a For a sample of system components,inspect system configuration settings to verifythat authentication parameters are set to requirethat user accounts be locked out after not morethan six invalid logon attempts.



8.1.6.b Additional testing procedure for serviceprovider assessments only: Review internalprocesses and customer/user documentation,and observe implemented processes to verifythat non- consumer user accounts aretemporarily locked-out after not more than sixinvalid access attempts.


N/A

8.1.7 Set the lockout duration to a minimum of30 minutes or until an administrator enables theuser ID.

8.1.7 For a sample of system components,inspect system configuration settings to verifythat password parameters are set to require thatonce a user account is locked out, it remainslocked for a minimum of 30 minutes or until asystem administrator resets the account.



8.1.8 If a session has been idle for more than 15minutes, require the user to re-authenticate tore-activate the terminal or session.

8.1.8 For a sample of system components,inspect system configuration settings to verifythat system/session idle time out features havebeen set to 15 minutes or less.



8.2 In addition to assigning a unique ID, ensureproper user-authentication management for non-consumer users and administrators on allsystem components by employing at least oneof the following methods to authenticate allusers: * Something you know, such as a password orpassphrase * Something you have, such as a token deviceor smart card * Something you are, such as a biometric.

8.2 To verify that users are authenticated usingunique ID and additional authentication (forexample, a password/phrase) for access to thecardholder data environment, perform thefollowing: * Examine documentation describing theauthentication method(s) used. * For each type of authentication method usedand for each type of system component,observe an authentication to verifyauthentication is functioning consistent withdocumented authentication method(s).



8.2.1 Using strong cryptography, render allauthentication credentials (such aspasswords/phrases) unreadable duringtransmission and storage on all systemcomponents.

8.2.1.a Examine vendor documentation andsystem configuration settings to verify thatpasswords are protected with strongcryptography during transmission and storage.



8.2.1.b For a sample of system components,examine password files to verify that passwordsare unreadable during storage.



8.2.1.c For a sample of system components,examine data transmissions to verify thatpasswords are unreadable during transmission.



8.2.1.d Additional testing procedure for serviceprovider assessments only: Observe passwordfiles to verify that customer passwords areunreadable during storage.


N/A

8.2.1.e Additional testing procedure for serviceprovider assessments only: Observe datatransmissions to verify that customer passwordsare unreadable during transmission.


N/A

8.2.2 Verify user identity before modifying anyauthentication credential —for example,performing password resets, provisioning newtokens, or generating new keys.

8.2.2 Examine authentication procedures formodifying authentication credentials andobserve security personnel to verify that, if auser requests a reset of an authenticationcredential by phone, e-mail, web, or other non-face-to-face method, the user’s identity isverified before the authentication credential ismodified.



8.2.3 Passwords/phrases must meet thefollowing: * Require a minimum length of at least sevencharacters. * Contain both numeric and alphabeticcharacters.

Alternatively, the passwords/phrases must havecomplexity and strength at least equivalent tothe parameters specified above.

8.2.3a For a sample of system components,inspect system configuration settings to verifythat user password parameters are set torequire at least the followingstrength/complexity: * Require a minimum length of at least sevencharacters. * Contain both numeric and alphabeticcharacters.



8.2.3.b Additional testing procedure for serviceprovider assessments only: Review internalprocesses and customer/user documentation toverify that non-consumer user passwords arerequired to meet at least the followingstrength/complexity: * Require a minimum length of at least sevencharacters. * Contain both numeric and alphabeticcharacters.


N/A

8.2.4 Change user passwords/passphrases atleast once every 90 days.

8.2.4.a For a sample of system components,inspect system configuration settings to verifythat user password parameters are set torequire users to change passwords at least onceevery 90 days.



8.2.4.b Additional testing procedure for serviceprovider assessments only: Review internalprocesses and customer/user documentation toverify that: * Non-consumer user passwords are requiredto change periodically; and * Non-consumer users are given guidance asto when, and under what circumstances,passwords must change.


N/A

8.2.5 Do not allow an individual to submit a newpassword/phrase that is the same as any of thelast four passwords/phrases he or she has used.

8.2.5.a For a sample of system components,obtain and inspect system configuration settingsto verify that password parameters are set torequire that new passwords cannot be the sameas the four previously used passwords.



8.2.5.b Additional testing procedure for serviceprovider assessments only: Review internalprocesses and customer/user documentation toverify that new non-consumer user passwordscannot be the same as the previous fourpasswords.


N/A

8.2.6 Set passwords/phrases for first- time useand upon reset to a unique value for each user,and change immediately after the first use.

8.2.6 Examine password procedures andobserve security personnel to verify that first-time passwords for new users, and resetpasswords for existing users, are set to a uniquevalue for each user and changed after first use.



8.3 Incorporate two-factor authentication forremote network access originating from outsidethe network by personnel (including users andadministrators) and all third parties, (includingvendor access for support or maintenance).

Note: Two-factor authentication requires thattwo of the three authentication methods (seeRequirement 8.2 for descriptions ofauthentication methods) be used forauthentication. Using one factor twice (forexample, using two separate passwords) is notconsidered two-factor authentication.

Examples of two-factor technologies includeremote authentication and dial-in service(RADIUS) with tokens; terminal accesscontroller access control system (TACACS) withtokens; and other technologies that facilitatetwo-factor authentication.

8.3.a Examine system configurations for remoteaccess servers and systems to verify two-factorauthentication is required for: * All remote access by personnel * All third-party/vendor remote access(including access to applications and systemcomponents for support or maintenancepurposes).



8.3.b Observe a sample of personnel (forexample, users and administrators) connectingremotely to the network and verify that at leasttwo of the three authentication methods areused.



8.4 Document and communicate authenticationprocedures and policies to all users including: * Guidance on selecting strong authenticationcredentials * Guidance for how users should protect theirauthentication credentials * Instructions not to reuse previously usedpasswords * Instructions to change passwords if there isany suspicion the password could becompromised.

8.4.a Examine procedures and interviewpersonnel to verify that authenticationprocedures and policies are distributed to allusers.



8.4.b Review authentication procedures andpolicies that are distributed to users and verifythey include: * Guidance on selecting strong authenticationcredentials * Guidance for how users should protect theirauthentication credentials. * Instructions for users not to reuse previouslyused passwords * Instructions to change passwords if there isany suspicion the password could becompromised.



8.4.c Interview a sample of users to verify thatthey are familiar with authentication proceduresand policies.



8.5 Do not use group, shared, or generic IDs,passwords, or other authentication methods asfollows: * Generic user IDs are disabled or removed. * Shared user IDs do not exist for systemadministration and other critical functions. * Shared and generic user IDs are not used toadminister any system components.

8.5.a For a sample of system components,examine user ID lists to verify the following: * Generic user IDs are disabled or removed. * Shared user IDs for system administrationactivities and other critical functions do not exist. * Shared and generic user IDs are not used toadminister any system components.



8.5.b Examine authenticationpolicies/procedures to verify that use of groupand shared IDs and/or passwords or otherauthentication methods are explicitly prohibited.



8.5.c Interview system administrators to verifythat group and shared IDs and/or passwords orother authentication methods are not distributed,even if requested.



8.5.1 Additional requirement for serviceproviders only: Service providers with remoteaccess to customer premises (for example, forsupport of POS systems or servers) must use aunique authentication credential (such as apassword/phrase) for each customer.

Note: This requirement is not intended to applyto shared hosting providers accessing their ownhosting environment, where multiple customerenvironments are hosted.

Note: Requirement 8.5.1 is a best practice untilJune 30, 2015, after which it becomes arequirement.

8.5.1 Additional testing procedure for serviceprovider assessments only: Examineauthentication policies and procedures andinterview personnel to verify that differentauthentication are used for access to eachcustomer.


N/A

8.6 Where other authentication mechanisms areused (for example, physical or logical securitytokens, smart cards, certificates, etc.), use ofthese mechanisms must be assigned as follows: * Authentication mechanisms must beassigned to an individual account and notshared among multiple accounts. * Physical and/or logical controls must be inplace to ensure only the intended account canuse that mechanism to gain access.

8.6.a Examine authentication policies andprocedures to verify that procedures for usingauthentication mechanisms such as physicalsecurity tokens, smart cards, and certificates aredefined and include: * Authentication mechanisms are assigned toan individual account and not shared amongmultiple accounts. * Physical and/or logical controls are defined toensure only the intended account can use thatmechanism to gain access.



8.6.b Interview security personnel to verifyauthentication mechanisms are assigned to anaccount and not shared among multipleaccounts.



8.6.c Examine system configuration settingsand/or physical controls, as applicable, to verifythat controls are implemented to ensure only theintended account can use that mechanism togain access.



8.7 All access to any database containingcardholder data (including access byapplications, administrators, and all other users)is restricted as follows: * All user access to, user queries of, and useractions on databases are through programmaticmethods. * Only database administrators have the abilityto directly access or query databases. * Application IDs for database applications canonly be used by the applications (and not byindividual users or other non-applicationprocesses).

8.7.a Review database and applicationconfiguration settings and verify that all usersare authenticated prior to access.



8.7.b Examine database and applicationconfiguration settings to verify that all useraccess to, user queries of, and user actions on(for example, move, copy, delete), the databaseare through programmatic methods only (forexample, through stored procedures).



8.7.c Examine database access control settingsand database application configuration settingsto verify that user direct access to or queries ofdatabases are restricted to databaseadministrators.



8.7.d Examine database access control settings,database application configuration settings, andthe related application IDs to verify thatapplication IDs can only be used by theapplications (and not by individual users or otherprocesses).



8.8 Ensure that security policies and operationalprocedures for identification and authenticationare documented, in use, and known to allaffected parties.

8.8 Examine documentation interview personnelto verify that security policies and operationalprocedures for identification and authenticationare: * Documented, * In use, and * Known to all affected parties.



9.1 Use appropriate facility entry controls to limitand monitor physical access to systems in thecardholder data environment.

9.1 Verify the existence of physical securitycontrols for each computer room, data center,and other physical areas with systems in thecardholder data environment. * Verify that access is controlled with badgereaders or other devices including authorizedbadges and lock and key. * Observe a system administrator’s attempt tolog into consoles for randomly selected systemsin the cardholder environment and verify thatthey are “locked” to prevent unauthorized use.

Google is responsible for physical securitycontrols on all Google Data centers underlyingGCP.

N/A

9.1.1 Use video cameras and/or access controlmechanisms to monitor individual physicalaccess to sensitive areas. Review collected dataand correlate with other entries. Store for atleast three months, unless otherwise restrictedby law.

Note: “Sensitive areas” refers to any datacenter, server room or any area that housessystems that store, process, or transmitcardholder data. This excludes public-facingareas where only point-of- sale terminals arepresent, such as the cashier areas in a retailstore.

9.1.1.a Verify that video cameras and/or accesscontrol mechanisms are in place to monitor theentry/exit points to sensitive areas.


N/A

9.1.1.b Verify that video cameras and/or accesscontrol mechanisms are protected fromtampering or disabling.


N/A

9.1.1.c Verify that video cameras and/or accesscontrol mechanisms are monitored and that datafrom cameras or other mechanisms is stored forat least three months.


N/A

9.1.2 Implement physical and/or logical controlsto restrict access to publicly accessible networkjacks.

For example, network jacks located in publicareas and areas accessible to visitors could bedisabled and only enabled when network accessis explicitly authorized. Alternatively, processescould be implemented to ensure that visitors areescorted at all times in areas with active networkjacks.

9.1.2 Interview responsible personnel andobserve locations of publicly accessible networkjacks to verify that physical and/or logicalcontrols are in place to restrict access to publiclyaccessible network jacks.


N/A

9.1.3 Restrict physical access to wirelessaccess points, gateways, handheld devices,networking/communications hardware, andtelecommunication lines.

9.1.3 Verify that physical access to wirelessaccess points, gateways, handheld devices,networking/communications hardware, andtelecommunication lines is appropriatelyrestricted.


N/A

9.2 Develop procedures to easily distinguishbetween onsite personnel and visitors, toinclude: * Identifying onsite personnel and visitors (forexample, assigning badges) * Changes to access requirements * Revoking or terminating onsite personnel andexpired visitor identification (such as ID badges).

9.2.a Review documented processes to verifythat procedures are defined for identifying anddistinguishing between onsite personnel andvisitors. Verify procedures include the following: * Identifying new onsite personnel or visitors(for example, assigning badges), * Changing access requirements, and * Revoking terminated onsite personnel andexpired visitor identification (such as ID badges)


N/A

9.2.b Examine identification methods (such asID badges) and observe processes foridentifying and distinguishing between onsitepersonnel and visitors to verify that: * Visitors are clearly identified, and * It is easy to distinguish between onsitepersonnel and visitors.


N/A

9.2.c Verify that access to the identificationprocess (such as a badge system) is limited toauthorized personnel.


N/A

9.3 Control physical access for onsite personnelto the sensitive areas as follows: * Access must be authorized and based onindividual job function. * Access is revoked immediately upontermination, and all physical accessmechanisms, such as keys, access cards, etc.,are returned or disabled.

9.3.a For a sample of onsite personnel withphysical access to the CDE, interviewresponsible personnel and observe accesscontrol lists to verify that: * Access to the CDE is authorized. * Access is required for the individual’s jobfunction.


N/A

9.3.b Observe personnel access the CDE toverify that all personnel are authorized beforebeing granted access.


N/A

9.3.c Select a sample of recently terminatedemployees and review access control lists toverify the personnel do not have physical accessto the CDE.


N/A

9.4 Implement procedures to identify andauthorize visitors. Procedures should include thefollowing:

9.4 Verify that visitor authorization and accesscontrols are in place as follows:

9.4.1 Visitors are authorized before entering,and escorted at all times within, areas wherecardholder data is processed or maintained.

9.4.1.a Observe procedures and interviewpersonnel to verify that visitors must beauthorized before they are granted access to,and escorted at all times within, areas wherecardholder data is processed or maintained.


N/A

9.4.1.b Observe the use of visitor badges orother identification to verify that a physical tokenbadge does not permit unescorted access tophysical areas where cardholder data isprocessed or maintained.


N/A

9.4.2 Visitors are identified and given a badge orother identification that expires and that visiblydistinguishes the visitors from onsite personnel.

9.4.2.a Observe people within the facility toverify the use of visitor badges or otheridentification, and that visitors are easilydistinguishable from onsite personnel.


N/A

9.4.2.b Verify that visitor badges or otheridentification expire.


N/A

9.4.3 Visitors are asked to surrender the badgeor identification before leaving the facility or atthe date of expiration.

9.4.3 Observe visitors leaving the facility toverify visitors are asked to surrender their badgeor other identification upon departure orexpiration.


N/A

9.4.4 A visitor log is used to maintain a physicalaudit trail of visitor activity to the facility as wellas computer rooms and data centers wherecardholder data is stored or transmitted.Document the visitor’s name, the firmrepresented, and the onsite personnelauthorizing physical access on the log. Retainthis log for a minimum of three months, unlessotherwise restricted by law.

9.4.4.a Verify that a visitor log is in use to recordphysical access to the facility as well ascomputer rooms and data centers wherecardholder data is stored or transmitted.


N/A

9.4.4.b Verify that the log contains: * The visitor’s name, * The firm represented, and * The onsite personnel authorizing physicalaccess.


N/A

9.4.4.c Verify that the log is retained for at leastthree months.


N/A

9.5 Physically secure all media. 9.5 Verify that procedures for protectingcardholder data include controls for physicallysecuring all media (including but not limited tocomputers, removable electronic media, paperreceipts, paper reports, and faxes).

Google is responsible for physical securitycontrols on all Google Data Centers underlyingGCP and backups that are performed andmaintained by Google.

GCP customers are responsible for the securityof any backups that are stored outside of GCP.

9.5.1 Store media backups in a secure location,preferably an off-site facility, such as analternate or backup site, or a commercialstorage facility. Review the location’s security atleast annually.

9.5.1.a Observe the storage location’s physicalsecurity to confirm that backup media storage issecure.



9.5.1.b Verify that the storage location securityis reviewed at least annually.



9.6 Maintain strict control over the internal orexternal distribution of any kind of media,including the following:

9.6 Verify that a policy exists to controldistribution of media, and that the policy coversall distributed media including that distributed toindividuals.

Google is responsible for physical securitycontrols on all Google Data Centers underlyingGCP and media that are maintained by Google.

GCP customers are responsible for the securityof any media that are stored outside of GCP.

9.6.1 Classify media so the sensitivity of thedata can be determined.

9.6.1 Verify that all media is classified so thesensitivity of the data can be determined.



9.6.2 Send the media by secured courier orother delivery method that can be accuratelytracked.

9.6.2.a Interview personnel and examinerecords to verify that all media sent outside thefacility is logged and sent via secured courier orother delivery method that can be tracked.



9.6.2.b Select a recent sample of several daysof offsite tracking logs for all media, and verifytracking details are documented.



9.6.3 Ensure management approves any and allmedia that is moved from a secured area(including when media is distributed toindividuals).

9.6.3 Select a recent sample of several days ofoffsite tracking logs for all media. Fromexamination of the logs and interviews withresponsible personnel, verify propermanagement authorization is obtainedwhenever media is moved from a secured area(including when media is distributed toindividuals).



9.7 Maintain strict control over the storage andaccessibility of media.

9.7 Obtain and examine the policy for controllingstorage and maintenance of all media and verifythat the policy requires periodic mediainventories.



9.7.1 Properly maintain inventory logs of allmedia and conduct media inventories at leastannually.

9.7.1 Review media inventory logs to verify thatlogs are maintained and media inventories areperformed at least annually.



9.8 Destroy media when it is no longer neededfor business or legal reasons as follows:

9.8 Examine the periodic media destructionpolicy and verify that it covers all media anddefines requirements for the following: * Hard-copy materials must be crosscutshredded, incinerated, or pulped such that thereis reasonable assurance the hard- copymaterials cannot be reconstructed. * Storage containers used for materials that areto be destroyed must be secured. * Cardholder data on electronic media must berendered unrecoverable via a secure wipeprogram (in accordance with industry-acceptedstandards for secure deletion), or by physicallydestroying the media.



9.8.1 Shred, incinerate, or pulp hard- copymaterials so that cardholder data cannot bereconstructed. Secure storage containers usedfor materials that are to be destroyed.

9.8.1.a Interview personnel and examineprocedures to verify that hard-copy materials arecrosscut shredded, incinerated, or pulped suchthat there is reasonable assurance the hard-copy materials cannot be reconstructed.



9.8.1.b Examine storage containers used formaterials that contain information to bedestroyed to verify that the containers aresecured.



9.8.2 Render cardholder data on electronicmedia unrecoverable so that cardholder datacannot be reconstructed.

9.8.2 Verify that cardholder data on electronicmedia is rendered unrecoverable via a securewipe program in accordance with industry-accepted standards for secure deletion, orotherwise physically destroying the media).



9.9 Protect devices that capture payment carddata via direct physical interaction with the cardfrom tampering and substitution.

Note: These requirements apply to card- readingdevices used in card-present transactions (thatis, card swipe or dip) at the point of sale. Thisrequirement is not intended to apply to manualkey-entry components such as computerkeyboards and POS keypads.

Note: Requirement 9.9 is a best practice untilJune 30, 2015, after which it becomes arequirement.

9.9 Examine documented policies andprocedures to verify they include: * Maintaining a list of devices * Periodically inspecting devices to look fortampering or substitution * Training personnel to be aware of suspiciousbehavior and to report tampering or substitutionof devices.


N/A

9.9.1 Maintain an up-to-date list of devices. Thelist should include the following: * Make, model of device * Location of device (for example, the addressof the site or facility where the device is located) * Device serial number or other method ofunique identification.

9.9.1.a Examine the list of devices to verify itincludes: * Make, model of device * Location of device (for example, the addressof the site or facility where the device is located) * Device serial number or other method ofunique identification.


N/A

9.9.1.b Select a sample of devices from the listand observe devices and device locations toverify that the list is accurate and up to date.


N/A

9.9.1.c Interview personnel to verify the list ofdevices is updated when devices are added,relocated, decommissioned, etc.


N/A

9.9.2 Periodically inspect device surfaces todetect tampering (for example, addition of cardskimmers to devices), or substitution (forexample, by checking the serial number or otherdevice characteristics to verify it has not beenswapped with a fraudulent device).

Note: Examples of signs that a device mighthave been tampered with or substituted includeunexpected attachments or cables plugged intothe device, missing or changed security labels,broken or differently colored casing, or changesto the serial number or other external markings.

9.9.2.a Examine documented procedures toverify processes are defined to include thefollowing: * Procedures for inspecting devices * Frequency of inspections.


N/A

9.9.2.b Interview responsible personnel andobserve inspection processes to verify: * Personnel are aware of procedures forinspecting devices. * All devices are periodically inspected forevidence of tampering and substitution.


N/A

9.9.3 Provide training for personnel to be awareof attempted tampering or replacement ofdevices. Training should include the following: * Verify the identity of any third-party personsclaiming to be repair or maintenance personnel,prior to granting them access to modify ortroubleshoot devices. * Do not install, replace, or return deviceswithout verification. * Be aware of suspicious behavior arounddevices (for example, attempts by unknownpersons to unplug or open devices). * Report suspicious behavior and indications ofdevice tampering or substitution to appropriatepersonnel (for example, to a manager orsecurity officer).

9.9.3.a Review training materials for personnelat point-of-sale locations to verify they includetraining in the following: * Verifying the identity of any third-partypersons claiming to be repair or maintenancepersonnel, prior to granting them access tomodify or troubleshoot devices * Not to install, replace, or return deviceswithout verification * Being aware of suspicious behavior arounddevices (for example, attempts by unknownpersons to unplug or open devices) * Reporting suspicious behavior andindications of device tampering or substitution toappropriate personnel (for example, to amanager or security officer).


GCP customers are responsible for training itspersonnel on the physical security of media andother applicable physical security requirements.

9.9.3.b Interview a sample of personnel at point-of-sale locations to verify they have receivedtraining and are aware of the procedures for thefollowing: * Verifying the identity of any third-partypersons claiming to be repair or maintenancepersonnel, prior to granting them access tomodify or troubleshoot devices * Not to install, replace, or return deviceswithout verification * Being aware of suspicious behavior arounddevices (for example, attempts by unknownpersons to unplug or open devices) * Reporting suspicious behavior andindications of device tampering or substitution toappropriate personnel (for example, to amanager or security officer).


GCP customers are responsible for training itspersonnel on the physical security of media andother applicable physical security requirements.

9.10 Ensure that security policies andoperational procedures for restricting physicalaccess to cardholder data are documented, inuse, and known to all affected parties.

9.10 Examine documentation and interviewpersonnel to verify that security policies andoperational procedures for restricting physicalaccess to cardholder data are: * Documented, * In use, and * Known to all affected parties.


GCP customers are responsible for developingand maintaining security policies andoperational procedures to comply with thisrequirement.

10.1 Implement audit trails to link all access tosystem components to each individual user.

10.1 Verify, through observation andinterviewing the system administrator, that: * Audit trails are enabled and active for systemcomponents. * Access to system components is linked toindividual users.

Google is responsible for controlling access,logging and monitoring of the systems andinfrastructure underlying GCP in compliancewith requirements of section 10.

GCP customers are responsible for controllingaccess, logging and monitoring on all customerdeployed instances on GCP in compliance withrequirements of section 10.

10.2 Implement automated audit trails for allsystem components to reconstruct the followingevents:

10.2 Through interviews of responsiblepersonnel, observation of audit logs, andexamination of audit log settings, perform thefollowing:

10.2.1 All individual user accesses to cardholderdata

10.2.1 Verify all individual access to cardholderdata is logged.



10.2.2 All actions taken by any individual withroot or administrative privileges

10.2.2 Verify all actions taken by any individualwith root or administrative privileges are logged.



10.2.3 Access to all audit trails 10.2.3 Verify access to all audit trails is logged. Google is responsible for controlling access,logging and monitoring of the systems andinfrastructure underlying GCP in compliancewith requirements of section 10.


10.2.4 Invalid logical access attempts 10.2.4 Verify invalid logical access attempts arelogged.



10.2 5 Use of and changes to identification andauthentication mechanisms —including but notlimited to creation of new accounts andelevation of privileges —and all changes,additions, or deletions to accounts with root oradministrative privileges

10.2.5.a Verify use of identification andauthentication mechanisms is logged.



10.2.5.b Verify all elevation of privileges islogged.



10.2.5.c Verify all changes, additions, ordeletions to any account with root oradministrative privileges are logged.



10.2.6 Initialization, stopping, or pausing of theaudit logs

10.2.6 Verify the following are logged: * Initialization of audit logs * Stopping or pausing of audit logs.



10.2.7 Creation and deletion of system- levelobjects

10.2.7 Verify creation and deletion of systemlevel objects are logged.



10.3 Record at least the following audit trailentries for all system components for eachevent:

10.3 Through interviews and observation ofaudit logs, for each auditable event (from 10.2),perform the following:

10.3.1 User identification 10.3.1 Verify user identification is included in logentries.



10.3.2 Type of event 10.3.2 Verify type of event is included in logentries.



10.3.3 Date and time 10.3.3 Verify date and time stamp is included inlog entries.



10.3.4 Success or failure indication 10.3.4 Verify success or failure indication isincluded in log entries.



10.3.5 Origination of event 10.3.5 Verify origination of event is included inlog entries.



10.3.6 Identity or name of affected data, systemcomponent, or resource.

10.3.6 Verify identity or name of affected data,system component, or resources is included inlog entries.



10.4 Using time-synchronization technology,synchronize all critical system clocks and timesand ensure that the following is implemented foracquiring, distributing, and storing time.

Note: One example of time synchronizationtechnology is Network Time Protocol (NTP).

10.4 Examine configuration standards andprocesses to verify that time-synchronizationtechnology is implemented and kept current perPCI DSS Requirements 6.1 and 6.2.



10.4.1 Critical systems have the correct andconsistent time.

10.4.1.a Examine the process for acquiring,distributing and storing the correct time withinthe organization to verify that: * Only the designated central time server(s)receives time signals from external sources, andtime signals from external sources are based onInternational Atomic Time or UTC. * Where there is more than one designatedtime server, the time servers peer with oneanother to keep accurate time, * Systems receive time information only fromdesignated central time server(s).



10.4.1.b Observe the time-related system-parameter settings for a sample of systemcomponents to verify: * Only the designated central time server(s)receives time signals from external sources, andtime signals from external sources are based onInternational Atomic Time or UTC. * Where there is more than one designatedtime server, the designated central timeserver(s) peer with one another to keepaccurate time. * Systems receive time only from designatedcentral time server(s).



10.4.2 Time data is protected. 10.4.2.a Examine system configurations andtime- synchronization settings to verify thataccess to time data is restricted to onlypersonnel with a business need to access timedata.



10.4.2.b Examine system configurations, timesynchronization settings and logs, andprocesses to verify that any changes to timesettings on critical systems are logged,monitored, and reviewed.



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

10.4.3 Examine systems configurations to verifythat the time server(s) accept time updates fromspecific, industry-accepted external sources (toprevent a malicious individual from changing theclock). Optionally, those updates can beencrypted with a symmetric key, and accesscontrol lists can be created that specify the IPaddresses of client machines that will beprovided with the time updates (to preventunauthorized use of internal time servers).



10.5 Secure audit trails so they cannot bealtered.

10.5 Interview system administrators andexamine system configurations and permissionsto verify that audit trails are secured so that theycannot be altered as follows:

10.5.1 Limit viewing of audit trails to those with ajob-related need.

10.5.1 Only individuals who have a job-relatedneed can view audit trail files.



10.5.2 Protect audit trail files from unauthorizedmodifications.

10.5.2 Current audit trail files are protected fromunauthorized modifications via access controlmechanisms, physical segregation, and/ornetwork segregation.



10.5.3 Promptly back up audit trail files to acentralized log server or media that is difficult toalter.

10.5.3 Current audit trail files are promptlybacked up to a centralized log server or mediathat is difficult to alter.



10.5.4 Write logs for external-facingtechnologies onto a secure, centralized, internallog server or media device.

10.5.4 Logs for external-facing technologies (forexample, wireless, firewalls, DNS, mail) arewritten onto a secure, centralized, internal logserver or media.



10.5.5 Use file-integrity monitoring or change-detection software on logs to ensure thatexisting log data cannot be changed withoutgenerating alerts (although new data beingadded should not cause an alert).

10.5.5 Examine system settings, monitored files,and results from monitoring activities to verifythe use of file-integrity monitoring or change-detection software on logs.



10.6 Review logs and security events for allsystem components to identify anomalies orsuspicious activity.

Note: Log harvesting, parsing, and alerting toolsmay be used to meet this Requirement.

10.6 Perform the following:

10.6.1 Review the following at least daily: * All security events * Logs of all system components that store,process, or transmit CHD and/or SAD * Logs of all critical system components * Logs of all servers and system componentsthat perform security functions (for example,firewalls, intrusion-detection systems/intrusion-prevention systems (IDS/IPS), authenticationservers, e-commerce redirection servers, etc.).

10.6.1.a Examine security policies andprocedures to verify that procedures are definedfor reviewing the following at least daily, eithermanually 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 componentsthat perform security functions (for example,firewalls, intrusion-detection systems/intrusion-prevention systems (IDS/IPS), authenticationservers, e-commerce redirection servers, etc.)



10.6.1.b Observe processes and interviewpersonnel to verify that the following arereviewed 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 componentsthat perform security functions (for example,firewalls, intrusion-detection systems/intrusion-prevention systems (IDS/IPS), authenticationservers, e-commerce redirection servers, etc.).



10.6.2 Review logs of all other systemcomponents periodically based on theorganization’s policies and risk managementstrategy, as determined by the organization’sannual risk assessment.

10.6.2.a Examine security policies andprocedures to verify that procedures are definedfor reviewing logs of all other systemcomponents periodically —either manually or vialog tools—based on the organization’s policiesand risk management strategy.



10.6.2.b Examine the organization’s risk-assessment documentation and interviewpersonnel to verify that reviews are performed inaccordance with organization’s policies and riskmanagement strategy.



10.6.3 Follow up exceptions and anomaliesidentified during the review process.

10.6.3.a Examine security policies andprocedures to verify that procedures are definedfor following up on exceptions and anomaliesidentified during the review process.



10.6.3.b Observe processes and interviewpersonnel to verify that follow-up to exceptionsand anomalies is performed.



10.7 Retain audit trail history for at least oneyear, with a minimum of three monthsimmediately available for analysis (for example,online, archived, or restorable from backup).

10.7.a Examine security policies and proceduresto verify that they define the following: * Audit log retention policies * Procedures for retaining audit logs for at leastone year, with a minimum of three monthsimmediately available online.



10.7.b Interview personnel and examine auditlogs to verify that audit logs are available for atleast one year.



10.7.c Interview personnel and observeprocesses to verify that at least the last threemonths’ logs can be immediately restored foranalysis.



10.8 Ensure that security policies andoperational procedures for monitoring all accessto network resources and cardholder data aredocumented, in use, and known to all affectedparties.

10.8 Examine documentation interviewpersonnel to verify that security policies andoperational procedures for monitoring all accessto network resources and cardholder data are: * Documented, * In use, and * Known to all affected parties.



11.1 Implement processes to test for thepresence of wireless access points (802.11),and detect and identify all authorized andunauthorized wireless access points on aquarterly basis.

Note: Methods that may be used in the processinclude but are not limited to wireless networkscans, physical/logical inspections of systemcomponents and infrastructure, network accesscontrol (NAC), or wireless IDS/IPS. Whichevermethods are used, they must be sufficient todetect and identify both authorized andunauthorized devices.

11.1.a Examine policies and procedures toverify processes are defined for detection andidentification of both authorized andunauthorized wireless access points on aquarterly basis.

Google is responsible for testing forunauthorized wireless access points,vulnerability scans and penetration tests on thesystems and infrastructure underlying GCP incompliance with requirements of section 11.

GCP customers are responsible for performingvulnerability scans and penetration tests oncustomer deployed instances on GCP incompliance with requirements of section 11.

11.1.b Verify that the methodology is adequateto detect and identify any unauthorized wirelessaccess points, including at least the following: * WLAN cards inserted into systemcomponents * Portable or mobile devices attached tosystem components to create a wireless accesspoint (for example, by USB, etc.) * Wireless devices attached to a network portor network device.



11.1.c If wireless scanning is utilized, examineoutput from recent wireless scans to verify that: * Authorized and unauthorized wireless accesspoints are identified, and * The scan is performed at least quarterly forall system components and facilities.



11.1.d If automated monitoring is utilized (forexample, wireless IDS/IPS, NAC, etc.), verifythe configuration will generate alerts to notifypersonnel.



11.1.1 Maintain an inventory of authorizedwireless access points including a documentedbusiness justification.

11.1.1 Examine documented records to verifythat an inventory of authorized wireless accesspoints is maintained and a business justificationis documented for all authorized wireless accesspoints.



11.1.2 Implement incident response proceduresin the event unauthorized wireless access pointsare detected.

11.1.2.a Examine the organization’s incidentresponse plan (Requirement 12.10) to verify itdefines and requires a response in the eventthat an unauthorized wireless access point isdetected.



11.1.2.b Interview responsible personnel and/orinspect recent wireless scans and relatedresponses to verify action is taken whenunauthorized wireless access points are found.



11.2 Run internal and external networkvulnerability scans at least quarterly and afterany significant change in the network (such asnew system component installations, changes innetwork topology, firewall rule modifications,product upgrades).

Note: Multiple scan reports can be combined forthe quarterly scan process to show that allsystems were scanned and all applicablevulnerabilities have been addressed. Additionaldocumentation may be required to verify non-remediated vulnerabilities are in the process ofbeing addressed.

For initial PCI DSS compliance, it is not requiredthat four quarters of passing scans becompleted if the assessor verifies 1) the mostrecent scan result was a passing scan, 2) theentity has documented policies and proceduresrequiring quarterly scanning, and 3)vulnerabilities noted in the scan results havebeen corrected as shown in a re-scan(s). Forsubsequent years after the initial PCI DSSreview, four quarters of passing scans musthave occurred.

11.2 Examine scan reports and supportingdocumentation to verify that internal andexternal vulnerability scans are performed asfollows:

11.2.1 Perform quarterly internal vulnerabilityscans and rescans as needed, until all “high-risk” vulnerabilities (as identified in Requirement6.1) are resolved. Scans must be performed byqualified personnel.

11.2.1.a Review the scan reports and verify thatfour quarterly internal scans occurred in themost recent 12- month period.



11.2.1.b Review the scan reports and verify thatthe scan process includes resca ns until all“high-risk” vulnerabilities as defined in PCI DSSRequirement 6.1 are resolved.



11.2.1.c Interview personnel to verify that thescan was performed by a qualified internalresource(s) or qualified external third party, andif applicable, organizational independence of thetester exists (not required to be a QSA or ASV).



11.2.2 Perform quarterly external vulnerabilityscans, via an Approved Scanning Vendor (ASV)approved by the Payment Card IndustrySecurity Standards Council (PCI SSC). Performrescans as needed, until passing scans areachieved. Note: Quarterly external vulnerabilityscans must be performed by an ApprovedScanning Vendor (ASV), approved by thePayment Card Industry Security StandardsCouncil (PCI SSC). Refer to the ASV ProgramGuide published on the PCI SSC website forscan customer responsibilities, scanpreparation, etc.

11.2.2.a Review output from the four mostrecent quarters of external vulnerability scansand verify that four quarterly externalvulnerability scans occurred in the most recent12- month period.



11.2.2.b Review the results of each quarterlyscan and rescan to verify that the ASV ProgramGuide requirements for a passing scan havebeen met (for example, no vulnerabilities rated4.0 or higher by the CVSS, and no automaticfailures).



11.2.2.c Review the scan reports to verify thatthe scans were completed by a PCI SSCApproved Scanning Vendor (ASV).



11.2.3 Perform internal and external scans, andrescans as needed, after any significant change.Scans must be performed by qualifiedpersonnel.

11.2.3.a Inspect and correlate change controldocumentation and scan reports to verify thatsystem components subject to any significantchange were scanned.



11.2.3.b Review scan reports and verify that thescan process includes rescans until: * For external scans, no vulnerabilities existthat are scored 4.0 or higher by the CVSS. * For internal scans, all “high-risk”vulnerabilities as defined in PCI DSSRequirement 6.1 are resolved. 11.2.3.c Validatethat the scan was performed by a qualifiedinternal resource(s) or qualified external thirdparty, and if applicable, organizationalindependence of the tester exists (not requiredto be a QSA or ASV).



11.3 Implement a methodology for penetrationtesting that includes the following: * Is based on industry-accepted penetrationtesting approaches (for example, NIST SP800-115) * Includes coverage for the entire CDEperimeter and critical systems * Includes testing from both inside and outsidethe network * Includes testing to validate any segmentationand scope-reduction controls * Defines application-layer penetration tests toinclude, at a minimum, the vulnerabilities listedin Requirement 6.5 * Defines network-layer penetration tests toinclude components that support networkfunctions as well as operating systems * Includes review and consideration of threatsand vulnerabilities experienced in the last 12months * Specifies retention of penetration testingresults and remediation activities results.

Note: This update to Requirement 11.3 is a bestpractice until June 30, 2015, after which itbecomes a requirement. PCI DSS v2.0requirements for penetration testing must befollowed until v3.0 is in place.

11.3 Examine penetration-testing methodologyand interview responsible personnel to verify amethodology is implemented that includes thefollowing: * Is based on industry-accepted penetrationtesting approaches (for example, NIST SP800-115) * Includes coverage for the entire CDEperimeter and critical systems * Testing from both inside and outside thenetwork * Includes testing to validate any segmentationand scope- reduction controls * Defines application-layer penetration tests toinclude, at a minimum, the vulnerabilities listedin Requirement 6.5 * Defines network-layer penetration tests toinclude components that support networkfunctions as well as operating systems * Includes review and consideration of threatsand vulnerabilities experienced in the last 12months * Specifies retention of penetration testingresults and remediation activities results.



11.3.1 Perform external penetration testing atleast annually and after any significantinfrastructure or application upgrade ormodification (such as an operating systemupgrade, a sub-network added to theenvironment, or a web server added to theenvironment).

11.3.1.a Examine the scope of work and resultsfrom the most recent external penetration test toverify that penetration testing is performed asfollows: * Per the defined methodology * At least annually * After any significant changes to theenvironment.



11.3.1.b Verify that the test was performed by aqualified internal resource or qualified externalthird party, and if applicable, organizationalindependence of the tester exists (not requiredto be a QSA or ASV).



11.3.2 Perform internal penetration testing atleast annually and after any significantinfrastructure or application upgrade ormodification (such as an operating systemupgrade, a sub-network added to theenvironment, or a web server added to theenvironment).

11.3.2.a Examine the scope of work and resultsfrom the most recent internal penetration test toverify that penetration testing is performed asfollows: * Per the defined methodology * At least annually * After any significant changes to theenvironment.



11.3.2.b Verify that the test was performed by aqualified internal resource or qualified externalthird party, and if applicable, organizationalindependence of the tester exists (not requiredto be a QSA or ASV).



11.3.3 Exploitable vulnerabilities found duringpenetration testing are corrected and testing isrepeated to verify the corrections.

11.3.3 Examine penetration testing results toverify that noted exploitable vulnerabilities werecorrected and that repeated testing confirmedthe vulnerability was corrected.



11.3.4 If segmentation is used to isolate theCDE from other networks, perform penetrationtests at least annually and after any changes tosegmentation controls/methods to verify that thesegmentation methods are operational andeffective, and isolate all out-of-scope systemsfrom systems in the CDE.

11.3.4.a Examine segmentation controls andreview penetration-testing methodology to verifythat penetrationtesting procedures are definedto test all segmentation methods to confirm theyare operational and effective, and isolate all out-of-scope systems from systems in the CDE.



11.3.4.b Examine the results from the mostrecent penetration test to verify that penetrationtesting to verify segmentation controls: * Is performed at least annually and after anychanges to segmentation controls/methods. * Covers all segmentation controls/methods inuse. * Verifies that segmentation methods areoperational and effective, and isolate all out-of-scope systems from systems in the CDE.



11.4 Use intrusion-detection and/or intrusion-prevention techniques to detect and/or preventintrusions into the network. Monitor all traffic atthe perimeter of the cardholder dataenvironment as well as at critical points in thecardholder data environment, and alertpersonnel to suspected compromises. Keep allintrusion-detection and prevention engines,baselines, and signatures up to date.

11.4.a Examine system configurations andnetwork diagrams to verify that techniques (suchas intrusion-detection systems and/or intrusion-prevention systems) are in place to monitor alltraffic: * At the perimeter of the cardholder dataenvironment * At critical points in the cardholder dataenvironment.



11.4.b Examine system configurations andinterview responsible personnel to confirmintrusion-detection and/or intrusion-preventiontechniques alert personnel of suspectedcompromises.



11.4.c Examine IDS/IPS configurations andvendor documentation to verify intrusion-detection and/or intrusion- preventiontechniques are configured, maintained, andupdated per vendor instructions to ensureoptimal protection.



11.5 Deploy a change-detection mechanism (forexample, file-integrity monitoring tools) to alertpersonnel to unauthorized modification(including changes, additions, and deletions) ofcritical system files, configuration files, orcontent files; and configure the software toperform critical file comparisons at least weekly.

Note: For change-detection purposes, criticalfiles are usually those that do not regularlychange, but the modification of which couldindicate a system compromise or risk ofcompromise. Change-detection mechanismssuch as file-integrity monitoring products usuallycome pre- configured with critical files for therelated operating system. Other critical files,such as those for custom applications, must beevaluated and defined by the entity (that is, themerchant or service provider).

11.5.a Verify the use of a change-detectionmechanism within the cardholder dataenvironment by observing system settings andmonitored files, as well as reviewing results frommonitoring activities. Examples of files thatshould be monitored: * System executables * Application executables * Configuration and parameter files * Centrally stored, historical or archived, log andaudit files * Additional critical files determined by entity(for example, through risk assessment or othermeans).

11.5.b Verify the mechanism is configured toalert personnel to unauthorized modification(including changes, additions, and deletions) ofcritical files, and to perform critical filecomparisons at least weekly



11.5.b Verify the mechanism is configured toalert personnel to unauthorized modification(including changes, additions, and deletions) ofcritical files, and to perform critical filecomparisons at least weekly.



11.5.1 Implement a process to respond to anyalerts generated by the change- detectionsolution.

11.5.1 Interview personnel to verify that all alertsare investigated and resolved.



11.6 Ensure that security policies andoperational procedures for security monitoringand testing are documented, in use, and knownto all affected parties.

11.6 Examine documentation interviewpersonnel to verify that security policies andoperational procedures for security monitoringand testing are: * Documented, * In use, and * Known to all affected parties.



12.1 Establish, publish, maintain, anddisseminate a security policy.

12.1 Examine the information security policy andverify that the policy is published anddisseminated to all relevant personnel (includingvendors and business partners).

Google is responsible for establishing,maintaining and disseminating security policies,usage policies and performing risk assessmentsfor all systems and infrastructure underlyingGCP in compliance with requirements in section12.

GCP customers are responsible for establishing,maintaining and disseminating security policies,usage policies and performing risk assessmentsfor all systems and instances deployed bycustomers on GCP.

12.1.1 Review the security policy at leastannually and update the policy when theenvironment changes.

12.1.1 Verify that the information security policyis reviewed at least annually and updated asneeded to reflect changes to businessobjectives or the risk environment.



12.2 Implement a risk-assessment process that: * Is performed at least annually and uponsignificant changes to the environment (forexample, acquisition, merger, relocation, etc.), * Identifies critical assets, threats, andvulnerabilities, and * Results in a formal, documented analysis ofrisk.

Examples of risk-assessment methodologiesinclude but are not limited to OCTAVE, ISO27005 and NIST SP 800-30.

12.2.a Verify that an annual risk-assessmentprocess is documented that identifies assets,threats, vulnerabilities, and results in a formal,documented analysis of risk.



12.2.b Review risk-assessment documentationto verify that the risk-assessment process isperformed at least annually and upon significantchanges to the environment.



12.3 Develop usage policies for criticaltechnologies and define proper use of thesetechnologies.

Note: Examples of critical technologies include,but are not limited to, remote access andwireless technologies, laptops, tablets,removable electronic media, e- mail usage andInternet usage.

Ensure these usage policies require thefollowing:

12.3 Examine the usage policies for criticaltechnologies and interview responsiblepersonnel to verify the following policies areimplemented and followed:

12.3.1 Explicit approval by authorized parties 12.3.1 Verify that the usage policies includeprocesses for explicit approval from authorizedparties to use the technologies.



12.3.2 Authentication for use of the technology 12.3.2 Verify that the usage policies includeprocesses for all technology use to beauthenticated with user ID and password orother authentication item (for example, token).



12.3.3 A list of all such devices and personnelwith access

12.3.3 Verify that the usage policies define a listof all devices and personnel authorized to usethe devices.



12.3.4 A method to accurately and readilydetermine owner, contact information, andpurpose (for example, labeling, coding, and/orinventorying of devices)

12.3.4 Verify that the usage policies define amethod to accurately and readily determineowner, contact information, and purpose (forexample, labeling, coding, and/or inventorying ofdevices).



12.3.5 Acceptable uses of the technology 12.3.5 Verify that the usage policies defineacceptable uses for the technology.



12.3.6 Acceptable network locations for thetechnologies

12.3.6 Verify that the usage policies defineacceptable network locations for the technology.



12.3.7 List of company-approved products 12.3.7 Verify that the usage policies include alist of company-approved products.



12.3.8 Automatic disconnect of sessions forremote-access technologies after a specificperiod of inactivity

12.3.8.a Verify that the usage policies requireautomatic disconnect of sessions for remote-access technologies after a specific period ofinactivity.



12.3.8.b Examine configurations for remoteaccess technologies to verify that remote accesssessions will be automatically disconnected aftera specific period of inactivity.



12.3.9 Activation of remote-access technologiesfor vendors and business partners only whenneeded by vendors and business partners, withimmediate deactivation after use

12.3.9 Verify that the usage policies requireactivation of remote-access technologies usedby vendors and business partners only whenneeded by vendors and business partners, withimmediate deactivation after use.



12.3.10 For personnel accessing cardholderdata via remote-access technologies, prohibitthe copying, moving, and storage of cardholderdata onto local hard drives and removableelectronic media, unless explicitly authorized fora defined business need. Where there is anauthorized business need, the usage policiesmust require the data be protected inaccordance with all applicable PCI DSSRequirements.

12.3.10.a Verify that the usage policies prohibitcopying, moving, or storing of cardholder dataonto local hard drives and removable electronicmedia when accessing such data via remote-access technologies.



12.3.10.b For personnel with properauthorization, verify that usage policies requirethe protection of cardholder data in accordancewith PCI DSS Requirements.



12.4 Ensure that the security policy andprocedures clearly define information securityresponsibilities for all personnel.

12.4.a Verify that information security policiesclearly define information securityresponsibilities for all personnel.



12.4.b Interview a sample of responsiblepersonnel to verify they understand the securitypolicies.



12.5 Assign to an individual or team thefollowing information security managementresponsibilities:

12.5 Examine information security policies andprocedures to verify: * The formal assignment of information securityto a Chief Security Officer or other security-knowledgeable member of management. * The following information securityresponsibilities are specifically and formallyassigned:

Google maintains highly trained andprofessional information security team and hasimplemented security awareness program for allapplicable personnel in compliance with section12 requirements to manage security for allsystems and infrastructure underlying GCP.

GCP customers are responsible for maintainingan information security team and implementingsecurity awareness programs in compliance withsection 12 requirements to the manageinformation security program for all customerdeployed instances on GCP

12.5.1 Establish, document, and distributesecurity policies and procedures.

12.5.1 Verify that responsibility for establishing,documenting and distributing security policiesand procedures is formally assigned.



12.5.2 Monitor and analyze security alerts andinformation, and distribute to appropriatepersonnel.

12.5.2 Verify that responsibility for monitoringand analyzing security alerts and distributinginformation to appropriate information securityand business unit management personnel isformally assigned.



12.5.3 Establish, document, and distributesecurity incident response and escalationprocedures to ensure timely and effectivehandling of all situations.

12.5.3 Verify that responsibility for establishing,documenting, and distributing security incidentresponse and escalation procedures is formallyassigned.



12.5.4 Administer user accounts, includingadditions, deletions, and modifications.

12.5.4 Verify that responsibility for administering(adding, deleting, and modifying) user accountand authentication management is formallyassigned.



12.5.5 Monitor and control all access to data. 12.5.5 Verify that responsibility for monitoringand controlling all access to data is formallyassigned.



12.6 Implement a formal security awarenessprogram to make all personnel aware of theimportance of cardholder data security.

12.6.a Review the security awareness programto verify it provides awareness to all personnelabout the importance of cardholder datasecurity.



12.6.b Examine security awareness programprocedures and documentation and perform thefollowing:

12.6.1 Educate personnel upon hire and at leastannually. Note: Methods can vary depending onthe role of the personnel and their level ofaccess to the cardholder data.

12.6.1.a Verify that the security awarenessprogram provides multiple methods ofcommunicating awareness and educatingpersonnel (for example, posters, letters, memos,web-based training, meetings, and promotions).




12.6.1.b Verify that personnel attend securityawareness training upon hire and at leastannually.




12.6.1.c Interview a sample of personnel toverify they have completed awareness trainingand are aware of the importance of cardholderdata security.



12.6.2 Require personnel to acknowledge atleast annually that they have read andunderstood the security policy and procedures.

12.6.2 Verify that the security awarenessprogram requires personnel to acknowledge, inwriting or electronically, at least annually, thatthey have read and understand the informationsecurity policy.



12.7 Screen potential personnel prior to hire tominimize the risk of attacks from internalsources. (Examples of background checksinclude previous employment history, criminalrecord, credit history, and reference checks.)

Note: For those potential personnel to be hiredfor certain positions such as store cashiers whoonly have access to one card number at a timewhen facilitating a transaction, this requirementis a recommendation only.

12.7 Inquire with Human Resource departmentmanagement and verify that background checksare conducted (within the constraints of locallaws) prior to hire on potential personnel whowill have access to cardholder data or thecardholder data environment.

Google has implemented appropriate screeningfor its personnel which complies with section 12requirements.

GCP customers are responsible forimplementing screening on their applicablepersonnel in relation to their PCI DSS scope.

12.8 Maintain and implement policies andprocedures to manage service providers withwhom cardholder data is shared, or that couldaffect the security of cardholder data, as follows:

12.8 Through observation, review of policies andprocedures, and review of supportingdocumentation, verify that processes areimplemented to manage service providers withwhom cardholder data is shared, or that couldaffect the security of cardholder data (forexample, backup tape storage facilities,managed service providers such as web-hostingcompanies or security service providers, thosethat receive data for fraud modeling purposes,etc.), as follows:

12.8.1 Maintain a list of service providers. 12.8.1 Verify that a list of service providers ismaintained.

N/A. Google does not share customer data withthid party providers

GCP customers are responsible for complyingwith this requirements as applicable to themwhen card holder data is shared with thirdparties.

12.8.2 Maintain a written agreement thatincludes an acknowledgement that the serviceproviders are responsible for the security ofcardholder data the service providers possessor otherwise store, process or transmit on behalfof the customer, or to the extent that they couldimpact the security of the customer’s cardholderdata environment.

Note: The exact wording of anacknowledgement will depend on the agreementbetween the two parties, the details of theservice being provided, and the responsibilitiesassigned to each party. The acknowledgementdoes not have to include the exact wordingprovided in this requirement.

12.8.2 Observe written agreements and confirmthey include an acknowledgement by serviceproviders that they are responsible for thesecurity of cardholder data the service providerspossess or otherwise store, process or transmiton behalf of the customer, or to the extent thatthey could impact the security of the customer’scardholder data environment.

N/A. Google does not share customer data withthid party providers.


12.8.3 Ensure there is an established processfor engaging service providers including properdue diligence prior to engagement.

12.8.3 Verify that policies and procedures aredocumented and implemented including properdue diligence prior to engaging any serviceprovider.



12.8.4 Maintain a program to monitor serviceproviders’ PCI DSS compliance status at leastannually.

12.8.4 Verify that the entity maintains a programto monitor its service providers’ PCI DSScompliance status at least annually.



12.8.5 Maintain information about which PCIDSS requirements are managed by eachservice provider, and which are managed by theentity.

12.8.5 Verify the entity maintains informationabout which PCI DSS requirements aremanaged by each service provider, and whichare managed by the entity.



12.9 Additional requirement for service providerassessments only: Service providersacknowledge in writing to customers that theyare responsible for the security of cardholderdata the service provider possesses orotherwise stores, processes, or transmits onbehalf of the customer, or to the extent that theycould impact the security of the customer’scardholder data environment.

Note: This requirement is a best practice untilJune 30, 2015, after which it becomes arequirement.

Note: The exact wording of anacknowledgement will depend on the agreementbetween the two parties, the details of theservice being provided, and the responsibilitiesassigned to each party. The acknowledgementdoes not have to include the exact wordingprovided in this requirement.

12.9 Additional testing procedure for serviceprovider assessments only: Review serviceprovider’s policies and procedures and observewritten agreement templates to confirm theservice provider acknowledges in writing tocustomers that the service provider will maintainall applicable PCI DSS requirements to theextent the service provider handles, has accessto, or otherwise stores, processes or transmitsthe customer’s cardholder data or sensitiveauthentication data, or manages the customer'scardholder data environment on behalf of acustomer.

Google has Data Processing and Security termsfor GCP. Refer -https://cloud.google.com/terms/data-processing-terms

N/A

12.10 Implement an incident response plan. Beprepared to respond immediately to a systembreach.

12.10 Examine the incident response plan andrelated procedures to verify entity is prepared torespond immediately to a system breach byperforming the following:

Google has implemented detailed incidentresponse plan for all systems and infrastructureunderlying GCP in compliance with section 12requirements

Customers are responsible to implementincident response plan in compliance withsection 12 requirements for all customerdeployed instances and data on GCP.

12.10.1 Create the incident response plan to beimplemented in the event of system breach.Ensure the plan addresses the following, at aminimum: * Roles, responsibilities, and communicationand contact strategies in the event of acompromise including notification of thepayment brands, at a minimum * Specific incident response procedures * Business recovery and continuity procedures * Data backup processes * Analysis of legal requirements for reportingcompromises * Coverage and responses of all critical systemcomponents * Reference or inclusion of incident responseprocedures from the payment brands.

12.10.1.a Verify that the incident response planincludes: * Roles, responsibilities, and communicationstrategies in the event of a compromiseincluding notification of the payment brands, at aminimum * Specific incident response procedures * Business recovery and continuity procedures * Data backup processes * Analysis of legal requirements for reportingcompromises (for example, California Bill 1386,which requires notification of affectedconsumers in the event of an actual orsuspected compromise for any business withCalifornia residents in their database) * Coverage and responses for all criticalsystem components * Reference or inclusion of incident responseprocedures from the payment brands.



12.10.1.b Interview personnel and reviewdocumentation from a sample of previouslyreported incidents or alerts to verify that thedocumented incident response plan andprocedures were followed.



12.10.2 Test the plan at least annually. 12.10.2 Verify that the plan is tested at leastannually.



12.10.3 Designate specific personnel to beavailable on a 24/7 basis to respond to alerts.

12.10.3 Verify through observation, review ofpolicies, and interviews of responsible personnelthat designated personnel are available for 24/7incident response and monitoring coverage forany evidence of unauthorized activity, detectionof unauthorized wireless access points, criticalIDS alerts, and/or reports of unauthorized criticalsystem or content file changes.



12.10.4 Provide appropriate training to staff withsecurity breach response responsibilities.

12.10.4 Verify through observation, review ofpolicies, and interviews of responsible personnelthat staff with responsibilities for security breachresponse are periodically trained.



12.10.5 Include alerts from security monitoringsystems, including but not limited to intrusion-detection, intrusion- prevention, firewalls, andfile-integrity monitoring systems.

12.10.5 Verify through observation and review ofprocesses that monitoring and responding toalerts from security monitoring systems,including detection of unauthorized wirelessaccess points, are covered in the incidentresponse plan.



12.10.6 Develop a process to modify and evolvethe incident response plan according to lessonslearned and to incorporate industrydevelopments.

12.10.6 Verify through observation, review ofpolicies, and interviews of responsible personnelthat there is a process to modify and evolve theincident response plan according to lessonslearned and to incorporate industrydevelopments.



A.1 Protect each entity’s (that is, merchant,service provider, or other entity) hostedenvironment and data, per A.1.1 through A.1.4:A hosting provider must fulfill theserequirements as well as all other relevantsections of the PCI DSS.

Note: Even though a hosting provider may meetthese requirements, the compliance of the entitythat uses the hosting provider is not guaranteed.Each entity must comply with the PCI DSS andvalidate compliance as applicable.

A.1 Specifically for a PCI DSS assessment of ashared hosting provider, to verify that sharedhosting providers protect entities’ (merchantsand service providers) hosted environment anddata, select a sample of servers (MicrosoftWindows and Unix/Linux) across arepresentative sample of hosted merchants andservice providers, and perform A.1.1 throughA.1.4 below:

Google has implemented configurationstandards that comply with requirements inAppendix A for the infrastructure underlyingGCP products in scope for PCI.

N/A

A.1.1 Ensure that each entity only runsprocesses that have access to that entity’scardholder data environment.

A.1.1 If a shared hosting provider allows entities(for example, merchants or service providers) torun their own applications, verify theseapplication processes run using the unique ID ofthe entity. For example: * No entity on the system can use a sharedweb server user ID. * All CGI scripts used by an entity must becreated and run as the entity’s unique user ID.


N/A

A.1.2 Restrict each entity’s access andprivileges to its own cardholder dataenvironment only.

A.1.2.a Verify the user ID of any applicationprocess is not a privileged user (root/admin).


N/A

A.1.2.b Verify each entity (merchant, serviceprovider) has read, write, or executepermissions only for files and directories it ownsor for necessary system files (restricted via filesystem permissions, access control lists, chroot,jailshell, etc.) Important: An entity’s files may notbe shared by group.

Google has implemented configurationstandards that comply with requirements inAppendix A \for the infrastructure underlyingGCP products in scope for PCI.

N/A

A.1.2.c Verify that an entity’s users do not havewrite access to shared system binaries.


N/A

A.1.2.d Verify that viewing of log entries isrestricted to the owning entity.


N/A

A.1.2.e To ensure each entity cannotmonopolize server resources to exploitvulnerabilities (for example, error, race, andrestart conditions resulting in, for example,buffer overflows), verify restrictions are in placefor the use of these system resources: * Disk space * Bandwidth * Memory * CPU


N/A

A.1.3 Ensure logging and audit trails areenabled and unique to each entity’s cardholderdata environment and consistent with PCI DSSRequirement 10.

A.1.3 Verify the shared hosting provider hasenabled logging as follows, for each merchantand service provider environment: * Logs are enabled for common third-partyapplications. * Logs are active by default. * Logs are available for review by the owningentity. * Log locations are clearly communicated tothe owning entity.


N/A

A.1.4 Enable processes to provide for timelyforensic investigation in the event of acompromise to any hosted merchant or serviceprovider.

A.1.4 Verify the shared hosting provider haswritten policies that provide for a timely forensicsinvestigation of related servers in the event of acompromise.


N/A

apply. - google cloud › files › pci_dss_shared... · works. ions ore zone, ed works. been...

Documents