SAQ A ISP

Information Security Policy

[COMPANY NAME]

DOCUMENT CONTROL
VERSION: 1.0
DATE: DD MMM YYYY

1 of 15
Contents
How to use this document.................................................................................................................................3
Introduction.......................................................................................................................................................4
Information Security Policy Statements.............................................................................................................4
Protecting Payment Card Data.......................................................................................................................5
Scope..............................................................................................................................................................6
Responsibilities...............................................................................................................................................6
The Six Goals of the PCI DSS...............................................................................................................................7
Goal 1 – Build and Maintain a Secure Network and Systems......................................................................7
Goal 2 – Protect Cardholder Data...............................................................................................................7
Goal 3 - Maintain a Vulnerability Management Program...........................................................................7
Goal 4 - Implement Strong Access Control Measures.................................................................................8
Goal 5 - Regularly Monitor and Test Networks.........................................................................................10
Goal 6 - Maintain an Information Security Policy......................................................................................10
Appendices.......................................................................................................................................................11
Appendix A – Agreement to Comply Form...................................................................................................11
Appendix B - Inspection of card reading devices for tampering or substitution...........................................12
Appendix C - Example Incident Response.....................................................................................................12

2 of 15
How to use this document
Step 1 – Introduction, Scope and Responsibilities
Read the introductory material so you understand what you need to do. Input your company name where
needed. This section defines the objectives and scope and may require items to be assigned.
Step 2 – PCI Goals
Work your way through the goals section of the document. Each goal has introductory information so you
understand what it is about, then a set of policy statements.

An 'Applicable to SAQ' column may be used to indicate the SAQs a policy statement is relevant to.  Those
policies with a for your SAQ type are applicable to your business.  If the 'Applicable to SAQ' column is
not shown, then all policy statements should be considered relevant.
Step 3 - Share throughout your business
Once you are satisfied the policy meets your needs to achieve the objectives of the Payment Card Industry
Data Security Standard (PCI DSS), you now need to share with the people in your business. You must ask
anyone who has access to or could affect the security of payment card data and/or your Cardholder Data
Environment to read the policy. This applies to both staff and third parties. They then need to sign and date
a copy of the agreement to comply form (See Appendix A). You need to keep a record of this consent.
Step 4 – Ongoing
You need to make sure the policy is accessible and available for reference if/when required. Keep a copy of
the policy on your business premises at all times.
Make sure your security measures, processes and operating procedures fulfil the policy statements and that
these are implemented or adhered to consistently. Remember to update the policy if you make any changes
to your business processes or how you accept or handle payment card data in the future so the policies
remain appropriate for the protection of payment card data and your business.

3 of 15
Introduction
This document defines the information security policy for [Company] on:
 The acceptance and processing of card payments
 The handling of payment card data (cardholder data and sensitive authentication data)
 The use of our networks and systems transmitting, processing and/or storing such data
Definitions for terms used in this policy can be found in this Glossary.
Based on your answers to the profile questions about how you accept card payments your business has been
deemed eligible for Self-Assessment Questionnaire (SAQ) A. To save you valuable time and effort, the
standard Information Security Policy has been tailored to suit the needs of SAQ A eligible businesses.
This Information Security Policy includes policy statements and requirements as required by the Payment
Card Industry Data Security Standard (PCI DSS) and has been developed to be appropriate for merchant
businesses accepting only card not present (e-commerce or mail order / telephone order) payments, where:
 All cardholder data functions are outsourced to PCI DSS validated compliant third-party service
provider(s)
 The merchant retains cardholder data only on paper (e.g. records, reports, receipts) and does not
store, process, or transmit any cardholder data in electronic format on their systems or premises.
 For e-commerce: All elements of the payment page(s) delivered to the consumer’s browser originate
