FCA and PRA licenses (authorisations) and ongoing compliance support, training, recruitment. Contact us 7 days a week, 8am-11pm. Free consultations. Phone / Whatsapp: +4478 3368 4449  Email: hirett.co.uk@gmail.com

← Return to the Table of Contents for all EMI and API pages

1 INTRODUCTION

This Data Protection Policy (the “Policy”) sets out the policy which HIRETT (referred to as “we” or “us” in this document) has adopted in order to facilitate compliance with the Data Protection Act 1998 (the “DPA”) when we establish and manage customer relationships and execute transactions.

The DPA regulates the “processing” of “personal data”. Its definition of “personal data” covers all information relating to identifiable living individuals which is held on computer, in other automatically-processable form or in a manual filing system which is structured so as to facilitate access to information relating to particular individuals. (Information relating to companies and other “legal” persons is not caught). Its definition of “processing” covers any conceivable activity in relation to personal data, including collection, analysis, processing in the ordinary sense of the word, storage, disclosure, international transfer and deletion.

We process personal data in various circumstances and in relation to various categories of individual. This Policy deals specifically with personal data collected in the context of the establishment and management of our customer relationships and the execution of transactions on the instructions of our customers (“Customer and/or Transaction Management”). It does not, for example, deal with data protection issues which might arise in relation to our HR or direct marketing activities.

It should be borne in mind that the DPA regulates processing of personal data relating to all individuals, not just relating to customers. Information relating to individual representatives of corporate customers, or to individuals (or individual representatives of corporate bodies) elsewhere in a payment chain – for example, an ultimate payee or an individual representative of an aggregator – is also protected by the DPA.

The individuals to whom personal data relate, whether customers or otherwise, are known as “data subjects”.

The UK Information Commissioner (the “Commissioner”) is responsible for enforcement of the DPA and has published a range of guidance on data protection issues, all of which is available on the Commissioner’s website at www.ico.gov.uk.

Our principal obligations under the DPA include: (i) processing personal data fairly, legitimately, lawfully and proportionately; (ii) informing individuals regarding our processing of their personal data; (iii) abiding by restrictions on the international transfer of personal data; (iv) keeping personal data secure, taking steps to ensure that they are accurate and up-to-date and deleting them when they are no longer needed; (v) maintaining an appropriate registration with the Commissioner’s office; and (vi) responding appropriately when data subjects seek to exercise their statutory rights of access, correction and objection.

A copy of this Policy will be supplied to each employee of HIRETT. The requirements set out in this Policy are mandatory unless otherwise stated and must be followed by all our employees and agents. It is the responsibility of each such person to acquaint themselves with the requirements of this Policy. Failure to comply with this Policy may constitute a serious disciplinary offence and could result in dismissal.
This Policy is supplementary to our other published policies, including our conduct of business, anti-money laundering and complaints policies.

2 DATA PROTECTION OFFICER

Mr. James Jacobs has been designated as HIRETT’s data protection officer (the “Data Protection Officer”). If you have any questions about this Policy or application in particular circumstances you should consult the Data Protection Officer.

3 FAIR AND PROPORTIONATE PROCESSING

The DPA requires that all of our processing of personal data should be fair and lawful and should meet one of various specified conditions. In designing and implementing each Customer and/or Transaction Management procedure involving the processing of personal data, we must take these requirements into account and ensure that they are met.

We expect that our routine processing of personal data for Customer and/or Transaction Management procedure will generally meet the most general of the available conditions, which is known as the “legitimate interests” condition. The legitimate interest’s condition will apply, and allow us to process personal data, if both:

  • A: the processing is necessary for the purposes of legitimate interests that we, or a person to whom we disclose the data, pursue (these may be business, compliance or other purposes); and
  • B: the processing is not “unwarranted” because it prejudices the rights, freedoms or legitimate interests of the data subjects.

Each processing operation should, therefore, be assessed to ensure that part A of this condition is met – i.e. we have a legitimate business, compliance or other purpose for carrying out the processing. If part A is met, you should then consider whether the processing will prejudice the data subjects in any way – our expectation is that, provided the other rules in this Policy are followed, our ordinary processing for Customer and/or Transaction Management purposes will not prejudice data subjects’ rights, freedoms or legitimate interests. If you consider that there is a potential for prejudice to be caused in a particular case, the prejudice should be balanced against our interests and a view taken on whether our interests outweigh the prejudice to the data subjects.

