NOTE: At FundApps we're focused on offering the best possible services to the investment management industry. As part of that, we have a firm commitment to ensuring our platform remains highly available and your data remains secure. We have made this resource available to clients and prospective clients in order to learn more about how we achieve this and to assist with any due diligence questions you may have.

Our own staff use this resource to review security policy and educate themselves on our approaches. This is by its nature a "living" document - which will evolve as we continually evaluate how we can deliver a best of breed platform to the industry.

Policy documentation is maintained electronically across GitBook and Notion, depending on its intended audience. Version control is managed through GitHub via GitBook’s Git Sync feature, ensuring all changes are tracked. Pull requests provide visibility into modifications and require approval from the CTO and Head of Security before being merged.

If you require any clarifications or have any questions then don't hesitate to contact us.

This document provides an introduction to FundApps' shareholding disclosure service and its platform. FundApps provides shareholding disclosure monitoring services via a hosted web application which is provided via FundApps controlled infrastructure from secure and strictly controlled hosting environments. We maintain the software, continuously updating with the latest software enhancements and legislative content updates.

Workflow

Users of the system may choose to receive notification e-mails letting them know when this process has concluded, and results are available inside the system. Users use a browser-based user interface to view the results of running the batch job and follow a workflow inside the software to investigate any results and file disclosures. Historical data from checks is retained within the system to provide a timeline of results and to facilitate the correct calculation of disclosure requirements.

Software

FundApps' web application is kept constantly up to date with the latest enhancements and fixes. We continuously deliver changes from development and content teams to client production environments. To support this activity we employ a best practices-based development approach employing test-driven development, pair programming and code review to reduce risk and improve software quality.

Every change to our software and rule content is run through an ever-growing test suite to ensure a minimal amount of risk in this continuous update process. Security considerations are built into our software lifecycle; we identify work items early on that have security implications. We conduct an annual penetration test and supply our clients with the report and a remediation plan.

Deployment of changes to our software is a fully automated and hands-off process.

Platform

FundApps platform is hosted in Amazon Web Services datacentres located in Dublin, Ireland and Frankfurt, Germany. With control over both software and infrastructure FundApps is able to deliver best in class availability and security. The principle of least privilege is applied throughout; at the network, system and software levels to tightly control the availability of data and reduce the potential for security breaches.

Data Security

On our AWS infrastructure, this data is subsequently encrypted at rest and employs a key management system which allows us to rotate the keys used for the encryption of these volumes on a regular basis. Backups are also stored encrypted at rest, meaning data is never available in cleartext.

Access Control

FundApps' web application enforces several layers of access control.

Authentication: Our software allows clients to either use a single-factor authentication mechanism, the native multi-factor authentication mechanism or to integrate the platform with their Single-Sign-On.

Network access control: FundApps is able to provide further access control by applying IP restrictions to client environments, preventing access from networks other than those of the client site. These restrictions operate before any authentication to the system and prevent any requests being made to the application at all.‌

Client Segregation: Individual client environments are isolated at the infrastructure level using separate databases, web and engine instances.

Access Control Audit Trail: A complete audit trail is visible inside the application and allows tracking of all operations taken inside the system, along with user access events. This auditing includes any support activities performed by FundApps staff.

Processes & Controls

We ship all log events generated on the platform to a central store for audit, reporting and alerting activity. Direct access to production systems is strictly restricted to key personnel with a direct operational need, and these accesses are reviewed on a monthly basis.

Monitoring

We have automated monitoring of critical conditions for both infrastructure and software in the platform. These conditions create alerts following escalation policies and where necessary alert operators on a 24/7 basis to preserve the integrity and availability of the platform.

Furthermore, FundApps uses a 24/7 Security Operation Centre (SOC) to detect and respond to security alerts.

Application performance and infrastructure metrics are used for capacity planning and platform management; ensuring there is always sufficient capacity available across the platform to satisfy all demands.

Technical Resilience

Introduction

At FundApps we believe in simplicity, automation and testing in order to deliver high quality software - and that follows through our entire software development process. Testing is a integral part of this - not only through our software development but also our rules team who implement the legal changes made around the world.

Security in project management

These projects must include information security requirements.

An information security risk assessment must be conducted at an early stage of the project to identify necessary controls.

Information security must be applied to all the phases of the applied project methodology.

Change Management Controls

Authorising Changes

Testing changes

All changes are tested with a multi-level test suite (Front End tests, integration tests, unit tests, rule tests, static application security testing as well as Open Source Software License scans) as can be seen in figures 4, 5, 6 and 7. Changes cannot be applied to production if tests fail. Finally, a dynamic application security testing tool scans a client-like environment on a weekly basis.

Approving changes and Segregation of Duties

Emergency changes

All builds are stored allowing to rollback to the last known good build in case of an emergency.

Change Management Steps

1. Work item specified Work items are scoped and defined as development tasks in Shortcut. Potential security issues flagged and discussed at this stage. Items prioritised and tackled by the team (Figure 2)

2. Development work Development or configuration work is performed as scoped and defined in the work item.

3. Pull Request created Once the work is complete, or at intermediate stages for larger work items ‘pull requests’ are created (Figure 3). Pull requests specify the desired changes across files and act as proposals for specific change.

5. Built by CI server All releases and pull requests are compiled on a build server, to check that the artifacts contained in source control are complete.

6. Unit Tests Run All unit tests contained within the test suites are run on the build server to verify that the release functions as specified in an isolated environment. This occurs both on pull requests and on the main branch (Figure 3 & 4).

7. Change merged to main branch Once the pull request has all tests passing and any identified changes to pass review have been made, the pull request is merged to main and becomes a potential release of the system.

8. Test Rule Content with release The test suite maintained for our legislative rule content is run using the logic and algorithms of the proposed new release to confirm behaviour and semantics are maintained.

9. Deploy to main testing environment The proposed release is deployed to a main testing environment, to validate that the release can be successfully deployed and that the resulting instance reports a healthy status.

10. Run Feature Tests A series of automated feature tests, using a scripted web browser covering the key functionality of the system are run (uploading files, viewing results etc). These establish that the proposed release loads correctly and performs the desired tasks.

11. Deploy to main staging environment The proposed release is deployed into a staging environment in our Production network (Figure 5). This verifies that the release can be deployed successfully with production configuration and infrastructure

12. Smoke Test A smoke test is performed by checking the health of the main staging environment and uploading a position file. This ensures that in the production environment, the system is able to accept uploads and process data.

13. Deploy to client performance environment If desired, or if the release presents questions regarding performance impact (identified during the pull request review), the release may be deployed to a specific performance testing environment to examine performance characteristics on the production network before availability to clients.

14. Deploy to client staging environment (automated) Given successful completion of all previous steps and check, a release is promoted to all client staging environments.

15. Deploy to client production environment (automated) Given that a release has been successfully deployed to a client’s staging environment, it is promoted to all client production environments. This process may be conducted for all clients sequentially.

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

The ISMS applies to the shareholding disclosure, position limits, sensitive industries, annex IV reporting and Filing Manager services, which FundApps delivers to its clients. It also applies to the information assets, processes, teams and external service providers which FundApps relies on to provide these services.

Services provided

FundApps’ five main services provided are:

Shareholding Disclosure

FundApps’ Shareholding Disclosure service monitors disclosure requirements for major shareholding, short selling and takeover panels. Position data is uploaded daily and users are alerted to new disclosures. Disclosures are made on time without mistakes.

Position Limits

FundApps' Position Limits service simplifies the process of monitoring position limits on derivative contracts which are imposed by exchanges across the globe as well as regulators (e.g. CFTC, ESMA via MiFID II). Our service informs our clients on where their positions are versus applicable limits and acts as an early warning system.

Sensitive Industries

FundApps simplifies the process of monitoring sensitive industries investment and foreign ownership. Position data is uploaded daily and users are alerted to pre-approval warnings, notifications for disclosure obligations and hard stop breaches.

