Data Retention and Protection Policy¶

Owner	Classification	Review Date	Status
CDO Office	Internal	April 2027	Active

Document Type	Policy
Owner	Head of Human Resource and Admin, Chief Technical Officer, Head of Compliance
Classification	Confidential
Review Cycle	Annual

Document Information¶

Field	Details
Document #	SP-DRDP-011
Version	V1.3
Confidentiality Level	Class 2 (Private Data / Confidential)
Date Created	27/03/2021
Issue Date	05/09/2025
Authorised By	Yassir Pasha

Change Control¶

Version	Date of Issue	Author(s)	Brief Description of Changes	Approved By
V1.0	08/04/2021	Rizwan Zafar	Initial release	Salim Karim
V1.1	07/02/2022	Rizwan Zafar	Data retention to meet regulatory requirements	Salim Karim
V1.2	02/02/2023	Rizwan Zafar	Change in review condition, changes in clause 3.2: PAN	Salim Karim
V1.3	27/09/2024	Syed Zubair Ahmed	Added 2.9 Information Deletion	Yassir Pasha
V1.3	05/09/2025	Simpaisa	Annual Review	Yassir Pasha

1 Introduction¶

In its everyday business operations Simpaisa collects and stores data of many types and in a variety of different formats. The relative importance and sensitivity of this data also varies.

It is important that this data is protected from loss, destruction, falsification, unauthorised access and unauthorised release and range of controls are used to ensure this, including backups, access control and encryption.

Within the context of the ISO Standard, Payment Card Industry Data Security Standard (PCI DSS) and other transaction data it is strictly forbidden to store certain types of data within Simpaisa systems. This policy highlights this data.

Simpaisa also has a responsibility to ensure that it complies with all relevant legal, regulatory, and contractual requirements in the collection, storage, retrieval and destruction of data.

This control applies to all systems, people and processes that constitute the organisation's information systems, including c-suite, board members, directors, employees, suppliers and other third parties who have access to Simpaisa systems.

Policy needs to be reviewed in case of a new product has been launched or at least once a year or any major change in business or regulatory requirements.

The following policies are relevant to this document:

Information Security Policy
Cryptographic Policy

2 Data Retention and Protection Policy¶

This policy begins by establishing the main principles that must be adopted when considering data retention and protection. It then sets out the types of data held by Simpaisa and their general requirements before discussing data protection, destruction, and management.

2.1 General Principles¶

There are certain key general principles that must be adopted when considering data retention and protection policy. These are:

Data must be held in compliance with all applicable legal, regulatory, and contractual requirements.
Data must not be held for any longer than required in production system.
The protection of data in terms of its sensitivity, confidentiality, integrity, and availability must be in accordance with their security classification.
Data must always remain retrievable in line with business requirements. Data can be archived by doing hashing to ensure availability as per need of business or regulatory requirements. For any retrieval for data request a formal process of approval will be required with justification of retrieval.
There must be processes for secure deletion of cardholder data when no longer needed for legal, regulatory, or business reasons.
A quarterly process must be defined for identifying and securely deleting stored cardholder data that exceeds defined retention requirements.

2.2 Data Types and Guidelines¶

To assist with the definition of guidelines for data retention and protection, data held by Simpaisa are grouped into the categories listed in Table 1. For each of these categories, the required or recommended retention period and allowable storage media are also given, together with a reason for the recommendation or requirement. Note that these are guidelines only and there may be specific circumstances where data needs to be kept for a longer or shorter period. This should be decided on a case-by-case basis as part of the design of the information security elements of new or significantly changed processes and services.