If you are in any doubt as to whether the legitimate interest’s condition is met, you should consider whether the processing can be justified on the basis that it meets any of the other statutory conditions available in the DPA. The other conditions most likely to apply are as follows:

  • Processing is justified if it is necessary to fulfil a UK legal obligation. This will include, for example, processing in order to carry out legally-required anti-money-laundering checks; or in response to a UK court order. Foreign legal requirements are not automatically sufficient to justify disclosure or other processing of personal data.
  • Processing is justified if it is necessary for the performance of a contract with the data subject or to take steps at the data subject’s request with a view to entering into such a contract. This will justify some processing of personal data relating to individual customers.
  • Processing can be justified on the basis of data subject consent. Our customer contracts should, therefore, include consents to the processing of individual customer data that will be necessary as part of our Customer and/or Transaction Management procedures.

The requirement that personal data should be processed lawfully can be breached in a number of circumstances, not covered by this Policy because in themselves they fall outside the scope of the DPA – for example, processing for fraudulent purposes would be unlawful and would therefore breach the DPA.

The DPA also prohibits the processing of excessive, irrelevant or inadequate personal data. Systems and procedures should be designed so as not to collect personal data which are excessive or irrelevant (in particular: personal data should not be collected on a “just-in-case” basis) and, of course, you should ensure that the data collected are adequate for the relevant purposes.

Personal data collected for any given purpose should not then be used for a purpose which is incompatible with that purpose – we would not expect this to be an issue in the ordinary course of Customer and/or Transaction Management, however.

We expect the general requirement that processing of personal data should be fair to be met if all the other requirements of this Policy are met.

4 TRANSPARENCY / INFORMATION-PROVISION

We are required under the DPA to ensure that data subjects have various information readily available to them. This requirement is subject to exceptions, however, and these exceptions are of relatively wide application in the context of Customer and/or Transaction Management. In particular, (a) information only needs to be made available where it is practicable to do so; (b) in the case of personal data which are not collected directly from the data subject (for example, payee data collected from a payer customer), we are not obliged to provide information if to do so would involve disproportionate effort; and (c) we take the view that we can assume that data subjects have, and need not therefore make available, information which should reasonably be obvious to them.

The information to be made available is (a) our identity; (b) the purposes for which we expect to process the data; and (c) any further information that needs to be provided to ensure that our processing of the data is fair.

We must ensure that our customer contracts inform our individual customers of the following:

  • our identity;
  • the purposes for which we process their information (including know-your-client and related compliance purposes as well as the execution of transactions and customer management generally); and
  • the following further information, which, we consider, needs to be provided to ensure that our processing of customer data is fair:
  • the categories of person to whom we may disclose customer data (including, for example, non-customer payers and payees; aggregators; any persons with whom we might share data for fraud prevention purposes; and regulatory and prosecuting authorities);
  • the fact that, if payments are made to persons outside the European Economic Area, this may involve transfers of the customer’s personal data to jurisdictions which do not have data protection laws as strict as those in the UK (see also paragraph 5 below); and
  • information as to the customer’s rights of access and correction under the DPA (see paragraph 10 below), and contact details so that they can contact the Data Protection Officer if they want to exercise those rights

Our customer contracts should also require customers to pass this information on to any individuals whose personal data they provide to us.
We take the view that we do not need to provide information to data subjects other than individual customers to justify our processing of their personal data for routine Customer and/or Transaction Management purposes. In particular:

We take the view that the effort involved in contacting an individual non-customer payer or payee, whose personal data are given to us by a customer, in order to provide him or her with information about our processing of his or her personal data, would be disproportionate given that we process his or her information only in order to facilitate a transaction of which he or she will in any case be aware.
We take the same view in relation to individual representatives of our customers – having required our customers to pass the required information on to their representatives we take the view that the effort involved in contacting the representatives directly would be disproportionate.

5 INTERNATIONAL TRANSFER