Filing Manager

Filing Manager automates the disclosure process for short selling reporting. It uses the client-provided data and provides a fully audited service to file for the client. It identifies disclosures for short positions once the position file runs and prepares them to be submitted to the relevant regulator.

Annex IV reporting

AIFMD Annex IV reporting requires detailed disclosures on investor data, risk exposures, liquidity, and financing to enhance transparency in the alternative investment space. We automate data aggregation, centralise workflows, and provide full calculation visibility at every stage.

People

The FundApps departments within the scope of the ISMS are:

• Client Services – On-board clients and assist them throughout their experience with our software.

• Regulatory team– Help to ensure rules correctly mirror current regulation.

• Finance – Manage FundApps’ budget, cash flow, tax planning and record keeping.

• People Operations – Team responsible for employer brand, recruitment and on-boarding through to development, reward and recognition.

• Product – Design and develop products to achieve the company’s objectives.

• Engineering – Manage and maintain system architecture and design for all hosted clients.

At a high level, the following executives and teams support FundApps’ processes and services:

• CEO – Assigns authority and responsibility for operating activities and reporting relationships. FundApps’ CEO defines and communicates the company’s objectives.

• Global Head of Client Services – Takes the lead in owning FundApps client portfolio and drive cross-team collaboration to support FundApps’ objectives.

• Chief Product Officer – Accountable for all product management and content team activities globally.

• Chief Technology Officer – Provides direction and decision making on what technologies to use, the architecture of the platforms and best technical practices to follow.

• Chief Revenue Officer– Accountable for all sales activities within the region and as the People Leader for the Regional Sales team.

• Head of People – Reporting directly to the CEO, the head of People Operations smooths the next phase in growth as FundApps scales.

• Head of Information Security – Responsible for managing Information Security, Cyber Security and Business Continuity risks potentially impacting FundApps.

Offices

FundApps operates out of three offices:

• 18th Floor, HYLO, 105 Bunhill Row, London, EC1Y 8LZ, United Kingdom

• 276 5th Ave, Suite 808, New York, NY 10001

• #13-135, 71 Robinson Road, 068895, Singapore

Infrastructure

FundApps services make use of a resilient infrastructure, which is hosted within multiple data centres (availability zones) and regions operated by Amazon Web Services. There are two environments with a primary environment made up of three data centres within a single geographic region, from which the service is provided in normal operation. There is also a secondary environment in an alternate geographic region, which is used in case the primary environment is unavailable. Each of the three data centres within the primary environment have discrete power and Internet connectivity. FundApps’ primary environment is designed to continue to provide its service should two of the three centres suffer concomitant failures. Should the whole primary environment fail, FundApps has procedures to recover its service in the secondary environment. The critical components of this highly available infrastructure include:

• Proxy servers, which filter inbound traffic and route them to the correct service;

• Serverless computing elements and containers which perform apply rule sets analysis of FundApps clients’ financial positions and provide clients with a web user interface and an application programming interface (API); and

• Databases, which store the results of this analysis, as well as objects and events related to client environments.

Software and Tools

FundApps relies on various applications, tools, and infrastructure components to support its information security management system.

FundApps' platform consists of software that supports its applications, including software for our build pipeline, deployment tools used to deploy to AWS environments, and automation software for managing cloud infrastructure changes.

In addition, FundApps utilises systems for:

• Identity and Access Management to control authentication and authorisation.

• Development and Change Management to track and manage software changes securely.

• Security Monitoring and Threat Detection to protect against, detect, and respond to security threats.

• Communication and Collaboration to facilitate internal and external information sharing.

• Customer Support and Relationship Management to manage client interactions and service requests.

FundApps is committed to a robust implementation of Information Security Management. All our hosting environments are certified to ISO 27001. As an organisation we are endeavour to align our processes to ISO 27001 and the NIST Cyber Security Framework.

We are specifically committed to preserving the confidentiality, integrity and availability of data and documentation supplied by, generated by and held on behalf of our clients. The principles defined in this policy will be applied to all of the physical and electronic information assets for which the FundApps is responsible.

Our senior management team are directly responsible for ensuring that all FundApps staff have been made aware of these procedures and their contents.

All employees have access to this information, are required to abide by them, and are encouraged to regularly review and update these in their relevant areas.

Definitions

Information security is the practice of preventing unauthorized access, use, disclosure, disruption, modification, inspection, recording or destruction of information. It focuses primarily on the confidentiality, integrity and availability of data.

FundApps Data, for the purposes of this policy, is data owned, processed or held by FundApps, whether primary or secondary, irrespective of storage location. It is used interchangeably with the term ‘information’.

Context of the organisation

FundApps, headquartered in London, United Kingdom, helps investment managers to harness the power of community and technology to automate regulatory compliance.

There are a number of internal and external factors that create uncertainty that gives rise to risk. These include:

Internal Issues

Information

• FundApps processes the following types of information which require adequate protection:

  • sensitive client information,

  • personal data,

  • Sensitive FundApps Intellectual property.

People

• Staff turnover,

• Induction of new joiners,

• Staff role changes,

• High rate of recruitment due to rapid growth.

Organisation

• Use of contractors,

• Staff working in different time zones.

Products/Services

• Alignment of products with evolving regulations,

• FundApps services’ competitive advantage relies partly on its intellectual property.

Systems and Processes

• Security or resilience issues with FundApps' information systems,

• Lack of process documentation.

External Issues

Political Factors

• War in Eastern Europe,

• Divergence of regulations between the UK and EU following Brexit,

• Changes made to regulations.

• Commercial war between the USA and China

Economic Factors

• Economic recession,

• Market conditions affect our client's ability to subscribe to FundApps’ services,

• Higher staff costs due to increasing demand for software engineers or regulatory experts in a constrained market.

Social Factors

• Increase in working from home and bring your own devices practices.

• Public services industrial action in the UK.

Technological Factors

• Fast-evolving threat landscape (e.g. ransomware campaigns),

• Increased expectations from clients to manage their own security (e.g. Bring Your Own Key, feed export logs to client SIEM).

• Rise of Artificial Intelligence.

Environmental Factors

• Pandemic affects how people work.

Legal Factors

• More lenient financial regulations makes our products less appealing.

• Regulations on personal data such as GDPR

• Regulations on access to MNPI and insider trading.

• Technology related legislation, such as the Computer Misuse Act 1990 or Freedom of Information Act 2000

• Intellectual property concerns related to the use of open source software.

Objectives

The objectives of the ISMS are:

Scope

Information security principles

The following eight information security principles provide overarching governance for the security and management of information at FundApps.

3. Staff with particular responsibilities for information are responsible for ensuring the classification of that information; for handling that information in accordance with its classification level; and for any policies, procedures or systems for meeting those responsibilities.

4. All users covered by the scope of this policy must handle information appropriately and in accordance with its classification level.

5. As far as is reasonably possible, endeavours must be made to ensure data is complete, relevant, accurate, timely and consistent.

6. Information should be both secure and available to those with a legitimate need for access in accordance with its classification level.

7. Information will be protected against unauthorized access and processing in accordance with its classification level.

8. Information will be protected against loss or corruption.

9. Breaches of this policy must be reported

Legal & Regulatory Obligations

FundApps has a responsibility to abide by and adhere to all current UK and EU legislation as well as a variety of regulatory and contractual requirements. Relevant legislation includes: • The Computer Misuse Act 1990 • General Data Protection Regulation 2018 • Data Protection Act 2018 • The Freedom of Information Act 2000 • Regulation of Investigatory Powers Act 2000 • Copyright, Designs and Patents Act 1988 • Defamation Act 1996 • Obscene Publications Act 1959 • Protection of Children Act 1978 • Criminal Justice Act 1988 • Digital Economy Act 2010

