Procedures for security incidents
Security related complaints and fraud prevention
We use a software system that has robust built-in mechanisms for the prevention of fraud and unauthorised access comparable to what many banks use for online banking, including password, memorable information, codes sent to authorised e-wallet holders (“user”) mobile phones and email notifications. If a user logs in to the system from a new location or a new device, that user will have to go through additional layers of authentication. Login attempts are constantly monitored by the system itself and when an attempt to access the system as an administrator is made from a new device or location, a notification is sent to the known administrators informing them of the location and device of the user. The administrators can immediately restrict access if a login attempt seems suspicious.
Process for security related complaints (See Appendix 9.2 for Complaints Policy)
The same process as per the Complaints Policy will be followed for security related complaints, however they will be dealt with directly by the Compliance Officer and depending on the severity regular updates will be given to Senior Management on both the status of the complaint and the actions being taken internally to resolve the complaint and further strengthen controls and systems.
Data Access
Our data is only accessible to authorised staff who require all of five means in order to log in to our system:
1. A password
2. An access card with encrypted credentials
3. A code is generated on the system log-in interface. This code is then input into a tailored application on a mobile device which then generates a token
4. This token is then input into the system which if correct, allows the user access into the system
5. The aforementioned token generation is linked to the IMEI number of the mobile device, which ensures that only a specific mobile device may be used, which in itself also requires biometric and facial recognition to access the token generating application.
How the data stored on our server and how breaches are prevented and addressed
Client and transactional data is stored remotely on an AES 256 bit end-to-end encrypted device which allows access to devices with a specific MAC address. As each device has its own unique MAC address, no other devices will be allowed access to the file storage device, even if the correct credentials are provided. This eliminates the possibility of a data breach from external devices. Only a limited number of specific devices can be allowed access to the aforementioned file storage device.
The file storage device self-destructs its data contents if physically connected to any other device except for the pre-registered devices. The possibility of a breach is therefore reduced to practically nil. An identical device is used as a failsafe which follows the same security protocol in the event of a failure of the primary storage device.
Monitoring data and how data is used
Monitoring algorithms as per the FCA handbook have been programmed to monitor in real-time all transactions, comparing them with previous transactions.
Data is automatically monitored via in-built algorithms and any client attempting to exceed the pre- defined limits is automatically logged and a report is automatically generated to be sent to the FCA as per the reporting procedures detailed in the FCA guidelines.
Security Policy
We use a bespoke IT system, features of which have been outlined above in terms of access control, breach prevention, data analysis, logging and reporting in section.
Our premises is completely secured with the following:
• Locked doors
• Intrusion detection alarm linked to live local rapid response unit
• CCTV system installed both internally and externally with images stored both locally and remotely.
• Access control devices are used throughout the premises with all entries and exits logged on our secure servers
In terms of security risks, the measures taken as detailed above, we believe are quite adequate in preventing, reporting and predicting any security breaches or risk of fraud or money-laundering.
All IT equipment is suitably protected with the latest antivirus software which is updated on a daily basis, or whenever an update becomes available. The equipment is also physically protected with the use of locks.
Customer authentication is carried by physically and meticulously confirming client ID’s with their identity particulars. Confirmation of address and post code, date of birth, transactional history and contact details are all used to further verify clients. Any suspicious transactions or individuals are duly reported using the in-built reporting utilities available to employees which is designed around FCA reporting guidelines.
Procedures for reporting incidents to the FCA
Process of identifying an operational or security incident
Any situation related to software, hardware and human resource components that affects the information systems infrastructure and causes the automation systems to fail to work partially or completely is defined as an operation or security incident.
Types of these incidents are not limited to below examples and include all information systems activities:
• Incidents reported from systems and network management system (system errors, unusual action, exposure to malware, etc.),
• Incidents impacting reputation (threats, rumours, leaking or divulging confidential information, etc.),
• Risk management (unusual or suspicious actions detected in logs and activity reports),
• External resources,
• Incidents observed by information system users,
• Breaches of security policies.
2.2 Classifying a major operational or security incident
Hirett Ltd(“Hirett”) will use the definition of an incident as defined under, “Directive (EU) 2015/2366” to assist in classifying and identifying a major incident. The definition being: A singular event or a series of linked events unplanned by the “Electronic Money Institution (EMI)” which has or will probably have an adverse impact on the integrity, availability, confidentiality, authenticity and/or continuity of payment-related services.
Hirett will assess an operational security incident against the following:
• the number of transactions affected as a percentage of the regular level of transactions carried out
• the number and proportion of e-wallet holders affected,
• whether the service has, or will, be down for a significant period of time, more than 2 hours,
• whether the incident is significant enough that it should be escalated to senior executives and/or the chief information officer,
• economic impact – considering costs both connected to the incident directly and indirectly
• whether there will be a negative reputational impact from traditional or social media interest because, for example, client information has been leaked or was stolen or this type of incident has occurred before.
Incident Reporting process
After an incident is discovered immediately an email will be sent to the CEO and senior management team notifying them of the incident and its severity alongside an incident report.
Based on the severity of the incident, the CEO will report the incident to the FCA within the first four hours of detection of the incident. This will be done by completing FCA’s Major Incident Report, SUP 15 Annex 11D (https://www.handbook.fca.org.uk/form/sup/SUP_15_ann_11_REP018_20180113.pdf)
; in an incremental manner.
Hirett will notify the major incident to the FCA using the, FCA’s Major Incident Report, SUP 15 Annex 11D in the first instance. The information that will be provided will include the following but not limited to:
- Description of incident
- The issue
- How it happened
- Was it related to a previous incident
- Incident status
- Areas affected
- Actions taken so far
- Reporting individuals’ details
- Date and time of incident
- Provide a date when Hirett will next update the FCA on the incident
- FCA Authorisation Number
- Primary contact person
The initial report will be filed with the FCA within 4 hours from the moment the major operational or security incident is first detected.
In cases where an incident might be initially classed as non-major but subsequently become re- classified as major, the initial report will be made immediately to notify the FCA that a change in status has been identified.
Intermediate reports will be submitted to the FCA every time the situation becomes significantly better or worse, new causes of the problem are identified or new action is taken to fix the issues. This report will be submitted every 3 business days at the very least.
A final report will be submitted when the root cause analysis has taken place and there are actual figures available to replace any earlier estimates. The report will include the root cause, a summary of measures that have been or plan to be adopted to remove the problem and prevent its recurrence in the future. The final report will be delivered within a maximum of 2 weeks after the business has been deemed back to normal.