The DPA restricts transfers of personal data to most countries and other territories outside the European Economic Area (the European Union plus Iceland, Liechtenstein and Norway).

Transfers can be made as necessary to facilitate a transaction, on the basis that they are necessary to perform a contract with the data subject (where the data relate to a customer) or entered into in the interests of the data subject (where they relate to an overseas payee).

Except for transfers necessary to facilitate a transaction, personal data should not be transferred to countries or territories outside the European Economic Area unless the Data Protection Officer has considered the proposed transfer and concluded, on the basis of legal advice if necessary, that it can be made without breach of the DPA.

6 SECURITY, ACCURACY AND DATA DELETION

We must have in place appropriate technical and organisational security measures to protect the personal data that we process for Customer and/or Transaction Management purposes against unauthorised or unlawful processing and accidental loss, destruction or damage.

We need to identify the particular security measures that are “appropriate” in the context of our business. They must deliver a level of security which is appropriate to the nature of the data and the risks associated with unauthorised or unlawful processing and accidental loss, destruction or damage. We must, in particular, take reasonable steps to ensure the reliability of our employees who have access to the data.

If any aspect of our processing of personal data for Customer and/or Transaction Management purposes is outsourced to a third-party service provider, including the outsourcing of any wider function which includes the processing of personal data, we must:

  • satisfy ourselves that the service provider will have appropriate technical and organisational security measures in place as discussed in paragraphs 6.1 and 6.2;
  • ensure that the arrangement is governed by a written agreement which requires the service provider to process the data only on our instructions and imposes on the service provider obligations equivalent to our obligations as set out in paragraphs 6.1 and 6.2; and
  • while the arrangement is in place, take reasonable steps from time to time to ensure that the service provider is meeting its security obligations in practice.

We must take reasonable steps to ensure that the personal data that we process are accurate and, where relevant, up to date.

We must delete personal data when we no longer need them, given the purposes for which they are processed. This does not, for example, prevent us from keeping records containing personal data which may be relevant if there is a future dispute with a customer or another person, but it does require us to delete those records when a dispute is no longer a real possibility unless we have another legitimate purpose for continuing to keep the personal data.

7 SENSITIVE PERSONAL DATA

We do not seek to collect or process personal data identified by the DPA as “sensitive” for Customer and/or Transaction Management purposes. You should not collect or process sensitive personal data for these purposes and should delete them if you become aware that we have collected them, except with the approval of the Data Protection Officer given on the basis of an assessment of the requirements of the DPA.

The DPA’s definition of “sensitive personal data” covers personal data consisting of information as to: racial or ethnic origin; political opinions; religious or other similar beliefs; trade union membership; physical or mental health or condition; sexual life; the commission or alleged commission of any offence; or any proceedings for any offence committed or alleged to have been committed, the disposal of such proceedings or the sentence of any court in such proceedings.

8 AUTOMATED DECISION-TAKING

We do not use so-called “automated decision-taking” techniques for Customer and/or Transaction Management purposes. You should not use such techniques except with the approval of the Data Protection Officer given on the basis of an assessment of the requirements of the DPA.

The DPA’s restrictions on the use of automated decision-taking cover systems which make decisions which significantly affect individuals solely on the basis of the automated processing of their personal data, without any human intervention. Examples would be the use of automated credit-scoring tools to pre-screen credit applications and the use of automated tools to pre-screen applications for employment. Semi-automated systems, where the ultimate decision is made or reviewed by a human being, are not caught by these rules.

9 REGISTRATION

We maintain a registration with the Commissioner’s office which covers our processing of personal data for Customer and/or Transaction Management (and other) purposes.

You should keep the Data Protection Officer aware of material changes to the purposes for which we process personal data or, within any given purpose, the categories of personal data that we process, the categories of data subject to whom the data relate, the categories of person to whom we disclose the data or the countries or territories outside the European Economic Area to which we transfer the data, so that he or she can ensure that the registration is amended accordingly.

10 RIGHTS OF ACCESS, CORRECTION AND OBJECTION

Data subjects have statutory rights of access to and correction of the personal data that we hold about them. They also have a statutory right to object to our processing of their personal data – that is, to require us to stop processing their data – although only in very limited circumstances.