Data Category	Description	Retention Period	Reason for Retention Period	Allowable Storage Media
Accounting	Invoices, purchase orders, accounts and other historical financial records	10 years	Regulatory Requirement	Electronic only – paper records must be scanned
Budgeting and Forecasting	Forward-looking financial estimates and plans	15 years	Regulatory Requirement	Electronic/Paper
Cardholder Data	Information obtained from payment (Credit/Debit) cards	36 weeks	Based on backup and recovery strategy	Electronic/tape media/Storage media devices
Audit Logs	Security logs e.g. records of logon/logoff and permission changes	12 months	Maximum period of delay before forensic investigation	Electronic
Operational Procedures	Records associated with the completion of operational procedures	5 years	Maximum period of time elapsed regarding dispute	Electronic/Paper
Customer	Customer names, addresses, order history, credit card and bank details	1 year after last purchase	Data protection requirement	Electronic/Paper/Electronic/tape media/Storage media devices
Supplier	Supplier names, addresses, company details	5 years after end of supply	Maximum period within which dispute might occur	Electronic/Paper
Human Resources	Employee names, addresses, bank details, tax codes, employment history	5 years after end of employment	Data protection requirement; Employment law	Electronic/Paper
Contractual	Legal contracts, terms and conditions, leases	5 years after contract end	Maximum period within which dispute might occur	Electronic/Paper
Cryptography Keys	Encryption and decryption keys	Less than 1 Year	Maximum period within which dispute might occur	Electronic
CCTV	Video logs	30 days	Maximum period within which dispute might occur	Electronic

Table 1: Data types and retention period

2.3 Use of Cryptography¶

Where appropriate to the classification of information and the storage medium, cryptographic techniques will be used to ensure the confidentiality and integrity of the data. Care must be taken to ensure that encryption keys used to encrypt data are securely stored for the life of the relevant data and comply with the organisation's policy on cryptography (see Cryptographic Policy).

2.4 Media Selection¶

The choice of long-term storage media must consider the physical characteristics of the medium and the length of time it will be in use.

Where data are legally (or practically) required to be stored on paper, adequate precautions must be taken to ensure that environmental conditions remain suitable for the type of paper used. Where possible, backup copies of such data should be taken by methods such as scanning or microfiche. Regular checks must be made to assess the rate of deterioration of the paper and action taken to preserve the data if required.

For data stored on electronic media such as tape, similar precautions must be taken to ensure the longevity of the materials, including correct storage and copying onto more robust media if necessary. The ability to read the contents of the tape (or other similar media) format must be maintained by the keeping of a device capable of processing it. If this is impractical an external third party may be employed to convert the media into an alternative format.

Cardholder data on electronic media must be rendered unrecoverable (e.g. via a secure wipe program in accordance with industry-accepted standards for secure deletion, or by physically destroying the media).

2.5 Data Retrieval¶

There is little point in retaining data if they are not able to be accessed in line with business or legal requirements. The choice and maintenance of data storage facilities must ensure that data can be retrieved in a usable format within an acceptable period. An appropriate balance should be struck between the cost of storage and the speed of retrieval so that the most likely circumstances are adequately catered for.

Formal request for data retrieval should be generated by the request initiator. Once the departmental approval is granted (only on the basis of accurate and complete reason for requesting data has been provided) the request will be escalated to the data owner of the relevant department for arrangement. Once the data owner validates if data is transferable, response to the data request shall be given within 48 working hours. Data owner is responsible for delivering data within 160 working hours, if the request is approved.

2.6 Data Destruction¶

Once data have reached the end of their life according to the defined policy, they must be securely destroyed in a manner that ensures that they can no longer be used.

Depending on the data type to be destroyed, industry certified disposal companies shall be used and a record of safe disposal in the form of a certificate will be obtained.

Before data disposal, the data owner will keep logs of the disposed data along with valid justification(s) and evidence for its disposal. An independent witness is to be generated to ensure that data has been disposed of accurately after completion of its lifecycle.

2.7 Data Review¶

The retention and storage of data must be subject to a regular review process carried out under the guidance of management to ensure that:

The policy on data retention and protection remains valid
Data is being retained according to the policy
Data is being securely disposed/archived of when no longer required
Legal, regulatory and contractual requirements are being fulfilled
Processes for data retrieval are meeting business requirements
The policy is still meeting the requirements of PCI DSS, ISO27001 compliance and regulatory requirements.