only and directly from a PCI DSS validated compliant third-party service provider(s).
If your business accepts or processes customer card data in other ways, this information security policy must
be reviewed and updated to include additional, appropriate statements that will ensure the protection and
confidentiality of payment card data in line with the PCI DSS requirements applicable to those additional
activities.
This policy aims to address all relevant PCI DSS policy requirements and obligations to ensure the protection
and confidentiality of payment card data, and is structured around the six goals of the PCI DSS v3.2.1.
Security policies and operational procedures for storing, processing or transmitting payment card data must
be documented, in use, and known to all affected parties.

Information Security Policy Statements

Maintaining the Confidentiality, Integrity and Availability of both our information and that of information
processed by us is critical to ensure continued service and the meeting of our regulatory, legal and
contractual obligations. Our information security objectives are:
 To maintain the confidentiality of information – by ensuring that information is accessible only to those
authorised to have access and to prevent unauthorised disclosure
 To maintain the integrity of information – safeguarding the accuracy and completeness of information
and information processing and ensuring that all information assets are adequately protected against
corruption or loss during input, processing, transmission or storage
 To maintain the availability of information – by ensuring that authorised users have access to
information and associated assets when required
 To ensure continuity of the business
 To minimise the impact on the business from security incidents

4 of 15
 Note on Information Security Policy coverage

Although statements on Information Security Policy have been included in this policy document, this policy is
not intended to encompass all aspects of information security in relation to the preservation of the
confidentiality, integrity and availability of sensitive, personal or confidential information belonging to
[Company] staff, customers, clients or third party providers. Nor does this Policy address all potentially
relevant legislative, regulatory and standards requirements that may apply to the business.

Businesses must therefore also define, update and disseminate an Information Security Policy that sets out
their specific information security objectives and policies for achieving those objectives.

Protecting Payment Card Data

Payment Card Data - the cardholder data and sensitive authentication data shown on the card or stored in the
magnetic stripe/chip.
Cardholder Data – includes the primary account number (PAN, the long card number shown on the payment card),
cardholder name and expiry date.
Sensitive Authentication Data – is all of the elements of a payment card used to verify the identity of the
cardholder. This includes the data contained on the card’s magnetic stripe or chip, the card security code (the
three-digit or four-digit number printed on the card) and the cardholder's PIN and 'PIN block'.
Cardholder Data Environment (CDE) – comprised of the people (including third parties), premises, processes and
technology that store, process, or transmit cardholder data or sensitive authentication data; as well as all system
components included in, or connected to, the CDE.

Our objectives for the protection of payment card data are:

 To maintain the confidentiality of payment card data
 To protect our Cardholder Data Environment from security breaches, unauthorised activity and/or
misuse of payment card data
 To accept or capture cardholder data and/or sensitive authentication data only when and where it really
is needed by the business
 To protect any paper documents showing cardholder data or sensitive authentication data to make sure
that this data is never accessible to people that have no need to see or view the data
 Not to keep or store sensitive authentication data the initial payment transaction has been processed.
 If sensitive authentication data is received, to immediately destroy all sensitive authentication data after
payment authorisation, in a way that ensures the sensitive authentication data is unrecoverable
 To only retain cardholder data that the business has a need to keep and only in hard copy (i.e. on paper);
these documents shall not be sent or received electronically
 Not to retain cardholder data in any electronic format (i.e. held in email, on file system, within an
application)
 To securely erase or destroy all cardholder data once it is no longer needed for a business reason in a
way that ensures the cardholder data is unrecoverable

This Policy must be distributed to all personnel. All personnel must read this document in its entirety and
sign a copy of the ‘Agreement to Comply’ form (shown in Appendix A) confirming they have read and
understand this policy fully.

5 of 15
Scope
The goals described in this Information Security Policy apply to all card not present mail order / telephone
order and / or e-commerce (website) payments accepted by [Company].
[Company] has outsourced all cardholder data functions to PCI DSS validated compliant third-party service
provider(s); therefore, this Information Security Policy primarily applies to the personnel, including
employees, contractors and third-parties, responsible for the management of these third-party service
providers and to those personnel who have access to or can affect the security of cardholder data.
Where [Company] redirects the cardholder from the [Company] website(s) to a third-party hosted payment
page (or integrates an iFrame of a third-party hosted payment page) for submission of the payment card
data, those policies within Goals 1, 3 and 4 intended to protect the websites from compromise and maintain
the integrity of the redirection mechanism that links cardholders to the hosted web interface also apply.
This policy applies to all personnel, including employees, contractors and third-parties resident’ on the
Company’s site(s), who have access to or can affect the security of cardholder data and/or the Cardholder
Data Environment (CDE).

