Sensitive Payment Data Policy | Introduction and Information Categories | Access and Collection | User Authentication and Control | Authorised Payment Institution API | Electronic Money Institution E-money EMI | Small Payment Institution SPI

CONTEXT AND OVERVIEW KEY DETAILS

• Policy prepared by: Rashid Saleh Jones
• Approved by board / management on: 1 July 2020
• Policy became operational on: 6 July 2020
• Next review date: 6 July 2021

INTRODUCTION

Hirett (hereinafter referred to as the “Company”) take great care of data it holds for its customers. All data stored and accessed on Hirett information systems, whether managed by employees or by a third party (Agents), must follow this policy. Policy exemptions will be permitted only if approved in advance and in writing by the Nominated Officer.

WHY THIS POLICY EXISTS

The purpose and benefits of this policy are to raise awareness of the Hirett’s data protection arrangements to ensure that a common and consistent approach is adopted in relation to the management of information and the protection of data in order that:

• Information is collected, processed, held, transferred and disposed of appropriately;
• Staff are aware of their rights and responsibilities in relation to information handling;
• Appropriate mechanisms are in place to ensure that those about whom the Company holds
• data are advised of their rights in relation to the gathering and processing of their personal data.
In formulating and reviewing Company processes and procedures on records management, due regard is given to the current legislative provisions for data protection, including the EU General Data Protection Regulations (GDPR) and such guidance as may be issued by the UK Information Commissioner.

POLICY SCOPE

This policy applies to all staff within the Company (meaning permanent, fixed term, and temporary staff, any third-party representatives or sub-contractors, agency workers, volunteers, interns and agents engaged with the Company in the Spain or overseas). Adherence to this policy is mandatory and non-compliance could lead to disciplinary action.

• IN SCOPE
All the devices on Hirett network are covered by this policy

• NOT IN SCOPE
This policy doesn’t cover external service providers infrastructure

1. DATA CLASSIFICATION

1.1. INTRODUCTION

All data stored on Hirett computing resources must be assigned a classification level by the information owner or creator. This level is used to determine which users are permitted to access the data.

1.2. INFORMATION CATEGORIES

• CONFIDENTIAL – applies to the most sensitive business information, which is intended strictly for use within Hirett. Unauthorized disclosure could seriously and adversely impact the company, stockholders, business partners, and/or its customers. Examples of confidential information include passwords, encryption keys, cardholder data, bank account information, et cetera.
• SENSITIVE – Applies to less sensitive business information, which is intended for use within Hirett. Unauthorized disclosure could adversely impact the company, its stockholders, its business partners, and/or its customers. Examples of sensitive information include, internal market research, audit reports, et cetera.
• PRIVATE – Applies to personal information, which is intended for use within Hirett. Unauthorized disclosure could adversely impact the company
and/or its employees. Examples of private information include policies and procedures, procedure metrics, intellectual property, et cetera.
• PUBLIC – Applies to all other information which does not clearly fit into any of the above three classifications. Unauthorized disclosure isn’t expected to seriously or adversely impact the company. Any release of this information must be authorized by the Hirett Public Relations Department.

2. DATA ACCESS

All confidential or sensitive data must be protected via access controls to ensure that data is not improperly disclosed, modified, deleted or rendered unavailable. Logs must track all access to such data and identify who and when the data was accessed.
Employees who have been authorized to view information at a particular classification level will only be permitted to access information at that level or at a lower level on a need to know basis. All access to systems must be configured to deny all but what a particular user needs to access per their business role.
Access to systems or applications handling confidential, sensitive or private information must follow the data access request process. All requests require approval by the Information Security Department and a valid Authorization Request Form. Access to data exceeding the employee’s authorized role must also follow the data access request process and must include documented limits around such access (e.g. access source, access time limits, et cetera).

3. DATA COLLECTION

4. USER AUTHENTICATION AND CONTROL

USERS

• Every user must use a unique user ID and a personal secret password for access to Hirett information systems and networks.
• The use of non-authenticated (e.g. no password) user IDs, or user IDs not associated with a single identified user, are prohibited. Shared or group user IDs are prohibited.
• Each user’s access privileges must be: authorized according to business needs, restricted to least privileges necessary to perform job responsibilities and assigned based on job classification and function. Access control systems must have a default “deny-all” setting.

5. SYSTEMS

• Each computer system shall have an automated or procedural access control process to authenticate all system users. The process must:
• Identify each User through a unique User identifier (user ID).
• Hirett employee user IDs will consist of the employee’s first initial followed by the last name.
• Non-Hirett employee user IDs will consist of the name of the third-party company followed by underscore and followed by the first name of the employee.
• If the chosen user ID is already being used, the digit ‘1’ should be added at the end. If the resulting user ID is also being used, increment the digit until a unique user ID is found.
• Authenticate every user, system and application ID with a password.
• Require all passwords to be at least 7 characters in length.
• Require complex passwords, consisting of both numeric and alphabetic characters.
• Require that new passwords cannot be the same as the 4 previously used passwords.

• Lock out accounts after not more than 6 invalid logon attempts.
• Require that once a user account is locked out it remains locked for 30 minutes or until the System Administrator resets the account.
• Require system/session idle time out of 15 minutes.
• Require passwords to be reset at least every 90 days. Note: Service level accounts (e.g. accounts that are not used interactively by users to login) may be exempt from this requirement with management approval. Administrative user IDs (e.g. root, system admin, database admin, et cetera) must comply.
• Encrypt all passwords during transmission and storage on all system components (e.g. in scripts and databases, connection strings, inside compiled code, et cetera).
• Remove or disable inactive users at least every 90 days.