A non-exhaustive summary of the legislation and regulatory and contractual obligations that contribute to the form and content of this policy is provided below. Related policies will detail other applicable legislative requirements or provide further detail on the obligations arising from the legislation summarised below.

Key Legislation Summary

The Computer Misuse Act 1990 defines offences in relation to the misuse of computers as:

1. Unauthorised access to computer material.

2. Unauthorised access with intent to commit or facilitate commission of further offences.

3. Unauthorised modification of computer material. 3ZA: Unauthorised acts causing, or creating risk of, serious damage 3A: Making, supplying or obtaining articles for use in offence under section 1, 3 or 3ZA

The General Data Protection Regulation 2018 (GDPR) defines obligations for businesses and organisations that collect, process and stored individuals' personal data. GDPR outlines seven data protection principles which relate to:

1. Lawfulness, fairness and transparency

2. Purpose limitation

3. Data minimisation

4. Accuracy

5. Storage limitation

6. Integrity and confidentiality (security)

7. Accountability

Data Protection Act 2018

GDPR and DPA 2018 are based on the same principles. The main differences between the two are around:

• Freedom of information,

• Compliance reports,

• Data subject access request,

• Age of consent,

• Information Commissioner’s Office codes of practice,

• National security and crime.

Supporting Policies, Codes of Practice, Procedures and Guidelines

Compliance, Policy Awareness and Disciplinary Procedures

Any security breach of FundApps information systems could lead to the possible loss of confidentiality, integrity and availability of personal or other confidential data stored on these information systems. The loss or breach of confidentiality of personal data is an infringement of the Data Protection Act 1998, contravenes FundApps Data Protection Policy, and may result in criminal or civil action against FundApps.

The loss or breach of confidentiality of contractually assured information may result in the loss of business, financial penalties or criminal or civil action against FundApps. Therefore it is crucial that all users of the FundApps information systems adhere to the Information Security Policy and its supporting policies as well as the Information Classification Standards.

All current staff and other authorised users will be informed of the existence of this policy and the availability of supporting policies, codes of practice and guidelines.

Any security breach will be handled in accordance with all relevant FundApps policies, including the Conditions of Use of IT Facilities at FundApps and the appropriate disciplinary policies.

Incident Handling

Review and Development

This policy, and its subsidiaries, shall be reviewed by FundApps and updated regularly to ensure that they remain appropriate in the light of any relevant changes to the law, organisational policies or contractual obligations.

FundApps ensures that all changes to the ISMS are carried out in a planned and controlled manner, in alignment with our Continual Improvement Process.

Interested Parties

The list of interested parties in FundApps' ISMS and their requirements are as follows:

• 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.

Analysis of performance

Based on these indicators, FundApps will assess whether its ISMS is performing efficiently and whether root causes of underperformance are being identified and managed appropriately.

Management Review

At least once per calendar year, a review of the ISMS will be done to ensure its continuing suitability, adequacy and effectiveness.

Attendees

The annual management review meeting will have the following attendees:

• the ISMS Implementer,

• the ISMS Manager, and

• at least one member from the Leadership Team, which can be the ISMS Manager.

Agenda

The agenda will include the following topics:

1. Status of actions from previous management reviews

2. Relevant changes in external and internal issues

3. Performance of the ISMS

   1. Audit results, non-conformities and corrective actions

   2. Monitoring and measurement results

   3. Information Security Objectives

4. Feedback from interested parties

5. Results of risk assessment and status of the risk treatment plan

6. Opportunities for continual improvement

Statement of Applicability version 2025-02. The following table summarises the controls that are relevant and applicable to FundApps' Information Security Management System in accordance with the requirements of ISO 27001:2022.

The following table describes the plan for 2025 to achieve FundApps' objectives.

Information Security Management System > Objective Plan

Updated the ISMS objective plan with 2023 objectives set out during the December ISMS Performance review.

Information Security Management System > Performance Evaluation

Updated the ISMS performance evaluation following the December ISMS Performance review.

Objective

Define the version control, change approval and review cycle of FundApps policies.

Scope

FundApps Information Security , Risk management and business continuity policies.

Policy

Version control

Policies in scope shall be versioned through the use of git. Any change to a policy will be tied to a commit number and an author. This information will be stored in the policies git log.

Change approval

Policies in scope shall be approved by a member of the leadership team. These approvals will be stored in the policies git log.

Review Cycle

Policies in scope shall be reviewed annually by the Head of Information Security and at least one member of the Leadership Team.

At FundApps, we are dedicated to providing the highest support quality while ensuring consistent data confidentiality, integrity, and availability.

As such, there are certain actions we can (and cannot) take on your behalf. The following is a list of some of the work practices you can expect from us:

What we do

• We use secure virtual desktops to access client platforms.

• We provide a valid and unambiguous reason every time we log into a client environment (reviewable at any time in the audit trail).

• We may click the "Validate File" button to troubleshoot failed file validations

• We may download/export relevant files to conduct necessary analysis to troubleshoot unexpected behaviour (i.e. disclosure documents, positions and portfolio files). These files will only be downloaded to secure virtual desktops and destroyed when no longer required.

• We may create or edit Companies as part of the environment setup. Subsequent changes must be based on a written request from a client with administrator privileges.

• We verify all calls made to our support line are from legitimate users of our platform.

What we are unable to do

• We cannot create or edit any users (except the initial admin users when setting up the environment)

• We cannot create or edit any data overrides

• We cannot upload any files to client environments (except disaggregations & imported disclosures as part of the initial setup)

• We cannot interact with results, except when downloading already generated documents to support

• We cannot action any tasks, including approving any rules

• We cannot download any files from a client’s platform anywhere except a secure virtual desktop.

• 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.

Objective

This policy defines the internal audit process of FundApps' Information Security Management System (ISMS).

Scope

Frequency and Coverage

Internal audits shall be performed against FundApps' ISMS at planned intervals at least once per year.

Over a three year period there will be three internal audits:

• one audit will cover the entire scope of the ISMS

• two audits will cover at least one third of the ISMS.

Internal Auditor

The internal auditor shall be appointed by the ISMS Manager. The auditor and may be a member of FundApps or an external trusted third party auditor. Auditor selection shall be done to ensure objectivity and the impartiality of the audit process.

Internal Audit Process

Audit Planning

Audits shall be planned in advance and the ISMS Manager shall be notified no less than 5 business days ahead of time.

The internal auditor shall prepare the audit plan which shall define the scope of the ISMS, including the scope of the controls, which shall be audited.

Amongst others, the audit plan must take as an input the following items:

• Security related incidents that have occurred since last audit;

• Changes made to the Information Security Policy;

• Changes made to Information Security controls;

• Improvements made to the ISMS.

The resulting audit plan must be validated by the ISMS Manager.

Upon validation the ISMS auditor must communicate the plan to the interested parties.

Audit Preparation

The internal auditor shall collect and study the previous audit findings and outstanding issues. They shall also prepare relevant documents required for the audit (e.g. ISMS Audit checklist).

Conduct Audit

During the audit, the internal auditor shall find relevant evidence to ascertain that:

• The information security policy reflects the current business requirements;

• An appropriate risk assessment methodology is being used;

• Documented procedures (within the scope of the ISMS) are being followed and are meeting their objectives;

• Controls are in place and working as intended;

• Residual risks have been assessed correctly and are within FundApps' risk appetite and risk tolerance levels;

• The agreed actions from the previous audits have been implemented;

• The ISMS is compliant with ISO 27001.

Audit Reporting

The internal auditor shall prepare an audit report based on the audit findings. Findings shall be labelled according to their severity and priority level:

• Major Non-Conformity - This pertains to a major deficiency in the ISMS and exists if one or more elements of the ISO/IEC 27001: 2022 Information Security standard is not implemented and this finding shall have a direct effect on information security, specifically on the preservation of confidentiality, integrity and availability of information assets.