Responsibilities
All personnel must comply with these information security policies.
[Company business owner / senior management, edit as appropriate for your business] must ensure that
personnel who have access to, or can affect the security of, payment card data and/or the CDE understand
their role and their responsibility to adhere to the policies set out in this document, as applicable to their
role.

[Company business owner / senior management, edit as appropriate for your business] shall ensure that
relevant procedures are created and maintained to ensure that these information security policies are
unambiguous, implemented effectively and adhered to consistently.
[Company business owner / senior management, edit as appropriate for your business] shall ensure that this
document is reviewed at least annually and whenever the environment changes, for example when security
risks, technologies or business circumstances change. The information security policy must be updated to
ensure policy statements remain appropriate for the protection of payment card data and re-distributed it
all personnel, as applicable.

6 of 15
The Six Goals of the PCI DSS
The PCI DSS was developed to encourage and enhance cardholder data security and designed to facilitate
the adoption of a consistent set of data security measures globally. There are twelve requirements which
follow six goals. This security policy highlights the six goals.

Goal 1 – Build and Maintain a Secure Network and Systems

PCI DSS Goal 1 is about building and maintaining secure networks and systems and not using vendor
supplied defaults for passwords and security parameters. All systems must be protected from unauthorised
access and activity from untrusted networks. Network security is the implementation and maintenance of
systems and controls to prevent and monitor unauthorised access, misuse, modification, or denial of a
computer network and network-accessible resources. Malicious individuals often use vendors defaults to
compromise systems because they are publicly available.

The policy(ies) specified below apply only if the e-commerce / payment page integration method used
redirects the cardholder from the [Company] website to a third-party hosted payment page (or integrates an
iFrame of a third-party hosted payment page) for submission of the payment card data. These policies are
intended to ensure the appropriate controls are in place to help protect the [Company] e-commerce website
from compromise and maintain the integrity of the redirection to the hosted payment page. See PCI SSC
FAQ #1439: https://pcissc.secure.force.com/faq/articles/Frequently_Asked_Question/How-do-PCI-DSS-
Requirements-2-6-and-8-apply-to-SAQ-A-merchants

These policies do not apply if all mail order/telephone order (MOTO) or e-commerce operations are
completely outsourced (there is no redirection mechanism from [Company] to the third party).

Goal 1 – Build and Maintain a Secure Network and Systems

Do not use vendor-supplied defaults for system passwords and other security parameters [2]
Vendor-supplied defaults (i.e. built-in vendor or ‘factory’ set default settings and passwords) must be
changed and all unnecessary default accounts removed or disabled before systems are installed on the
network. [2.1]
This applies to ALL default passwords, including but not limited to those used by operating systems, software that
provides security services, application and system accounts, point-of-sale (POS) terminals, payment applications, Simple
Network Management Protocol (SNMP) community strings, etc.)

Goal 2 – Protect Cardholder Data

PCI DSS Goal 2 – is about protecting card holder data and especially when sending it across open public
networks that are easily accessed by malicious individuals. Critical methods of protecting cardholder data
include hashing, truncations, masking and encryption. Risk mitigation methods include not storing
cardholder data unless absolutely necessary, truncating cardholder data if the full Primary Account Number
(PAN) is not needed and not sending unprotected PANs using email or instant messaging.
There are no Goal 2 policy statements applicable for SAQ A eligible merchants.

Goal 3 - Maintain a Vulnerability Management Program

PCI DSS Goal 3 is about protecting systems against malware and developing secure systems and applications.
All systems must have appropriate software patches to protect against the exploitation and compromise of
cardholder data. Vulnerabilities should be fixed by patches released by vendors and must be installed by the
entities that manage them.

