• Client instances

• Amazon AWS (production data)

• Google Mail (our own internal communications)

Identification

Information systems are identified as part of:

• Supplier Review Procedure

• Monthly security review meetings

• Our software development lifecycle

• Everyday working practice

Third-party vendors

This register includes information systems that FundApps depends on and that third-party vendors manage. As such, we evaluate business continuity and sufficient security controls as part of our assessment process.

Assessment

For each information system identified, we

• Assign an owner (Supplier Relationship Manager) for the system.

• Identify the business criticality.

• Based on the data classification, identify information security and business continuity controls. This information is stored in our Third-Party Risk Management System.

• Identify any specific risks relating to this third party and record them in our

  • Third-Party Risk Management System,

  • The Information Security Risk Register,

  • Business Continuity Risk Register, or

  • DPIA.

Review

Information systems are reviewed as part of our monthly security review meetings.

• Client support queries

• Internal communications

• Server logs

• Development source code

Identification

Information assets are identified as part of:

• Monthly company-wide security awareness sessions

• Monthly security review meetings

• Our software development lifecycle

• Everyday working practice

Assessment

For each information asset identified, we

• Assign an owner for the information

• Identify if it falls under any specific regulation (primarily General Data Protection Regulation)

• Identify an appropriate data classification from these ratings

Any changes to the register results in:

• updates to our data classification policy with regards the information systems and asset information falling under each classification

Review

Information systems are reviewed as part of our monthly security review meetings.

Overview

FundApps approaches both information security and business continuity from risk based principles. Each identified information security or business continuity risk is reviewed with regard to Likelihood (the possibility of a risk happening), and Impact (the consequence of a risk happening).

Risks can be identified by any member of staff, and, staff members are encouraged to contribute. Once risks are identified and reviewed for Likelihood and Impact, an appropriate remediation plan can be formulated.

The key is that risk management drives activity to resolve identified risks, and is the responsibility is that of each employee of FundApps.

Risk Appetite

FundApps has no appetite for safety risks that could result in the injury or loss of life of FundApps staff, clients or partners.

FundApps has no appetite for information security risks that could result in unauthorised or accidental disclosure of, client or other sensitive information.

FundApps has a low appetite for business continuity risks which prevent the ability to provide service to clients.

Risk Tolerance

It is important to note that following the risk management framework, any risk that equals or exceeds a risk rating of twelve (12) will exceed the FundApps Risk Tolerance level and therefore will require a risk treatment plan to lower the risk profile. See the FundApps Risk Management Matrix at the bottom of the page for further information.

Risk Management Process

A- Risk Identification

Potential information security risks and business continuity risks are identified through both formal and informal channels:

1. Monthly security review meetings

2. Incident response and reviews

3. As part of the Software Development Lifecycle

4. As part of the continuous release management

5. As part of everyday working practice

B- Risk Assessment

Likelihood and impact

Potential risks are recorded in the risk register and assigned an owner. Risks are assessed on two criteria with regards to any current controls that may already be in place:

• Likelihood, according to the FundApps Risk Management Matrix (cf. bottom of the page). Likelihood should consider the specific vulnerability or threats that may exploit this vulnerability.

Residual risk

The assessment of likelihood and impact places the risk within risk tolerance levels defined in the Risk Management Matrix (cf. bottom of the page).

Each risk level consists of

• the likelihood and impact levels

• a timeframe for review while the risk is open

• a timeframe for review once the risk is closed

C- Risk Response

Based on this categorization we can then design a risk response in order to reduce our residual risk.

Strategies for responding to the risk can include:

• Avoid risk – activities with a high likelihood of loss and large business impact. The best response is to avoid the activity.

• Mitigate risk – activities with a high likelihood of occurring, but business impact is small. The best response is to use management control systems to reduce the risk of potential loss.

• Transfer risk – activities with low probability of occurring, but with a large business impact. The best response is to transfer a portion or all of the risk to a third party by purchasing insurance, hedging, outsourcing, or entering into partnerships.

• Accept risk – if cost-benefit analysis determines the cost to mitigate risk is higher than cost to bear the risk, then the best response is to accept and continually monitor the risk.

Our risk response may generate information security or business continuity controls which could be technical, procedural or policy based.

D- Risk and Control Monitoring

Identified risks and their mitigating controls are monitored and reviewed at least annually in order to ensure the residual risk is within the risk appetite. Should the residual risk change, either due to a change in the intrinsic risk, or due to the control effectiveness, the risk response will be reviewed.

Risk Management Matrix

In order to preserve the appropriate confidentiality, integrity and availability of FundApps information assets, we must make sure they are protected against unauthorized access, disclosure or modification. This is critical for all personal data, client data and FundApps proprietary data we deal with across the FundApps business.

This standard applies to all FundApps information, irrespective of the data location or the type of device it resides on.

Approach

As a result, we can see at a glance

• What information assets fall under which data classification

• What information systems hold data falling under those classifications

• The controls that we expect each system to have in place

Responsibilities

FundApps & third parties

All FundApps employees, contractors and third parties who interact with information held by and on behalf of the FundApps are responsible for assessing and classifying the information they work with and applying the appropriate controls. Individuals must respect the security classification of any information as defined and must report the inappropriate situation of information to the Information Security Manager or Head of Security as quickly as possible.

System Owners

Each System has an owner (Supplier Relationship Manager) responsible for assessing the information it contains and classifying its sensitivity. Systems owners are then responsible for ensuring the appropriate controls are in place in conjunction with the Head of Security.

Security Team

Responsible for advising on and recommending information security standards on data classification and ensuring these are regularly reviewed.

Classification and Protection Guidance

The latest classification guidance can be found below.

Reporting Violations

Report suspected violations of this policy to the Head of Information Security, the CTO or the CEO. Reports of violations are considered Restricted data until otherwise classified.