• Minor Non-Conformity - A minor deficiency. One or more elements of the ISMS is/are only partially complied with. Minor non-conformities have an indirect effect on information security.

• Observations/Potential Improvements – An audit recommendation for improvement for consideration by FundApps.

The internal auditor shall send the audit report to the ISMS Manager and the ISMS Implementer.

Audit Remediation

According to the audit findings and the non-conformity levels, an action plan and potential follow-up audit shall be defined by the ISMS Implementer and validated by the ISMS Manager. The scope of a follow-up audit is limited to the non conformity and the same mechanisms that produced the finding are used.

Appendix

Internal Audit Template

Roles and Responsibilities

ISMS Manager

The CTO shall ensure FundApps allocates the appropriate resources to ensure the ISMS' conformity with the ISO 27001 standard and shall report the performance of the ISMS to the Leadership team.

ISMS Implementer

The Head of Information Security shall maintain the ISMS, assess its conformity with the ISO 27001 standard, define appropriate corrective actions and report its performance to the CTO.

ISMS Internal Auditor

The internal auditor, who can be a staff member or a consultant, shall perform an impartial internal audit against the requirements of the ISO 27001 standard, and follow-up on the internal audit results to achieve continual improvement.

Leadership Team

The leadership team will ensure the performance of the ISMS aligns with FundApps' business objectives.

FundApps staff

Finally all FundApps staff members contribute to the ISMS, FundApps' security policies and procedures.

Organisation

The following diagram details the organisation between the staff who have a role in the ISMS.

Competence

FundApps assesses the competencies of those who play a role in the ISMS based on the table below:

If gaps are identified with the required competencies, FundApps will define a set of actions to remediate it. These actions may include training, mentoring or hiring or contracting competent persons.

Internal communication regarding this ISMS will be conducted as described below:

This plan describes how the Internal Audit will be split over 3 years, so that every 3 year cycle the entirety of FundApps' Information Security Management System has been audited.

Once a cycle of 3 years is completed, a new 3 year cycle will begin.

Year 1

This internal audit shall cover the following elements:

• Clauses 4 to 10;

The audit will be performed before the end of June of year 1.

Year 2

This internal audit shall cover the following elements:

• Clauses 4 to 10;

The audit will be performed before the end of June of year 2.

Year 3

This internal audit shall cover the following elements:

• Clauses 4 to 10;

The audit will be performed before the end of June of year 3.

Whether it's a USB stick left on a train, a website hack leading to stolen confidential information, or phishing attacks compromising accounts - IT security is in the news more and more.

FundApps is privy to sensitive client information daily, and therefore it’s important a proactive approach to security is taken. Our policies captured in this living document are therefore the responsibility of everyone in the Company to uphold and update. With suggestions and improvements be raised and addressed as required with the team and the CTO.

NOTE: Security doesn't stop when you leave the office. This policy applies to both FundApps provided equipment, but also any other equipment you may use to access FundApps systems or software.

Guiding principles & security awareness

Top tips

• Better safe than sorry. Use common sense. If you're not sure whether something is a good idea (downloading a piece of software, opening an email, leaving a laptop unattended, using a particular third-party service) - it probably isn't. Discuss it with the team!

• Educate yourself - read about a security breach? Find out how it happened and why. Think about whether there's anything we could do differently at FundApps to stop it from happening here. Also, see "other reading".

• If you know or suspect a loss or theft of confidential information has occurred or the security or integrity of any system has potentially been compromised - report it immediately to the Head of Information Security, CTO and CEO. Keep trying until they confirm they are aware.

Raising others awareness

Don't just educate yourself, share with the team.

• Join our #ask-security channel in Slack

• Read about a recent security breach at a company? Find a link that talks about what happened in detail and share it in Slack with the company

• See someone leaving their screen unlocked? Lock it for them, and make sure they know you did!

Security Musts

This applies to all computers you access FundApps platforms from, not just your work computer.

• Hard disk encryption enabled (BitLocker, FileVault).

• Windows update enabled and configured for automatic update installs.

• Anti-virus software must be installed and configured for automatic updates.

• Make sure your computer password meets our minimum security requirements. It should be at least 12 characters.

• Set your PC so it will automatically lock after 5 minutes.

• Only install applications from official application stores (e.g. Microsoft Store, App Store, Google Play).

Daily habits

• Lock your computer whenever you leave it unattended.

• Keep your desks clear of any printed material and keep those containing sensitive data locked away.

Policies

Credentials

• Use a different password for each service you access.

• Use two-factor authentication whenever available (we enforce this for services where we can, such as Google Mail and GitHub).

• Use secure passwords (minimum 12 characters in length).

• Never share individual account credentials.

• Immediately change compromised credentials and report the compromise to the Information security team.

Bring your own device

• Any mobile device accessing FundApps email must have a secure PIN set and remote-wipe software installed.

• Any device you use to access the FundApps platform or related services must comply with our security checklist (cf. Security Musts) - this includes but is not limited to - hard disk encryption, antivirus, a secure password and a 5-minute lock timeout.

• Bring Your Own Devices compliant with these rules may be used to access all FundApps systems, provided access to production systems is done through virtualised systems or bastion hosts.

• Confidential data must not be stored on BYODs.

Email

• Email is not a secure medium. You should be conscious of this and consider how emails might be used by others. Emails can be spoofed (not come from the person you expect) and intercepted.

• If your Email account is breached this is often a route into accessing many other services (given the reliance on email-based password resetting). You should never use your email password for other services.

• When sending attachments containing FundApps confidential information, you should use a password-protected archive and share the password via a secondary, unrelated channel (such as SMS)

• Remember that emails can easily be taken out of context, that once an email is sent you cannot control what the recipients might do with it, and that it is very easy to forward large amounts of information.

• Similarly, you should not necessarily trust what you receive in an email - in particular, you must never respond to an email request to give a username or password.

Physical security

• Lock your computer whenever you leave it unattended.

• Any computer equipment should be secured behind locked doors when left unattended.

• Any unattended portable equipment should be physically secure if possible, for example, locked in an office or a desk drawer. When being transported in a vehicle they should be hidden from view. Staff should avoid storing sensitive information on portable equipment whenever possible (see data security section).

• Enable 5-minute screen savers on your computer. (Go to Screen Saver settings, wait 5 minutes, and check On resume, display logon screen).

Data security

FundApps attaches great importance to the secure management of the data it holds and generates and will hold staff accountable for any inappropriate mismanagement or loss of it.

• If a client emails you sensitive portfolio data, please advise them that they should not be doing this.

• Do not create users for clients, even if you know them. Every client has an Admin user who can create users for themselves.

• • If you need to debug client portfolio data, you should use our secure VMs in our production environment.

  • Client data (of any kind) should never be stored on mobile devices or taken off-site (with the exception of email).

  • Failure to comply with these requirements will be considered a serious breach of this policy.

Acceptable use

Internet access is provided as a critical aspect of our business. It should be used in a responsible manner and any personal use should be reasonable. The Internet may not be accessed and used for any of the following:

• Any activity that would violate the laws and regulations of the UK

• Sending offensive or harassing material to other users

• Any activity that would violate the privacy of others

• Cause damage or disruption to organisational systems

Monitoring

Monitoring software is in use to protect the effectiveness, security, availability and integrity of FundApps systems. We monitor the type and volume of internet and network traffic. The information recorded can be used to identify an individual user and the website domain being accessed.

Working from outside the office

Whether you are working from home or from a public place (e.g. whilst travelling) you must ensure you keep our data and Information System secure. This means that you must:

• lock your laptop whenever you leave it unattended;

• ensure others cannot read sensitive information (e.g. Client data) by looking over your shoulder (order a privacy screen if needed);

• ensure sensitive conversations cannot be overheard by others;

• do not let anyone use your corporate devices.