7 of 15
The policy(ies) specified below apply only if the e-commerce / payment page integration method used
redirects the cardholder from the [Company] website to a third-party hosted payment page (or integrates an
iFrame of a third-party hosted payment page) for submission of the payment card data. These policies are
intended to ensure the appropriate controls are in place to help protect the [Company] e-commerce website
from compromise and maintain the integrity of the redirection to the hosted payment page. See PCI SSC
FAQ #1439: https://pcissc.secure.force.com/faq/articles/Frequently_Asked_Question/How-do-PCI-DSS-
Requirements-2-6-and-8-apply-to-SAQ-A-merchants

These policies do not apply if all mail order/telephone order (MOTO) or e-commerce operations are
completely outsourced (there is no redirection mechanism from [Company] to the third party).

Goal 3 - Maintain a Vulnerability Management Program

Develop and maintain secure systems and applications [6]
All systems and software must be protected from known vulnerabilities by installing applicable vendor-
supplied security patches (security updates). All critical security patches or updates must be installed within
one month of their release by the vendor [6.2]

Goal 4 - Implement Strong Access Control Measures

PCI DSS Goal 4 is about ensuring that critical data can only be accessed by authorised personnel, systems
and processes must be in place to limit access, assigning unique user IDs, requesting authentication and
ensuring physical security.

The policy(ies) labelled [8.X] below apply only if the e-commerce / payment page integration method used
redirects the cardholder from the [Company] website to a third-party hosted payment page (or integrates an
iFrame of a third-party hosted payment page) for submission of the payment card data. These policies are
intended to ensure the appropriate controls are in place to help protect the [Company] e-commerce website
from compromise and maintain the integrity of the redirection to the hosted payment page. See PCI SSC
FAQ #1439: https://pcissc.secure.force.com/faq/articles/Frequently_Asked_Question/How-do-PCI-DSS-
Requirements-2-6-and-8-apply-to-SAQ-A-merchants

The policy(ies) labelled [8.X] do not apply if all mail order/telephone order (MOTO) or e-commerce
operations are completely outsourced (there is no redirection mechanism from [Company] to the third
party).

Goal 4 - Implement Strong Access Control Measures

User identification and authentication procedures and management controls, for non-consumer users and
administrators, must implement the following [8.1]:
All users must be assigned their own individual login (unique ID) for access before allowing them access to
systems or cardholder data [8.1.1]
This policy must be met for all non-consumer users, such as user accounts with administrative access, accounts used to view or
access cardholder data, accounts that can access systems with cardholder data, accounts used by vendors and other third parties
who access or manage our systems. This policy does not apply to consumers (e.g. cardholders). This policy does not apply to user
accounts within a point-of-sale payment application that can only access one card at a time to process a single transaction (such as
cashier accounts on POS tills).
Access must be revoked immediately on termination of the user’s employment or contract. [8.1.3]

8 of 15
Goal 4 - Implement Strong Access Control Measures
All users must authenticated by employing at least one of the following methods, in addition to the assigned
unique ID:
• A password or passphrase (something the user knows)
• A token, smartcard or digital certificate unique to the user (something the user has)
• A biometric identifier, such as a fingerprint (something inherent in the user)
[8.2]
This policy must be met for all non-consumer users, such as user accounts with administrative access, accounts used to view or
access cardholder data, accounts that can access systems with cardholder data, accounts used by vendors and other third parties
who access or manage our systems. This policy does not apply to consumers (e.g. cardholders). This policy does not apply to user
accounts within a point-of-sale payment application that can only access one card at a time to process a single transaction (such as
cashier accounts on POS tills).

Access control systems/mechanisms must be configured to require all users to the select
passwords/passphrases that meet at least the following strength/complexity requirements:
• Minimum length of at least seven characters.
• Contain both numeric and alphabetic characters.
Alternatively, the passwords/passphrases must have complexity and strength at least equivalent to the
parameters specified above, refer to the current version of NIST SP 800-63 for guidance [8.2.3]
This policy must be met for all non-consumer users, such as user accounts with administrative access, accounts used to view or
access cardholder data, accounts that can access systems with cardholder data, accounts used by vendors and other third parties
who access or manage our systems. This policy does not apply to consumers (e.g. cardholders). This policy does not apply to user
accounts within a point-of-sale payment application that can only access one card at a time to process a single transaction (such as
cashier accounts on POS tills).