If a data subject attempts to exercise any of these statutory rights you should immediately pass his or her communication to the Data Protection Officer so that he or she can ensure that we respond appropriately and within the timescale laid down under the DPA.

In recording and processing personal data for Customer and/or Transaction Management purposes you should bear in mind data subjects’ rights of access. You should not record personal data that you would not want the data subject to see.

11 COMPLIANCE CHECK FOR DATA AND RECORDS

Compliance check the data entered in the records of the actual state. The Company makes checking compliance data follows the Front Office:

  • Monitoring of payment transactions between clients’ accounts registered with the company entered into the system by comparing the company payment orders from clients and keep records of payments to client accounts.
    • Deadline: once a month, on the last working day of the calendar month
  • Checking the payment transactions from the accounts of clients registered with the company accounts outside the company entered into the system by comparing the companies’ payment orders from clients and keep records of payments to client accounts
    • Deadline: once a month, on the last working day of the calendar month
  • Control of deposits from the bank account comparing with an overview of the monies received on behalf of the company.
    • Date: every business day
  • The Company makes checking compliance data follows the accounting department:
  • Control of banking operations is based on inventory and accounts obligation based on the inventory accounts receivable.
    • Deadline: once a week, the last working day of the calendar week
  • The anomalies detected the responsible person must immediately be removed.
  • The fulfilment of these obligations under the control of the Financial Controller.

12 PAYMENTS & PAYMENT CARD DATA PROTECTION

Card data are at least the full payment card number (PAN, primary account number). Card data also include the PAN along with any of the following information:

  • cardholder name;
  • expiry date;
  • Service Code;
  • so-called sensitive card details, i.e.:
  • card validation codes/values (CAV2, CID, CVC2, CVV2)
  • magnetic stripe track
  • PIN or so-called PIN block

A masked PAN number is not a piece of card data (e.g. visible only the first 6 digits and the last 4 digits, the remaining digits replaced by asterisks).

Card data processing

If a given process does not require card data processing, we do not process them. Card data may be processed only if this is governed by a procedure or with the prior written or in the form of e-mail consent of the Chief Information Security Officer.

If as a result of an error or coincidence we have gained possession of card data, they should be returned to the authorized person and destroyed or masked. This applies, for instance, to e-mail correspondence, documents in paper form, etc.

We do not disseminate card data. This also applies to internal distribution, card details should be in
the smallest possible number of copies and locations.

Card data protection

The primary document defining principles of card data protection is:

  • Card data security policy – constitutes implementation of PCI DSS standard requirements.

PCI DSS is a global information security standard for the payment card industry. Card data protection is applicable to all users of systems of HIRETT, i.e. employees, suppliers, contracting parties and business partners.

General rule:

We do not process card data unless this is absolutely necessary.

Card Data Processing

An unencrypted PAN may not be sent via e-mail or other communication program (e.g. instant messengers). Sending of card data is possible only following encryption using strong cryptography. When displayed, payment card PAN numbers must be masked (visible are the first 6 characters and the last 4 characters).

Media and card data

Card data may not be left without adequate protection, when they are on portable
data media, printouts or left on your desk.

Card data destruction

Destruction of printouts containing card data when no longer needed takes place by means of a shredder.

Card data access

No supplier (third party) may have access to card data. When working remotely, it is prohibited to copy card data to local media (hard drives, memory sticks, etc.), to use the copy-paste function and to make printouts.

In the areas where card data are processed, staff must wear visible IDs.

Password protection

A request for a password reset / change is submitted in person, over the phone, by email to the address
permissions@Hirett.com.uk or through your immediate supervisor. If not sure if a request is submitted by an authorized party, the IT Administrator requires that the request be submitted by a supervisor.

Methods of communicating passwords by IT Administrators

Personal (in the presence of the user) – a password is transmitted directly to the person. Remote complete: by telephone – when unambiguous identification of the user over the telephone is possible, the complete password is transmitted this way.

Remote divided: where the person requesting a password, change is unable to see the IT Administrator
personally, and unambiguous identification of the user is not possible over the telephone, the password is transmitted in two parts:

  • The first part of the password is sent to the email address of the immediate supervisor or
    account manager,
    The second part of the password is transmitted by phone to the user requesting the change.