Breaches of security

If you know or suspect a loss or theft of confidential information has occurred, or the security or integrity of any system has potentially been compromised - report it to the Head of Information Security, the CTO or the CEO. This could include

• The disclosure of confidential information to any unauthorised person.

• The integrity of any system or data being put at risk (for example virus, malware, hacking).

• Availability of the system or information being put at risk.

• Loss of any system, laptop, mobile phone or other portable device.

• Finding doors and/or windows broken and/or forced entry gained to a secure room/building in which computer equipment exists.

Further reading

For general awareness, we recommend the following sites.

For more technical information, check out

Introduction

Whatever part of FundApps we work in we are ambassadors for our company.

Lots of us are having conversations and sharing through social media or online communities. We approach the online world in the same way we do the physical one – by using sound judgement, respect and common sense.

Who’s this policy for?

It applies to anyone working for and on behalf of FundApps. This policy doesn’t form part of your contract and may be amended at any time.

What types of social media does this cover?

This policy covers the use of any online platform which can be used for networking, sharing information or opinions. This includes posting comments, pictures, videos, blogging, using forums, sending private messages relating to FundApps its clients or colleagues, endorsing other people’s content and re-tweeting/circulating posts. It covers platforms like YouTube, LinkedIn, Facebook, Twitter, Instagram, Pinterest, Yammer and Instant Messaging services e.g. WhatsApp, etc., or any other existing or new social media platforms, whether it’s internal or external on your own or a work device.

Can I say that I work for FundApps on my profile?

If you want to then yes you can; just make sure it’s clear that you’re not speaking on behalf of FundApps and say that ‘all views are my own’ somewhere on your profile.

How should I use social media (including internal sites)?

Be yourself

If your profile mentions FundApps, be honest about who you are and what you do. Never share your login details or let others post on your behalf. If you’re leaving, remember to update your profile with your new company name or employment status.

Be respectful

Be respectful to other people, even if you disagree with their opinion.

Don’t post things or send messages that could damage our reputation, bring the company into disrepute or cause actual or likely harm to the company or colleagues.

Don’t use statements, photos, videos, audio or send messages that reasonably could be viewed as malicious, abusive, offensive, obscene, threatening, intimidating or contain nudity or images of a sexual nature, or that could be seen as bullying, harassment or discrimination.

Use common sense

You’re responsible for what you put online and any impact it has on others so set up privacy settings if you need to. Never give out personal or private information about colleagues or clients. As a general rule, if you wouldn’t say or show it to your manager, then it’s probably not appropriate to post or send it online!

And remember, what you post or send can be difficult to delete once it’s online.

Be aware

Help us protect our company and reputation by thinking carefully about what you put online. If you see something online that concerns you please talk to the senior management team.

Did you know?

Even when you say something is your personal opinion we can still be held liable, so pause and think before you post.

You should never assume your social media content won’t reach a wider, public audience. Even if it was originally meant for a small group of friends or for a private message, colleagues or clients may have access to things you put online.

Disseminating confidential or sensitive information; or posting, sharing or endorsing inappropriate messages about your colleagues or FundApps, could result in disciplinary action, which could lead to your dismissal.

Protecting our business

To help protect our business anything you develop or create, including programs or documentation, whilst working for us remains the property of FundApps and must not be used or shared on social media sites or online forums, unless you have specific permission from your director to do so.

Never reveal confidential or sensitive information including anything that is given to us in confidence by suppliers or third parties.

This includes information about FundApps which is not in the public domain.

Respect intellectual property laws

Intellectual property laws (which include copyright and trademarks) are in place to protect the ideas people have, create or develop so that other people can’t steal or use them without permission. For example, FundApps is our trademark, which means we can stop other people from using it on their products.

We must always take care to protect intellectual property rights and respect the rights of others. Stealing someone’s idea can reflect badly on FundApps and damage client trust.

Most forms of published information are protected by copyright, which means you shouldn’t re-use it without getting the owner’s permission first.

Copyright applies to stuff that’s used both internally and externally so make sure you always respect copyright and see permission first – even if it’s only being used within FundApps. Copyright can also apply when sharing content on Twitter and Facebook, so be mindful when doing this.

Can I use my FundApps email address when I’m using social media?

You should use your personal e-mail address unless you’re speaking on behalf of the company (and are authorised to do so).

Can I use the company logo, brand name or pictures of the office etc. in my posts?

Yes, as long as it’s connected with work, appropriate to post, does not reveal confidential information and any people in the photo are happy for it to be posted.

Can I use social media during working hours?

Yes, if you’re using social media for part of your job or it’s related to work (for example, to help a client). Otherwise, using social media during working hours must be reasonable and shouldn’t interfere with you carrying out your job.

What should I do if I see a colleague has posted something offensive or inappropriate on line?

If it’s something that’s personally offensive to you, you should speak to the person involved, if you’re comfortable to do so, and ask them to remove the post. If the posts aren’t removed or it happens again you should speak to your manager about it. If the post is directly about you, and has been posted without your consent or you’re offended by it, or it’s inappropriate, please speak to your manager or the senior management team.

If you endorse, share or send an offensive or inappropriate comment or message about FundsApps or your colleagues, it will be investigated and may result in us taking disciplinary action against you, which could lead to your dismissal.

If the post contains company information which you believe to be confidential (basically something which isn’t already in the public domain), you should report this immediately to our CTO and security@fundapps.co.

Is social media monitored?

Yes. Social media sites are scanned for any mention of FundApps, our products and services or inappropriate comments about the company, our colleagues, managers or clients. If you spot anything that’s been posted about our business that concerns you please contact the senior management team.

Inappropriate behaviour including posting confidential or sensitive information will be investigated, and may result in us taking disciplinary action against you which could lead to your dismissal. You will be asked to co-operate with any investigation.

If it comes to our attention that any inappropriate posts, comments or messages have been made/sent by you or can be viewed on your profile, then we reserve the right to access these posts and to take copies of them. You may also be asked to remove any content that we consider to be a breach of this policy. If you don’t remove the content when asked, it may result in disciplinary action. Any such posts may be used in internal proceedings and/or legal action.

We treat the online world the same as the physical one, so if your post, comment or message would breach our policies in another forum it will breach it in an online forum too.

For anyone else not directly employed by FundApps: if you breach this policy we may terminate the arrangements we have with you for your services.

Data Center Physical Security Overview

All data hosted in FundApps’ platform is hosted in facilities with top grade physical security. These facilities are located within the EU with Amazon Web Services (AWS). AWS hold industry standard certifications relating to security and availability, including but not limited to ISO 9001, 27001 and SOC I, II certifications. Full details of the certification activities undertaken by our hosting partner are available via AWS compliance.

Data Center Access Control

AWS provides physical data center access only to approved employees. All employees who need data center access must first apply for access and provide a valid business justification. These requests are granted based on the principle of least privilege, where requests must specify to which layer of the data center the individual needs access, and are time-bound. Requests are reviewed and approved by authorized personnel, and access is revoked after the requested time expires. Once granted admittance, individuals are restricted to areas specified in their permissions.

Third-party access is requested by approved AWS employees, who must apply for third-party access and provide a valid business justification. These requests are granted based on the principle of least privilege, where requests must specify to which layer of the data center the individual needs access, and are time-bound. These requests are approved by authorized personnel, and access is revoked after request time expires. Once granted admittance, individuals are restricted to areas specified in their permissions. Anyone granted visitor badge access must present identification when arriving on site and are signed in and escorted by authorized staff.

FundApps Offices Physical Security

All FundApps offices are protected by locked doors which can be opened only with a valid access card or valid fob, and by CCTV. Doors to the building are equipped with alarm systems which trigger if they are forced open. Visitors are escorted throughout their visit to our offices.

FundApps backups production data to local storage at the following frequency:

• FundApps continuously backups production data to a hot standby instance in the same region but a different availability zone (generally <100ms RPO, <5 minutes RTO).

• Backups are continuously replicated to a cold standby instance in a secondary region (generally <500ms RPO, <1 hour RTO).

Seven days of full snapshot history are stored in RDS snapshots in the primary and secondary regions. Each backup contains the entire history of the client instance. Backup integrity is checked automatically at the end of each backup. Backups are fully encrypted.

Objective

This process aims to allow FundApps to continually improve the suitability, adequacy and effectiveness of the information security management system.

Scope

ISMS Change Management Process

Nonconformities of FundApps' Information Security Management System with ISO 27001:2022.

Policy

ISMS Change Management Process

FundApps ensures that all changes to the Information Security Management System are carried out in a planned manner and controlled in accordance with ISO 27001 Clause 6.3.

To ensure a structured approach to ISMS changes, FundApps follows these key steps:

1. Identifying & Assessing Changes

• Changes may be identified through internal reviews, ISMS performance reviews, audits, risk assessments, regulatory updates, or feedback from stakeholders.

• Each change is assessed for potential impacts on security objectives, risk posture, and existing controls.

1. Planning & Approval

• Changes are reviewed and approved by relevant stakeholders before implementation to ensure alignment with security and business objectives.

1. Implementation & Documentation

• Approved changes are implemented following a structured approach to minimise security risks and operational disruptions.

• All changes are documented in accordance with FundApps' record-keeping requirements.

1. Monitoring & Review

• The effectiveness of implemented changes is monitored to ensure security objectives are met.

• Any unintended consequences are reviewed, and corrective actions are taken as necessary.

1. Control of External Processes

• Any externally provided processes, products, or services that impact the ISMS are reviewed and controlled to maintain compliance and security integrity.

Management of nonconformities

FundApps shall implement the following process when nonconformities arise:

React to the nonconformity

FundApps shall react to the nonconformity as applicable by taking action to control and correct it and deal with its consequences.

Non-confirmities can be identified daily through the use of FundApps' compliance monitoring tool, during annual internal audits, during the ISMS performance review and during the annual risk assessment.

Evaluate the root cause

FundApps shall evaluate the need for action to eliminate the causes of the nonconformity to ensure it does not occur again.

To do so FundApps shall:

• review the nonconformity;

• determine the cause of the nonconformity; and

• determine if similar nonconformities exist or could potentially occur.

Remediate root cause

FundApps shall implement actions required to address the root cause of the nonconformity.

Determine effectiveness of the remediation

FundApps shall review the effectiveness of the remediation actions which have been taken and make further changes to the ISMS if necessary.

Retain evidence

FundApps shall retain evidence of:

• the nature of the nonconformities and any subsequent action taken, and

• the result of any remediation actions.

Access Control

FundApps implements physical and logical access controls across its IT systems and services in order to provide authorised, granular, audit-able and appropriate user access, and to ensure appropriate preservation of data confidentiality, integrity and availability in accordance with our Information Security Policy.

• An owner responsible for managing user access

• The types of data it holds and therefore the data classification and controls required to protect that information.

• Status of basic controls such as SSO and two-factor

FundApps' Identity and Access Management system allows to simplify and automate the on-boarding and off-boarding processes in terms of provisioning and de-provisioning accesses to systems.

Logical access controls for FundApps Platform

User Interface

Support staff access the platform through the same interface our clients do. As such, controls in place include:

• Access via HTTPS only;

• Named accounts using Single sign-on (SSO) and two-factor authentication;

• Audit logs of support staff accessing the system, which is visible to our clients;

• Access is granted on a least-privilege and need-to-know basis;

• Access review by head of Client Services on a quarterly basis.

Additionally, we provide clients with the option to enable Just-In-Time (JIT) access feature. This is a dynamic access control method that allows our Client Services staff to have temporary permissions to a client's environment only when necessary and for the duration required to complete specific tasks.

JIT has a number of benefits:

• FundApps staff do not have default access to client data.

• Access is granted and revoked by clients with the Administrator role.

• Application access is restricted to predetermined time periods and designated FundApps staff members only.

• Access is time-limited, automatically expiring once the predetermined period concludes.

• As is currently the case, access is documented in the audit trail.

It is important to note that if you ask us to enable JIT and subsequently fail to grant CS access for support purposes in a timely manner, this may result in missed service levels or other consequential issues for which we cannot be held responsible. It is imperative that all necessary access permissions are granted promptly to ensure our ability to meet agreed-upon service standards.

Production

Access to our production network is restricted to a very small set of staff. Controls in place include:

• All credentials and accounts are provisioned through a configuration change management system that requires approval of the change;

• Access to the network must be made via a secure connection through the use of multi-factor authentication.

• Each member of operational staff uses a named account to each server where access is required which is separately provisioned from the above network access;

• Access is granted on a least-privilege and need-to-know basis;

• Access is subject to Just-In-Time (JIT) and peer approval;

• All access to and key administrative actions on production servers are logged to a centralised audit store;

• Access review by CTO on a quarterly basis.

Logical access controls for all IT systems

• Named accounts are mandatory, unless an exception is granted by the data owner responsible.

• Any built-in, default accounts should be disabled or renamed and passwords changed

• Single-sign-on should be enabled and mandatory wherever possible

• Two-factor should be enabled and mandatory whenever possible

• Passwords should not be re-used across systems. Passwords should be stored using an approved password management tool with a strong master password.

• Use secure passwords (minimum 12 characters in length).

• Audit logs must provide non-repudiation for changes and access to FundApps Restricted and Confidential data

See our data classification policy for more information on the specific controls in place.

Physical access controls

Types of Authentication mechanisms supported by FundApps' platform

Roles and privileges in FundApps' platform

Objective

The purpose of this policy is to define the way in which FundApps raises, approves, records and reviews exceptions to its information security policies.

Scope

This policy applies to all exceptions to FundApps' security policies.

Policy

Raising Exceptions

All exceptions must be raised to the Head of Information Security, the CTO, or the CEO and approved before the event. Ensure that items are recorded appropriately in either the Security Exception Log or the Incident Log.

Approving Exceptions

Exceptions must be approved by the Head of Information Security, the CTO or the CEO.

Recording Exceptions

Reviewing Exceptions

Exceptions will be reviewed by the Head of Information Security annually.

Objective

The purpose of this policy is to define the way in which FundApps detects, classifies, mitigates and corrects vulnerabilities on its Information System. Effective implementation of this policy will allow to reduce the probability and/or impact of vulnerabilities affecting the FundApps Information System

Scope

This policy applies to applications and infrastructure which makes up FundApps’ production environment. Physical vulnerability management is out of scope of this policy and managed by our hosting provider (AWS).

Vulnerability Detection

FundApps uses several layers of security controls to detect and remediate vulnerabilities:

• A human-led penetration test performed by a CREST-accredited company is performed annually.

• Static Application Security Testing (SAST) is performed against any change before being deployed to production.

• Dynamic Application Security Testing (DAST) is performed against our platform weekly.

• Infrastructure vulnerability scanning is performed against our infrastructure weekly.

Vulnerability Severity Ratings

• Applications
• Infrastructure

Vulnerability Acceptance, Mitigation and Correction

• Process

  Once vulnerabilities have been identified, rated and formalised, FundApps will manage risk treatment based on the following diagram:

By default, and as a maximum, the vulnerability acceptance period will be one year.

• Applications

  FundApps will endeavour to address vulnerabilities based on their severity as defined in the following table:

(*) number of working days after application vulnerability report is formalised. (**) Critical or High vulnerabilities will not be accepted. In the worst case scenario FundApps will mitigate these to reduce the risk to Medium.

• Infrastructure

  FundApps will endeavour to address infrastructure vulnerabilities based on their severity as defined in the following table:

(*) number of working days after vulnerability has been identified.