Group, shared, or generic IDs, passwords, or other authentication methods must not be used:
 Generic usernames, user IDs or account logins must be disabled or removed [8.5]
 Shared and/or generic user IDs, shared passwords and/or other shared authentication mechanisms
must not be used to administer any system components, for administrative activities or for any other
functions critical to the business or its security [8.5]
In some circumstances, a shared user account may be permitted, e.g. for point-of-sale payment applications or systems where the
user only has access to one card number at a time in order to facilitate a single transaction.

Restrict physical access to cardholder data [9]

All paper and electronic media displaying or containing cardholder data must be physically secured. [9.5]
Paper and electronic media includes but is not limited to computers, removable electronic media, paper receipts, paper reports, and
faxes)
The movement or distribution of any media containing or displaying cardholder data, whether that is within
the business or externally, must be controlled. [9.6]
This must include the following:

Identify and classify any such media (i.e. as ‘confidential’) to ensure appropriate handling by staff,
contractors, etc. [9.6.1]
If any media is sent/moved between business locations, it must always be sent by a secure and tracked
method or kept ‘in hand’ by staff [9.6.2]
Management approval is required for any media which needs to be moved out of a secure location [9.6.3]
Strict controls shall be in place for the secure storage of media containing cardholder data and for the
control of access to the media. [9.7]
Destroy media when it is no longer needed for business or legal reasons as follows: [9.8]

9 of 15
Goal 4 - Implement Strong Access Control Measures
Physical destruction of hard copy media including cross-cut shredding, incineration or pulping so that
cardholder data cannot be reconstructed. [9.8.1]
If media containing cardholder data is placed into storage containers prior to destruction, e.g. by a third-
party document destruction company, those containers must be secured to prevent access to the contents
[9.8.1]

Goal 5 - Regularly Monitor and Test Networks

PCI DSS Goal 5 is about tracking and monitoring all access to network resources and cardholder data and
testing the security of systems. The ability to track user activities is critical in preventing, detecting or
minimising the impact of a data compromise. Logging in all environments allows tracking, alerting and
analysis when something does go wrong. Testing is to ensure that the security controls are working.
There are no Goal 5 policy statements applicable for SAQ A eligible merchants.

Goal 6 - Maintain an Information Security Policy

PCI DSS Goal 6 is about having a strong security policy sets the security tone for the whole entity and
informs personnel what is expected of them. All personnel should be aware of the sensitivity of data and
their responsibilities for protecting it.

Goal 6 - Maintain an Information Security Policy

Policies and procedures to manage service providers with whom cardholder data is shared, or that could
affect the security of cardholder data, must be created and maintained as follows: [12.8]
A list of service providers and what services they provide shall be created and maintained [12.8.1]
There must be a written agreement or acknowledgment from each service provider, with access to or that
could impact the security of cardholder data, confirming that they are aware of and accept their
responsibilities for the security of cardholder data. [12.8.2]
A process to vet potential suppliers or service providers must be established. Proper due diligence, to
evaluate the suitability of a potential service provide, must be exercised before engaging with any third
party that may affect the security of business’s cardholder data environment, card payment processing or
handling of payment card data [12.8.3].
Service providers’ compliance with the PCI DSS shall be monitored and checked at least annually [12.8.4].
The services delivered by service providers must be compliant with the applicable PCI DSS requirements.
For each service provider, maintain a record or documentation that makes clear which PCI DSS requirements
are managed by the service provider and which will be the responsibility of the business [12.8.5]. If
appropriate, map out these responsibilities in a matrix (or table) detailing what specific PCI DSS
responsibilities are assigned to whom as part of the agreement or service contract. There may also be PCI
DSS requirements that are a shared responsibility.
In preparation to respond immediately to a system breach, an incident response plan must be
implemented as follows [12.10]
An incident response plan must be created to be implemented in the event of a system breach. [12.10.1]
The incident response plan sets out the steps to be taken to respond immediately to a security incident or
data breach. See Appendix C for an example

