SAQ P2PE ISP

Information Security Policy

[COMPANY NAME]

DOCUMENT CONTROL
VERSION: 1.0
DATE: DD MMM YYYY
Contents
How to use this document.................................................................................................................................3
Introduction.......................................................................................................................................................4
Information Security Policy Statements.............................................................................................................4
Protecting Payment Card Data.......................................................................................................................5
Scope..............................................................................................................................................................5
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...........................................................................................9
Goal 6 - Maintain an Information Security Policy........................................................................................9
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 Plan.............................................................................................13

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 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) P2PE. To save you valuable time and effort, the
standard Information Security Policy has been tailored to suit the needs of SAQ P2PE 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 processing card payments via:
 Hardware payment terminals included in a validated and PCI-listed Point-to-Point Encryption (P2PE)
solution.
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
 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.

Scope
The goals described in this Information Security Policy apply to the physical locations/areas, payment
terminals, media, processes and people in the environment(s) where the Company accepts, stores,
processes or transmits cardholder data (our Cardholder Data Environment).

5 of 15
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.
There are no Goal 1 policy statements applicable for SAQ P2PE eligible merchants.

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.
The applicable Goal 2 policy statements for SAQ P2PE eligible merchants are shown below. The intent of
those policy statements must be met in order to fulfil the applicable PCI DSS requirements.

Goal 2 – Protect Cardholder Data

Cardholder data storage must be kept to a minimum through implementation of data retention and
disposal policies, procedures and processes. These must include at least the following for all cardholder
data storage: [3.1]
SAQ P2PE merchants may retain cardholder data only on paper (hard copy). This policy applies if you have paper records (for
example, receipts, printed reports, mail order forms, etc.) with account data, including primary account numbers (PANs).
 The data storage amount and retention time must be limited to that which is required for legal,
regulatory, and/or business requirements [3.1.a]
 Processes must ensure the secure deletion of cardholder data when it is no longer needed [3.1.b]
 Any specific retention requirements, if any, for cardholder data must be specified [3.1.c]
 Processes must ensure that, at least quarterly, stored cardholder data exceeding the defined
retention period is securely deleted [3.1.d]
 All stored cardholder data must meet the requirements defined in the data-retention policy [3.1.e]
Sensitive Authentication Data must not be kept or stored after payment authorisation:
 Do not store the card verification code or value (three-digit or four-digit number printed on the front
or back of a payment card used to verify card-not-present transactions) after authorisation [3.2.2]
Security policies and operational procedures for managing the secure storage of cardholder data, as per
policy statements above, shall be documented, used by and known to all affected parties [3.7]

7 of 15
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.
There are no Goal 3 policy statements applicable for SAQ P2PE eligible merchants.

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 applicable Goal 4 policy statements for SAQ P2PE eligible merchants are shown below. The intent of
those policy statements must be met in order to fulfil the applicable PCI DSS requirements.

Goal 4 - Implement Strong Access Control Measures

Restrict physical access to cardholder data [9]
SAQ P2PE merchants may retain cardholder data only on paper (hard copy). This policy applies if you have paper records (for
example, receipts, printed reports, mail order forms, etc.) with account data, including primary account numbers (PANs).
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)
Destroy media when it is no longer needed for business or legal reasons as follows: [9.8]
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]
Physically secure and protect card reading devices or terminals, that capture payment card data via
direct physical interaction with the card, from tampering and substitution. [9.9]
Note: This includes card-reading devices used in card-present transactions (that is, card swipe or dip) at the point of sale. This
requirement is not intended to apply to manual key-entry components such as computer keyboards and POS keypads.
An up-to-date and accurate list or inventory of all card reading devices or terminals shall be maintained
[9.9.1]. See Appendix B for an example
The inventory should include:
 Make, model of device
 Location of device (for example, the address of the site or facility where the device is located)
 Device serial number or other method of unique identification
The list of card-reading devices must be updated whenever devices are added, relocated, replaced or
decommissioned [9.9.1].
Card reading devices must be regularly checked to ensure that they have not been tampered with or
substituted. A tamper/inspection report should be completed [9.9.2]. See Appendix B for an example

8 of 15
 Goal 4 - Implement Strong Access Control Measures
All personnel at points of sale and /or that use the card reading devices shall be trained to be aware of
attempted tampering or replacement of devices. This training must include their responsibility to:
 Verify the identity of any third-party persons claiming to be repair or maintenance personnel, prior to
granting them access to modify or troubleshoot POS devices.
 Not to allow anyone to install, replace, or return devices without verification (for example, on the basis
of prior notification by the device provider, acquirer, or equivalent)
 Be aware of suspicious behaviour around POS devices (for example, attempts by unknown persons to
unplug or open devices).
 Report suspicious behaviour and indications of POS device tampering or substitution to appropriate
personnel (for example, to a manager or security officer) [9.9.3]
Security policies and operational procedures for restricting physical access to cardholder data and
protecting card reading devices, as per policy statements above, shall be documented, used by and known
to all affected parties [9.10]

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 P2PE 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.
The applicable Goal 6 policy statements for SAQ P2PE eligible merchants are shown below. The intent of
those policy statements must be met in order to fulfil the applicable PCI DSS requirements

Goal 6 - Maintain an Information Security Policy

A security policy shall be established, published, maintained and made available to all relevant personnel.
The security policy must be reviewed at least annually and updated when the environment changes [12.1,
12.1.1]
The security policy and procedures must clearly define information security responsibilities for all
personnel [12.4]
The following information security management responsibilities must be formally assigned: [12.5]
The responsibility for establishing, documenting, and distributing security incident response and escalation
procedures must be assigned [12.5.3] This includes the responsibility for creation of the incident response
plan.
A formal security awareness program must be put in place. This program shall make all personnel aware
of the policy and procedures for protecting cardholder data [12.6]
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]

9 of 15
Goal 6 - Maintain an Information Security Policy
There must be a written agreement or acknowledgment from each service provider, with access to or
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
Example Device Inventory
Location Make Model Device Serial No. / Unique Identifier

Store AAAAAA, till point 1 Ingenico ICT250 XYX-111-222-333

Example Inspection Procedure

1. Check the serial number or other unique identifier of each card reading device, making sure it is the
same as that on record.
2. Physically inspect all surfaces to ensure that none of the following show evidence of tampering:
 Physical connections
 Marking, labels and stickers
 Security seals
 Security screws
3. These physical checks should be compared with other devices (use stock images or photos of your
devices held on file if you have any doubts), ensuring that the devices retain their visual and physical
integrity.
4. For further guidance on skimming attacks and prevention see:
https://www.pcisecuritystandards.org/documents/Skimming_Prevention_BP_for_Merchants_Sept2014.pdf

5. Complete a tamper/inspection report (example shown below).

6. If Tampering or Substitution is detected, follow the Security Incident Response Plan (see Appendix C)

Inspection Report Example:

Location Make Model Device Serial Inspection Findings
No. / Unique
Is unique identifier Indications of
Identifier
correct? tampering?
Store Ingenico ICT250 XYX-111-222-333 Yes/No Yes/No
AAAAAA, till
point 1

Date of Inspection Name of Inspector Signature

12 of 15
Appendix C - Example Incident Response Plan
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

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. payment
terminal or card reading device
 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. This could be relating
to your staff or your third party providers.
 Card reading devices that have been substituted
 Card reading devices showing signs of tampering
 Any card-skimming devices found in your business
 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 card reading devices, payment terminals 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
[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:

13 of 15
  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 personnel 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]
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.

14 of 15
 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.
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.

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

15 of 15