A rapid response to incidents that threaten the confidentiality, integrity, and availability (CIA) of FundApps information assets, information systems and the networks that deliver the information is required to protect those assets. Without a rapid response, those assets could be compromised and FundApps could be in breach of legislation, our own stated policies, and the potential of of breaching the trust of our clients and users.

Information Security incidents will occur that require full participation of FundApps technical staff as well as management leadership to properly manage the outcome. To accomplish this FundApps has established an incident response policy and procedures that will ensure appropriate leadership and technical resources are involved to:

• assess of the seriousness of an incident

• assess the extent of damage

• identify the vulnerability created

• estimate what additional resources are required to mitigate the incident

It will also ensure that proper follow-up reporting occurs and that procedures are adjusted so that responses to future incidents are improved.

1. Scope & Objectives

The primary emphasis of processes and activities described within this policy is the return to a normal (secure) state as quickly as possible, whilst minimising the adverse impact to FundApps. The capture and preservation of incident relevant data (e.g., network flows, data on drives, access logs, etc.) is performed primarily for the purpose of problem determination and resolution. Strict forensic measures are not used in the data capture and retention. Forensic measures will be determined on a case by case basis.

Contingency Planning, Business Continuity and Disaster Recovery are governed by a different set of policies. An event may initially be declared an ‘Information Security Incident’ and subsequently declared to be a ‘Disaster’. In this case, the activities described below will be included in the Disaster Recovery process.

2. Information Security Incidents

An Information Security Incident is generally defined as any known or highly suspected circumstance that affect the confidentiality, integrity or availability of sensitive information managed or belonging to FundApps.

Examples of an Information Security Incident may include but are not limited to:

• the theft or physical loss of computer equipment known to hold files containing sensitive client or company information

• a server known to hold sensitive data is accessed or otherwise compromised by an unauthorised party

• the FundApps network is subjected to a Distributed Denial of Service (DDoS) attack

• a firewall is accessed by an unauthorised entity

• a network outage is attributed to the activities of an unauthorised entity

2.1 Categories

For the purposes of this protocol, incidents are categorised as “Unauthorised Access” or “Unauthorised Acquisition” and can be recognised by associated characteristics.

Unauthorised Access

The unauthorised access to or disclosure of FundApps or client information through network and/or computing related infrastructure, or misuse of such infrastructure, to include access to related components (e.g., network, server, workstation, router, firewall, system, application, data, etc.). Characteristics of security incidents where unauthorised access might have occurred may include but are not limited to:

• Evidence (e‐mail, system log) of disclosure of sensitive data

• Anomalous traffic to or from the suspected target

• Unexpected changes in resource usage

• Increased response time

• System slowdown or failure

• Changes in default or user‐defined settings

• Unexplained or unexpected use of system resources

• Unusual activities appearing in system or audit logs

• Changes to or appearance of new system files

• New folders, files, programs or executables

• User lock out

• Appliance or equipment failure

• Unexpected enabling or activation of services or ports

• Protective mechanisms disabled (firewall, anti‐virus)

Unauthorised Acquisition

The unauthorised physical access to, disclosure or acquisition of assets containing or providing access to FundApps or client information (e.g., removable drives or media, hardcopy, file or document storage, server hardware, etc.)/ Characteristics of security incidents where unauthorised acquisition might have occurred may include but are not limited to:

• Theft of computer equipment where sensitive data is stored

• Loss of storage media (removable drive, flash drive, etc)

• Illegal entry (burglary)

• Suspicious or foreign hardware is connected to the network

• Normally secured storage areas found unsecured

• Broken or non‐functioning locking mechanisms

• Presence of unauthorised personnel in secured areas

• Disabled security cameras or devices

2.2 Criticality

Incidents assigned a criticality rating according to the actual and potential impact on the business of FundApps.

2.3 Roles and Responsibilities

Key roles and responsibilities of those who form part of the Incident Response Team (IRT) have been defined below:

3. Key components of our Critical Incident Response Protocol

The Critical Incident Response Protocol consists of these key components

• Detection

• Activation of team

• Containment

• Notification of non-IRT team members

• Assessment

• Notification of external parties

• Corrective Measures

• Washup & lessons learned

• Closure

3.1 Detection

Timely detection of incidents is critical to containment and minimizing its impact on our business and clients. Please see our IT security policy and specific controls regarding how we detect security incidents.

3.2 Activation of Team

All suspected security incidents are reported to the Incident Response Team Lead, mobilization will be immediate and based on initial orientation and observation. Notification of the rest of the team should occur via direct communication - that is any form of communication where you get a response from the other party (ie voicemail or email are not considered direct notification). Team members should rely on usual company communication channels to ensure they have up to date information.

3.3 Containment

The IRT will determine and cause to be executed the appropriate activities and processes required to quickly contain and minimise the immediate impact on FundApps and our clients.

Containment activities are designed with the primary objectives of:

• Counteract the immediate threat

• Prevent propagation or expansion of the incident

• Minimise actual and potential damage

• Restrict knowledge of the incident to authorised personnel

• Preserve information relevant to the incident

Containment Activities - Unauthorised Access

Activities that may be required to contain the threat presented to systems where unauthorised access may have occurred:

• A1. Disconnect the system or appliance from the network or access to other systems.

• A2. Isolate the affected IP address from the network.

• A3. Power off the appliance(s) if unable to otherwise isolate.

• A4. Disable the affected application(s).

• A5. Discontinue or disable remote access.

• A6. Stop services or close ports that are contributing to the incident.

• A7. Remove drives or media known or suspected to be compromised.

• A8. Where possible, capture and preserve system, appliance and application logs, network flows, drives and removable media for review.

• A9. Notify IRT of status and any action taken.

Containment Activities - Unauthorised Acquisition

Activities that may be required to contain the threat presented to assets where unauthorised acquisition may have occurred:

• B1. Identify missing or compromised assets.

• B2. Gather, remove, recover and secure sensitive materials to prevent further loss or access.

• B3. Power down, recycle or remove equipment known to be compromised.

• B4. Where possible, secure the premises for possible analysis by local management and law enforcement.

• B5. Gather and secure any evidence of illegal entry for review by local management and law enforcement.

• B6. Where possible, record the identities of all parties who were possible witnesses to events.

• B7. Preserve camera logs and sign‐in logs for review by local management and law enforcement.

• B8. Notify IRT of the disposition of assets and any action taken.

3.4 Notification of non-IRT members

Designated persons will take action to notify the appropriate internal parties as necessary. All internal & external communication must be approved by the IRT Lead

3.5 Assessment

The IRT will determine the category and severity of the Incident and undertake discussions and activities to determine the next best course of action best, i.e., decide if protocol execution is required. Once the IRT is assembled, the Assessment Checklist is executed and reviewed to ensure all pertinent facts are established. All discussions, decisions and activities are to be documented.

Assessment should consist of the following at a minimum:

Incident data

• The current date and time and a brief description of the Incident

• Who discovered the incident, and how?

Types of information

• What is the nature of the data?

• Was the data held by FundApps or a third party?

• How was the information held? Was the data encrypted or otherwise obfuscated?

Risk

• Can we reasonably determine the risk or exposure?

• To what degree are we certain that the data has or has not been released?

• Can we identify and do we have contact with the party that received the data or caused the compromise? Describe what is known.

• Identify the impacted clients, if possible.

• What is the risk or exposure to FundApps?

• What is the risk or exposure to the client?

Next Steps

• Do we have enough information to establish the category and severity of the Incident?

• If additional data collection data is required, assign responsibility to an IRT member for the collection

• Is there any deadline or reporting requirement (self‐imposed or regulatory) we need to address?

• What communications need to be established? Provide details

• Are there any immediate issues that have not been addressed? Describe

• Recap all work and responsibility assignment

• When do we meet again to follow up? Provide details