10 of 15
Appendices
Appendix A – Agreement to Comply Form
Agreement to Comply with Information Security Policies

I, the undersigned, agree to take all reasonable precautions to assure that [Company] information which has
been entrusted to [Company] by third parties and customers, will not be disclosed to unauthorised persons. I
understand that I am not authorised to use this information for my own purposes.
I confirm that I have read, understood and agree to abide by this policy and any associated procedures. I
understand that any non-compliance with this policy may be a cause for disciplinary action up to and
including dismissal from [Company].

____________________________________________________ ___________________
Employee Name (Print) and signature Date

11 of 15
Appendix B - Inspection of card reading devices for tampering or
substitution
This appendix is not used for this Information Security Policy.

Appendix C - Example Incident Response

This Incident Response Plan is provided as an Example and Template to be used to create a bespoke
Security Incident Response Plan for your business. It includes common good practice and industry
recommended steps for incident reporting and response.
What you need to do
Review this plan and update it with details specific to your business.
 Include the names of the individuals assigned responsibility for actions within the plan
 Include internal and external contact information specific to your business and its operations
 Update the plan to address any incident types and actions that are specific to your business

Security incidents must be managed in an efficient and time effective manner to make sure that the impact
of an incident is contained and the consequences for both the business and for customers are limited.
This Appendix sets out the [Company] plan for reporting and dealing with security incidents relating to
payment card data, including incidents of card reading device tampering or substitution.

How to Recognise a Security Incident

A security incident may not be recognised straightaway; however, there may be indicators of a security
breach, unauthorised activity, or signs of misuse within the environment.
Look out for any indications that a security incident has occurred or may be in progress, indications may
include:
 Suspicious or unusual activity on, or changes of behaviour of your payment systems, e.g. e-
commerce website
 The presence of or unusual activity in relation to malware (malicious software), suspicious files, or
new/unapproved executables and programs.
 Watch out for excessive or unusual remote access activity into your business (incl. your e-commerce
website). This could be relating to your staff or your third party providers.
 Hardware or software key-loggers found connected to or installed on systems
 Lost, stolen, or misplaced paper documents, receipts or any other records that display the full PAN
or card verification code (the 3- or 4-digit number printed on the card)
 Lost, stolen, or misplaced computers, mobile devices or other media (such as USB memory sticks)
that contain payment card data or other sensitive data

Roles & Responsibilities

The incident response primary contact in [Company] is:
Job Title/Role Contact Name Contact Telephone Contact Email
[INSERT DETAILS] [INSERT DETAILS] [INSERT DETAILS] [INSERT DETAILS]

Security incident response team members and contacts in the absence of the primary contact:
Job Title/Role Contact Name Contact Telephone Contact Email

12 of 15
 [INSERT DETAILS] [INSERT DETAILS] [INSERT DETAILS] [INSERT DETAILS]

The incident response primary contact (or security incident response team members in the absence of the
primary contact) is responsible for:
 Making sure that all relevant staff understand how to identify and report a suspected or actual
security incident.
 Leading the investigation of each reported incident.
 Taking action to limit the exposure of sensitive or payment card data to reduce the risks that may be
associated with any incident.
 Gathering evidence and any related information from various security measures and controls, such
as CCTV recordings or firewall/router logs.
 Documenting each incident and all activities undertaken in response to an incident.
 Reporting each security incident and findings to the appropriate parties. This may include your
acquirer, card brands, business partners, customers, etc.
 Resolving each incident to the satisfaction of all stakeholders, including any external parties.
 Initiating follow-up actions to reduce the likelihood of recurrence, as appropriate.
All staff members, including all employees, temporary staff, consultants, contractors, etc. are responsible
for:
 Making sure that they understand how to identify and report a suspected or actual security incident
 Reporting a suspected or actual security incident without undue delay to the incident response