Any questions or concerns regarding information security may be directed to the Chief Information Security.

13 SYSTEMS/INFORMATION ACCESS

Information risk owners or their delegate must explicitly define, document and keep up to date the access requirements for the specific roles which have access to the information.
A form exists on the system for managers to complete if an employee’s role within the organisation changes and access to systems needs to be updated or removed. Managers must contact the Service Desk to ensure access to other systems and programs are updated if a user’s role or the business need changes.

  • For systems containing restricted and personal information and data, an access control matrix must be developed to record role based authorised access recorded on an individual basis. Authorisation procedures must be in place for managers to authorise all access (including short term and temporary access) recorded on the matrix. The access matrix must be continually updated and maintained to reflect accurate records of access.
  • To gain access to specific systems and information, a member of staff will need to follow a formal application process. Users will need to apply to the relevant owners/senior custodian of the systems using the appropriate completed forms.
  • Generic logons are not generally permitted across the HIRETT, however, use of generic accounts under exceptional ‘controlled’ circumstances such as the HIRETT’s Libraries system, is permitted.
  • To ensure relevant HIRETT or national legislation security standards are adhered to, personnel checks, such as DBS and Baseline Personnel Security Standard checks may be undertaken if required.
  • The appropriate level of access to systems and information will be determined upon the prospective users required business need, job function and role.
  • A signed confirmation by the user may be required indicating that they understand and appreciate the conditions of access and security.
  • If authorisation to use systems and information is granted, unique logon credentials and password will be provided to the applicant. Further instruction on how to maintain the security of systems and information with due regard to the procedures below may be given.
  • Access for remote users shall be subject to authorisation by line managers via the Transformation Service. No uncontrolled external access shall be permitted to any network device or networked system.
  • The application and all other documentation should be maintained in line with the safe haven guidance.
  • Login banners should be used to remind users of their obligations when using the system

14 SYSTEMS/INFORMATION DE-REGISTRATION

  • If a member of staff changes role or their contract is terminated, the manager should ensure that a user’s access to the system/information has been reviewed or, if necessary, removed as soon as possible by the standard leavers/change process performed by SAP processes.
  • If a member of staff is deemed to have contravened any of the Information Security policies or procedures, potentially jeopardising the availability, confidentiality or integrity of any systems or information, their access rights to the system/information should be reviewed by the system owners.
  • If a specific access limit is exceeded or control circumvented several times by a user the manager should review the access rights of the user and if necessary remind the user of the relevant access and security.
  • If a number of unsuccessful log-on attempts is exceeded, the user will be informed that they need to contact the system owners or the Transformation Service desk to ask for access rights to be re-established. In these circumstances, access rights may need to be reviewed.
  • If it is deemed that it is no longer appropriate or necessary for a user to have access to systems and/or information then the user’s manager will need to inform the owners of the system/information that access rights should be altered/removed immediately.
  • If any system/information rights are altered or removed, the relevant documentation will need to be updated accordingly.

15 LOG-ON CONSIDERATIONS

  • All systems should be accessed by secure authentication of user validation. As a minimum, this should entail use of a User name and a Password.
  • Logon to systems/information should only be attempted using authorised and correctly configured equipment in accordance with HIRETT policies.
  • After successful logon users should ensure that equipment is not left unattended and active sessions are terminated or locked as necessary. Systems should be logged off, closed down or terminated as soon as possible.
  • System logon data should not be copied, shared or written down.

16 PHYSICAL ACCESS AND CONTROLS