• Is this incident going to have legal impacts, requiring forensic evidence to be gathered? If so, refer to the section Gathering Forensic Evidence.

3.7 Gathering Forensic Evidence

The following rules should be enforced when interacting with potential evidence:

• Save the original materials: You should always work on copies of the digital evidence as opposed to the original. This ensures that you are able to compare your work products to the original that you preserved unmodified.

• Take photos of physical evidence: Photos of physical (electronic) evidence establish the chain of custody and make it more authentic.

• Take screenshots of digital evidence content: In cases where the evidence is intangible, taking screenshots is an effective way of establishing the chain of custody.

• Document the date, time, and any other information of receipt. Recording the timestamps of whoever has had the evidence allows investigators to build a reliable timeline of where the evidence was prior to being obtained. In the event that there is a hole in the timeline, further investigation may be necessary.

• Provide third-party company with a bit-for-bit clone of digital evidence. This ensures that they have a complete duplicate of the digital evidence in question.

• Perform a hash test analysis to further authenticate the working clone.

3.6 Notification of external parties

Designated persons will take action to notify the appropriate internal and external parties, as necessary. Communications may include meetings, video conferencing, teleconferencing, e‐mail, telephone/messaging, voice recordings or other means as deemed appropriate. All external communication must be approved by the IRT Lead. FundApps will endeavour to notify clients of any potential incidents impacting the confidentiality, integrity or availability of the client's data, stored in the FundApps platform, no later than 48 hours after having first detected an anomaly.

• Clients - IRT Lead or CEO will establish communication with Clients, as appropriate for the circumstance

• Other affected parties - IRT Lead or CEO will establish communication with other affected parties (such as hosting providers) as appropriate for the circumstance

• Law enforcement - IRT Lead will establish if law enforcement is required and take appropriate action

• Government or Regulatory Bodies - IRT Lead will establish if government notification (e.g. Information Commissioner) is required and take appropriate action

• Media interest - The CEO will deal with any communications with the Media.

3.7 Corrective Measures

The IRT will determine and cause to be executed the appropriate activities and processes required to quickly restore circumstances to a normal (secure) state.

Corrective measures are designed with the primary objectives of:

• Secure the processing environment

• Restore the processing environment to its normal state

Corrective Measures - Unauthorised Access

Activities that may be required to return conditions from unauthorised access to a normal and secure processing state.

• A1. Change passwords on all local user and administrator accounts or otherwise disable the accounts as appropriate.

• A2. Change passwords for all administrator accounts where the account uses the same password across multiple appliances or systems (servers, firewalls, routers).

• A3. Re-image systems to a secure state.

• A4. Restore systems with data known to be of high integrity.

• A5. Apply OS and application patches and updates.

• A6. Modify access control lists as deemed appropriate.

• A7. Implement IP filtering as deemed appropriate.

• A8. Modify/implement firewall rule sets as deemed appropriate.

• A9. Ensure the anti‐virus is enabled and current.

• A10. Make all personnel “security aware”.

• A11. Monitor/scan systems to ensure problems have been resolved.

• A12. Notify IRT of status and any action taken.

Corrective Measures - Unauthorised Acquisition

Activities that may be required to return conditions from an unauthorised acquisition to a normal and secure processing state.

• B1. Retrieve or restore assets where possible.

• B2. Store all sensitive materials in a secure manner (e.g., lockable cabinets or storage areas/containers).

• B3. Install/replace locks and issue keys only to authorised personnel.

• B4. Restore security devices and/or apparatus to working condition.

• B5. Remove and retain unauthorised equipment from the network/area.

• B6. Implement physical security devices and improvements (e.g., equipment cables, alarms) as deemed appropriate.

• B7. Make all personnel “security aware”.

• B8. Notify IRT of status and any action taken.

3.8 Washup and lessons learned

After the incident has been dealt with, a subsequent washup session will be run in order to identify if any further lessons can be learnt or actions taken aside from the immediate corrective measures.

3.9 Closure

The IRT will stay actively engaged throughout the life cycle of the Information Security Incident to assess the progress/status of all containment and corrective measures and determine at what point the incident can be considered resolved.

Recommendations for improving processes, policies, procedures, etc., will exist beyond the activities required for incident resolution and should not delay closing the Information Security Incident.

Objective

This policy aims to define how FundApps retains data throughout its systems.

Scope

The policy applies to all data processed or stored by FundApps.

Policy

Personal Data Retention

Client Data

FundApps retains the following sets of data within its production platform during the lifetime of the contract with its clients:

• Data uploaded to the platform;

• Application audit trail (i.e. actions performed by users in application).

Upon contract termination FundApps will securely delete all client data from its infrastructure within 20 working days, insofar as technically feasible. A copy of this data can be provided to the client prior to deletion based on contractual agreements.

Technical Data

FundApps stores technical logs and events related to its production infrastructure within a centralised log management platform. Data is retained for at least one year.

FundApps data

All other data which do not fall in the previous categories is retained by FundApps within its systems for the length of time deemed adequate by FundApps to provide its service efficiently.

Objective

The purpose of this policy is to define the way in which FundApps addresses information security in project management.

Scope

Policy

Information Security must be addressed for all FundApps projects in scope of this policy.

FundApps projects must include information security requirements.

An information security risk assessment must be conducted at an early stage of the project to identify necessary controls.

Information security must be applied to all the phases of the applied project methodology.

Roles and responsibilities

The product manager is responsible for ensuring the project complies with this policy. The Head of Information Security is responsible for ensuring this policy is aligned with FundApps' business objectives.

Objective

The purpose of this policy is to define the way in which FundApps manages cryptographic controls to protect the confidentiality, authenticity and/or the integrity of information.

Scope

The policy applies to all FundApps Information Systems.

Policy

FundApps will implement cryptographic controls to protect information as defined in the Data Classification and Protection Standard.

Information which requires encryption

The following tables summarises when cryptography must be used:

Encryption of data in transit

Encryption of data at rest

All client data is encrypted at rest. FundApps employs a key management system which allows us to rotate the keys used for the encryption of these volumes on a regular basis. Backups are also stored encrypted at rest, meaning your data is never available in cleartext. Data is encrypted using AES-256-GCM, a symmetric algorithm based on Advanced Encryption Standard (AES) in Galois Counter Mode (GCM) with 256-bit keys.

Encryption ciphers and key lengths

The minimum length of a symmetric key to encrypt restricted client data at rest is 256 bits.

Cryptographic Key Management

Cryptographic keys must be generated, transmitted, stored and managed in a secure manner that prevents loss, unauthorised access, or compromise.

Access: Access to cryptographic keys must be restricted to authorised staff only.

Distribution: Private and symmetric keys must be distributed securely such as through the use secure email or out of band techniques like phone conversations with known individuals. Physical transportation of private and symmetric keys will require that they will be encrypted

Physical security: Equipment used to generate, store and archive keys must be physically protected using appropriate, secure access controls.

Key rotation: Cryptographic keys must be rotated at a minimum every 3 years.

Compromised keys: In the event of a cryptographic key being compromised, a new key (or key pair) must be generated and the existing key must be revoked.

Backup: Backup of cryptographic keys must be maintained to recover them should they be lost.

Logging and auditing: All accesses to cryptographic keys as well as modifications to these keys must be logged. Logs must be audited for anomalous activity.

Roles and responsibilities

The Head of Information Security is responsible for ensuring the policy is aligned to FundApps' business objectives.

Objective

The purpose of this policy is to define the way in which FundApps manages patching of its Information System.

Scope

The policy applies to all FundApps managed Information Systems.

Policy

End user computers

End user computers must receive system patches automatically. Users must not be able to defer patching for more than 30 days.

Servers

Proxy servers

Proxy servers must be cycled at least on a monthly basis, and must be built using an image including the latest system patches.

Web servers

Web servers must receive system patches automatically every month.

Other servers