The results of these reviews must be recorded.

2.8 Data Sanitisation¶

Sanitisation refers to a process that renders access to target data on the media infeasible for a given level of effort. Media sanitisation is one key element in assuring confidentiality. The processes should guide media sanitisation decision making regardless of the type of media in use. For all media types, organisations and individuals should focus on the information that could possibly have been recorded on the media, rather than on the media itself. Clear, Purge, and Destroy are actions that can be taken to sanitise media.

Clear applies logical techniques to sanitise data in all user-addressable storage locations for protection against simple non-invasive data recovery techniques; typically applied through the standard Read and Write commands to the storage device, such as by rewriting with a new value or using a menu option to reset the device to the factory state (where rewriting is not supported).
Purge applies physical or logical techniques that render Target Data recovery infeasible using state of the art laboratory techniques.
Destroy renders Target Data recovery infeasible using state of the art laboratory techniques and results in the subsequent inability to use the media for storage of data.

2.9 Information Deletion¶

All sensitive information, including personally identifiable information (PII) and payment card data, must be securely deleted when it is no longer required, in accordance with data retention policies and regulatory requirements. Information stored in any format (physical or digital) must be securely erased using industry-approved methods, such as cryptographic erasure, degaussing, or secure wiping. Data subject to regulatory requirements, such as PCI DSS, must be deleted upon reaching its defined retention period to prevent unauthorised access, recovery, or misuse. Periodic reviews will be conducted to ensure compliance with deletion requirements, and any exceptions to this clause must be documented and approved by senior management.

3 PCI DSS Compliance¶

PCI DSS compliance requires that cardholder data is handled uniquely and independently to other data classifications. Simpaisa ensures these requirements, summarised in the following sections, are fulfilled.

3.1 Sensitive Authentication Data (SAD)¶

It is forbidden to store Sensitive Authentication Data (SAD) even if encrypted. If SAD is received it must be rendered unrecoverable upon completion of the authorisation stage of the payment process.

Sensitive Authentication Data is the following information on credit/debit cards:

Full Track Data – Magnetic strip on the back of the card or the chip on the front of the card
CAV2/CVC2/CVV2/CID – The three- or four-digit value, typically on the back of the card next to the signature section
PIN/PIN BLOCK – Personal identification number entered by the cardholder during a card present transaction, and/or encrypted PIN block present within the transaction message

It is forbidden to allow the presence of Sensitive Authentication Data (SAD) even if it is not encrypted.

Sensitive Authentication Data is the following information on credit/debit cards:

Incoming transaction data
All logs for transaction
History files
Trace files
Database schemas
Database contents

3.2 Primary Account Number (PAN)¶

The primary account number is the long sixteen-digit number across a payment card. Although this can be stored if the organisation requires to do so for business reasons the following requirements must be met:

The PAN must be masked when displayed. The maximum number of digits permitted to be displayed are the first 4 and last 4 digits.
Only staff members with legitimate business need can see the full PAN.
The PAN must be rendered unreadable anywhere it is stored. See the Cryptographic Policy for more information.
PANs are never to be sent via end-to-end user messaging (e.g., email, IM, SMS, webchat etc.).

Access to the full sixteen digits of the primary account number is only available to roles required to do so for legitimate business reasons. Below is a list of these roles with business justification, prior to any access grant for PAN, it should be reviewed by management committee, if the reason is justified or not. Requester needs at least 80% of positive votes from all stakeholders to proceed with the request. In case, all stakeholders are not present, they should be communicated via email for consensus.

In the case of any loss or leakage or data compromise, management will be accountable or answerable to the regulator/financial institute/law enforcements. In case, issue is not raised by legal regulator or financial institute, Simpaisa management will hire an independent reputable organisation to do the forensic compromise assessment of data leakage. Findings will be shared with the management, disciplinary action procedure will be triggered.