Maintaining the physical security of offices and rooms where information, data and processing facilities are accessed and located is vitally important. There must be methods of physically securing access to protect information and data:

  • Staff should wear their HIRETT ID badges and visitors must wear the Visitor ID badges which have been issued to them. People who are not displaying ID badges should be challenged. Any person not known to location personnel must be challenged in order to establish who they are and whether authorisation has been provided for them to be there. If there is any doubt about the identity of the individual, the appropriate security officer/manager should be contacted to confirm the individual’s identity. Staff in residential establishments will need to check their local procedures whilst working inside the home.
  • Appropriate recording mechanisms need to be in place to record the names, dates, times and signatures for the signing in and out of visitors (including HIRETT personnel) to HIRETT locations. All visitors must be issued with an authorised HIRETT visitors badge when signing in.
  • The use of keys to buildings, rooms, secure cabinets, safes etc. must be controlled and recorded. Keys must be stored in secure areas/locked cabinets when not in use and must be identifiable by recording serial/ID markings of all keys. The location of keys must be known at all times and a signing in/out recording mechanism must be maintained to record the serial/ID of keys against individual names when keys are used.
  • Electronic access fobs must be issued to authorised staff on an individual basis. Staff issued with access fobs must have their names and employee numbers recorded against the registered access fob number including date and time of issue
  • Access fobs should only be used by the registered user and must not be lent out or given to other staff, regardless of their seniority. In emergency situations, authorised personnel may be permitted to use another authorised person’s fob if available with permission of the line manager and the recorded user must either be present or be made aware that their fob is being used. Any such use must be recorded and maintained in a logging system for this type of event
  • Access fobs issued to personnel who no longer work for the HIRETT must be deactivated and recovered immediately – a record of this action must be kept, using an official recording system
  • Locations housing critical or sensitive information and/or information processing facilities should have a secure, physically sound perimeter with suitable controls and restrictions allowing access to authorised staff only. CCTV and audible alarm systems should be active in areas where critical servers are located, such as in the data centre.
  • Observance and maintenance of the physical security of rooms and offices where PCs and/or critical information processing equipment is located needs to be a paramount consideration. For example, do not house critical equipment in publicly accessible locations, close to windows, in areas where theft is a high risk. Locate servers and business critical equipment in locations with adequate environmental and fire controls.
  • Access to information processing systems will only be allocated to staff following any required legal/HIRETT checks. If required, usage policies will also need to be signed by staff.
  • All interfaces used for managing system administration and enabling access to information processing must be appropriately secured.
  • Access to and knowledge of key fobs, door lock codes or access to keys for locks, are restricted to authorised personnel only and must not be shared with any unauthorised person.
  • Access codes used for secure locking mechanisms must be changed every three months as a minimum or more regularly as specified by the location manager in line with professional best practice. Outside of office record should be kept in a secure location of when the dates when the access codes are updated.
  • If electronic door locks/key fobs are in use they must be issued to authorised staff on an individual basis, be fully registered to that individual and only used by that individual. The key fob must be deactivated immediately when no longer required and registration details updated accordingly.
  • Direct access to secure locations, or access to adjoining offices which could provide access, must be locked and secured using appropriate locking mechanisms.
  • All HIRETT/Contracted Cleaners must have and display appropriate identification and be made aware of the requirements within this procedure.
  • Personal, special access visits from relatives or acquaintances of personnel are not permitted within secure areas. There must be a valid reason for all visits and any such visitors must go through the standard signing in/out procedure.
  • Equipment should be sited to minimise unnecessary, unauthorised access into work areas. For example, refreshment units or office machinery designed for visitors should be placed in public accessible areas only.

17 RESPONSIBILITIES

Directors are responsible for ensuring that all staff and managers are aware of security policies and that they are observed. Managers need to be aware they have a responsibility to ensure staff have sufficient, relevant knowledge concerning the security of information and systems. Designated owners of systems, who have responsibility for the management of ICT systems and inherent information, need to ensure that staff have been made aware of their responsibilities toward security. Designated owners of systems and information need to ensure they uphold the security policies and procedures.

18 BREACHES OF THE POLICY

Breaches of this policy and/or security incidents can be defined as events which could have, or have resulted in, loss or damage to HIRETT assets, or an event which is in breach of the FSF’s security procedures.
All HIRETT employees, members, partner agencies, Third Parties and vendors have a responsibility to report security incidents and breaches of this policy as quickly as possible through the HIRETT’s Incident Reporting Procedure. This obligation also extends to any external organisation contracted to support or access the Information Systems of the HIRETT.
The HIRETT will take appropriate measures to remedy any breach of the policy and its associated procedures and guidelines through the relevant frameworks in place. In the case of an employee then the matter may be dealt with under the disciplinary procedures.

← Return to the Table of Contents for all EMI and API pages