primary contact, or to another member of the security incident response team.

External Contacts
External Party Contact Name (if known) Email Telephone

[YOUR ACQUIRER] [INSERT DETAILS] - [INSERT DETAILS]

[YOUR THIRD PARTY SUPPLIERS AND [INSERT DETAILS] [INSERT DETAILS] [INSERT DETAILS]
SERVICE PROVIDERS], e.g. Internet
Service Provider, IT or network support,
e-commerce providers, data centre, etc.]
[LOCAL LAW ENFORCEMENT] [INSERT DETAILS] [INSERT DETAILS] [INSERT DETAILS]
[YOUR NATIONAL FRAUD AND CYBER- [INSERT DETAILS] [INSERT DETAILS] [INSERT DETAILS]
CRIME REPORTING ORGANISATION]
For use if you are unable to contact your Acquirer:
Visa Europe Data Compromise Team - datacompromise@visa.co +44 (0) 20 7795 5031
m
Visa Asia Pacific (AP) and Central and - VIFraudControl@visa.com -
Eastern Europe, Middle East and Africa
Visa U.S. - USFraudControl@visa.co +1 (650) 432-2978
m
Visa Canada - CanadaInvestigations@vis +1 (416) 860-3872
a.com
Visa Latin America & Caribbean - LACFraudInvestigations@ +1 (305) 328-1593
visa.com
MasterCard - account_data_compomise -
@mastercard.com
American Express Enterprise Incident - EIRP@aexp.com +1 (602) 537-3021
Response Program (EIRP)
For reporting of breaches of personally identifiable information (Personal Data Breach):
[YOUR DATA BREACH NOTIFICATION [INSERT DETAILS] [INSERT DETAILS] [INSERT DETAILS]

13 of 15
 CONTACTS]

Incident Response Plan Steps

The Procedure for a security incident is as follows:

Report
1. Any information security incidents must be reported, without undue delay, to the incident primary
contact or to another member of the security incident response team.
In the event that a security incident or data breach is suspected to have occurred, the staff member
should discuss their concerns with their line manager, who in turn may raise the issue with the
primary contact or another member of the security incident response team.
Investigate
2. After being notified of a security incident, the security incident primary contact † will commence
investigation and determine the appropriate response.
3. The security incident primary contact † will initiate actions to limit the exposure of payment card data
and mitigating any risks associated with the incident.

Contain the incident

 Stop using the payment system to take card payments.
 Make sure that no-one can access or alter the affected system.
 Isolate the system from your network – without turning the system off.
 Unplug network cables or if using a wireless network, change the SSID (Service Set
Identifier) on the wireless access point, and other systems that may be using this wireless
network (but not on the device believed to be compromised).
 Back up systems to preserve their current state, which will also help with any investigations
at a later stage

Inform
4. The security incident primary contact † will contact the Acquirer.
5. The security incident primary contact † will follow the Acquirer’s advice to ensure the security of all
future card payments is followed.
6. Depending on the severity of the incident, the security incident primary contact † may also contact
local law enforcement, and other parties that may be affected by the security incident such as
customers, business partners or suppliers.
Resolve
7. The security incident primary contact † will liaise with the Acquirer, and other external parties as
applicable, to ensure investigate the incident and gather evidence, as is required.
8. The security incident primary contact † will take action to investigate and resolve the problem to the
satisfaction of the Acquirer, and other parties and stakeholders involved.
Recovery
9. The security incident primary contact will authorise a return to normal operations once satisfactory
resolution is confirmed.
10. Normal operations must adopt any updated processes or security measures identified and
implemented as part of resolution of the incident.

†
or another member of the security incident response team in the primary contact’s absence

14 of 15
Review
11. The security incident primary contact will complete a post-incident review. The review will consider
how the incident occurred, what the root causes were and how well the incident was handled. This
is to help identify recommendations for better future responses and to avoid a similar incident in the
future.
12. The security incident response primary contact will ensure that the required updates and changes
are adopted or implemented as necessary.

15 of 15