1 of 57

v2021-07

Welcome

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 it's nature a "living" document - which will evolve as we continually evaluate how we can deliver a best of breed platform to the industry.

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

FundApps Policies

Technical & Platform Overview

This document provides an introduction to FundApps' shareholding disclosure service and its platform. FundApps provide shareholding disclosure monitoring services via a hosted web application 'Rapptr'. Rapptr 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 correct calculation of disclosure requirements.

Software

Rapptr 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 of the Rapptr software is a fully automated and hands-off process.

Platform

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

Rapptr enforces several layers of access control.

Authentication: Rapptr allows clients to either use the Rapptr native 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 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

Software Development

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.

Supporting Information

Roadmaps and ideas for new development are captured as ‘living documents’, describing areas of functionality of our product, and possible new features - both internal ideas and suggestions from clients.

All artifacts are deployed from a centralized system that retains all deployed versions of artifacts and records of the versions, times and where applicable, manual intervention to trigger a deployment. This information is made available throughout the company via internal communications and stored for audit purposes.

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

Work item specified Work items are scoped and defined as development tasks in ClubHouse. Potential security issues flagged and discussed at this stage. Items prioritised and tackled by the team (Figure 2)
Development work Development or configuration work is performed as scoped and defined in the work item.
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.
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.
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 master branch (Figure 3 & 4).
Change merged to master 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 master and becomes a potential release of the system.
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.
Deploy to master testing environment The proposed release is deployed to a master testing environment, to validate that the release can be successfully deployed and that the resulting instance reports a healthy status.
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.
Deploy to master 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
Smoke Test A smoke test is performed by checking the health of the master staging environment and uploading a position file. This ensures that in the production environment, the system is able to accept uploads and process data.
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.
Deploy to client staging environment (automated) Given successful completion of all previous steps and check, a release is promoted to all client staging environments.
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.

Risk Management

Risk Management Framework

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 it's ability to provide it's service to it's client.

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:

Monthly security review meetings
Incident response and reviews
As part of the Software Development Lifecycle
As part of the continuous release management
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

Information Asset Register

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.

Information Systems Register

Rapptr (client instances)
Amazon AWS (production data)
Google Mail (our own internal communications)

Identification

Information systems are identified as part of:

Monthly company-wide security awareness sessions
Monthly security review meetings
Our software development lifecycle
Everyday working practice

Third party vendors

Information systems that FundApps depend on that are managed by third party vendors are included in this register. 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 for the system
Identify information security controls based on the data classification
Identify business continuity controls based on the data classification

Review

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

Data Classification and Protection Standard

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 who is 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 Information Security Lead.

Management team

Responsible for the 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.

(*) RTO means Recovery Time Objective.

Reporting Violations

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

Information Security Management System

Information Security Management Policy

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

Products needs to align with evolving regulations,
FundApps services’ competitive advantage relies partly on its intellectual property.

Systems and Processes

Staff work from home,
Lack of process documentation.

External Issues

Political Factors

Divergence of regulations between UK and EU following Brexit,
Frequent changes made to regulations.

Economic Factors

Market conditions affect our clients’ ability to subscribe to FundApps’ services,
Higher staff costs due to an 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.

Technological Factors

Fast evolving threat landscape (e.g. ransomware campaigns),
Increased expectation from clients to manage their own security (e.g. Bring Your Own Key, feed export logs to client SIEM).

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:

Objective

Measurement

1) Ensure the protection of sensitive data managed by FundApps' Information Systems.

Zero data breaches.

2) Ensure the protection of all FundApps Information Systems against the risks of unauthorised access, misuse, damage and abuse.

Zero FundApps Information Systems compromised, misused, damaged or abused.

3) Demonstrate a high level of competence and expertise in Information Security

Obtain an ISO 27001 certification.

Zero clients lost due to Information Security issues.

4) Maintain compliance with security standards.

Maintain ISO 27001 certification and SOC 2 Type II Reports.

5) Foster a culture of security awareness within FundApps.

Zero security incident resulting from lack of security awareness (e.g. phishing).

6) Protect FundApps from liability or damage due to an Information Security Incident.

Zero law suits, fines or losses due to a security incident.

7) Maintain a cycle of continuous improvement.

All non-conformities with ISO 27001 standard are prioritised for remediation.

Scope

Information security principles

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

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.
All users covered by the scope of this policy must handle information appropriately and in accordance with its classification level.
As far as is reasonably possible, endeavours must be made to ensure data is complete, relevant, accurate, timely and consistent.
Information should be both secure and available to those with a legitimate need for access in accordance with its classification level.
Information will be protected against unauthorized access and processing in accordance with its classification level.
Information will be protected against loss or corruption.
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 • 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.

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:

Lawfulness, fairness and transparency
Purpose limitation
Data minimisation
Accuracy
Storage limitation
Integrity and confidentiality (security)
Accountability

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.

Interested Parties

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

Interested Party

Requirements on the ISMS

Clients

Provide service in line with contractual Service Level Agreements.

Protect client data from unauthorised access.

Staff and contractors

Provide a secure Information System to allow them to perform their jobs.

Owners and Investors

Provide a cost-effective, safe and secure Information System which allows to FundApps to be profitable, attract new clients and develop new services.

Suppliers

Operate a secure Information System which prevents security incidents from impacting the supplier's Information System (e.g. malware propagation).

Regulators

Operate a secure Information System which complies with applicable laws and regulations.

Scope

The ISMS applies to the shareholding disclosure, position limits and sensitive industries 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’ three main services provided are:

Shareholding Disclosure

FundApps’ Shareholding Disclosure service helps compliance professionals with shareholding disclosure requirements, prove adherence to regulation and mitigate reputational risk to avoid fines.

FundApps’ outsourced, managed service combines FundApps’ proprietary rules engine with a team of compliance professionals and legal information from aosphere (an affiliate of Allen & Overy) and other regulatory data sources.

FundApps automates disclosure requirements such as major shareholding, 13F reporting, short selling (including EU Short Selling Rules, takeover panels, issuer limits, and issuer requests (such as Section 793).

Position Limits

FundApps' Position Limits is a managed service for financial institutions, who trade derivative contracts on multiple exchanges. It combines FundApps’ proprietary rules engine with a dedicated team of compliance professionals and up-to-date contract limits and exchange data. It helps compliance managers monitor holdings against position limits for exchange-traded contracts resulting from MiFID II regulation, as well as limits imposed by regulatory bodies such as the United States’ Community Futures Trading Commission (CFTC).

Sensitive Industries

FundApps automates the monitoring of regulatory disclosure thresholds in “sensitive industries”, including pre-approval and post notification, hard-stop and issuer-specific limits. FundApps’ Sensitive Industry rules cover industries in jurisdictions which have different regulations governing ownership.

People

The FundApps departments within the scope of the ISMS are:

Client Services – On-board clients and assist them throughout their experience with Rapptr.
Content – 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.
Head of Client Services – Takes the lead in owning FundApps client portfolio and drive cross-team collaboration to support FundApps’ objectives.
Head of Product – 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.
Head of Sales – Accountable for all sales activities within the region and as the People Leader for the Regional Sales team.
Head of People Operations – Reporting directly to the CEO, the head of People Operations smooths the next phase in growth as FundApps scales.
Information Security Lead – Responsible for managing Information Security, Cyber Security and Business Continuity risks potentially impacting FundApps.

Offices

FundApps operates out of three offices:

114-116 Curtain Road, London EC2A 3AH, United Kingdom
115 Broadway, New York, NY 10006, USA
#02-11, Capitol Piazza, 13 Stamford Road, Singapore 0178905

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 servers;
Web front-end servers, which provide FundApps clients with a web user interface and an application programming interface (API);
Engine servers, which perform apply rule sets analysis of FundApps clients’ financial positions;
Database servers, which store the results of this analysis, as well as objects and events related to client environments;
Network Address Translation Gateways used by the servers to connect to non-FundApps resources; and
Bastion hosts, which FundApps staff use to administrate the infrastructure.

Software

FundApps’ platform consists of system software (operating systems, middleware, and utilities) that supports its applications. FundApps’ stack is made of Windows servers running Internet Information Services (IIS), SQL Server and RabbitMQ.

AWS services such as Elastic Load Balancing, Amazon Route 53, AWS Lambda and Amazon Simple Storage Service are also used to support the service provided. Ingress traffic is filtered by high availability web proxies deployed to Linux servers running Ubuntu operating system.

The software developed by FundApps is mostly written in C# and NodeJS programming languages. This software is accessible to clients through a Web User Interface and an Application Programming Interface (API).

FundApps’ platform is kept up to date with the latest enhancements and fixes. FundApps delivers changes from development and content teams to client production environments. To support this activity FundApps employs test-driven development, pair programming and code review to reduce risk and improve software quality.

Every change to software and rule content is run through a test suite to achieve a minimal amount of reduce risk in this continuous update process. Security considerations are built into the software lifecycle. FundApps identify work items early on that have security implications.

Deployment of changes of the FundApps platform software is a fully automated process

Interfaces and Dependencies

Amazon Web Services

AWS provide hosting services and is used to host the FundApps platform.

Data Centre Physical Security Overview

All data hosted in FundApps’ platform is hosted by AWS within the EU in facilities with physical security controls in place. AWS hold industry standard certifications relating to security and availability, including but not limited to ISO 9001, 27001, as well as SOC I and II attestations. Full details of the certification activities undertaken by FundApps’ hosting partner are available via AWS compliance.

Data Centre Access Control

AWS provides physical data centre access only to approved employees. All employees who need data centre 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 centre the individual needs access, and are time-bound. Requests are reviewed and approved by authorised 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 centre the individual needs access, and are time-bound. These requests are approved by authorised 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 authorised staff.

Alert Logic

Alert Logic provide network-based and host-based Intrusion Prevention Services (IPS), as well as a 24/7 Security Operation Centre (SOC).

Exclusions

There are no exclusions to the ISMS.

Objective Plan

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

Objective

What will be done

Responsible

Resources required

Evaluation

Est. completion date

1) Ensure the protection of non-public data managed by FundApps' Information Systems.

Implement conditional access to allow same controls on BYOD than corporate devices

Information Security Lead

External expertise on conditional access

Conditional Access has been deployed to Okta

End of December 2021

2) Ensure the protection of all FundApps Information Systems against the risks of unauthorised access, misuse, damage and abuse.

Automate security testing for Infrastructure as Code

Information Security Lead

Recurrent budget

Automated security testing for IaC implemented in build pipeline

End of June 2021

3) Demonstrate a high level of competence and expertise in Information Security

Maintain a SOC 2 Type II Report

Information Security Lead

External auditor

SOC 2 Type II Report

End of November 2021

4) Maintain compliance with security standards.

Obtain ISO 27001 certification

Information Security Lead

Internal and External auditors

ISO 27001 certification

End of November 2021

5) Foster a culture of security awareness within FundApps.

Provide security awareness training refresher for all staff

Information Security Lead

None

Security awareness refresher training provided to all staff

End of September 2021

6) Protect FundApps from liability or damage due to an Information Security Incident.

Review compliance with Privacy laws

Legal counsel

Recruit legal counsel

Compliance with privacy laws reviewed

End of December 2021

7) Maintain a cycle of continuous improvement.

Remediate findings identified by ISO 27001 readiness assessment and Internal audit

Information Security Lead

None

All non-conformities have been remediated

End of July 2021

Performance Evaluation

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:

Status of actions from previous management reviews
Relevant changes in external and internal issues
Performance of the ISMS
1. Audit results, non conformities and corrective actions
2. Monitoring and measurement results
3. Information Security Objectives
Feedback from interested parties
Results of risk assessment and status of risk treatment plan
Opportunities for continual improvement

Internal Audit Policy

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.

The annual internal audit must cover a section of the ISMS so that over a period of 3 years, the entirety of the ISMS scope can be audited.

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: 2013 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

Internal Audit Plan 2021

FundApps shall perform it's first ISMS audit in 2021.

This internal audit shall cover the following elements:

Observations from the Readiness Assessment against ISO/IEC 27001:2013 standard;

The audit will be performed before the end of June 2021.

Continual Improvement Process

Objective

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

Scope

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

Policy

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.

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.

Information Security Policies

Client Services Access to Client Environments

At FundApps we are dedicated to providing the highest quality of support 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 hosted in our AWS production environment 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 in order to troubleshoot failed file validations
We may download/export relevant files in order 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 the administrator privileges.

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.

Employee Guide

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 pro-active 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 happening here. Also see "other reading".
If you know or suspect a loss or theft of confidential information has a occurred, or the security or integrity of any system has potentially been compromised - report it immediately to the 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 #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 installed and configured for automatic updates.
Make sure your computer password meets our minimum security requirements. It should be at least 8 characters with at least one upper/lowercase character, a number and symbol.
Set your PC so it will automatically lock after 3 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 information.

Policies

General security

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 8 characters in length, and at least 3 out of 4 of lower case, upper case, digits and symbols).
Never share individual account credentials.
Immediately change compromised credentials and report compromise to the Information Security Lead.

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 to our security checklist (cf. Security Musts) - this includes but is not limited to - hard disk encryption, anti-virus installed, a secure password and 3 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.

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 of email based password re-setting). 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 3 minute screen savers on your computer. (Go to Screen Saver settings, wait 3 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.

If your profile mentions FundApps, be honest about who you are and what you do.
Be aware if your profile mentions FundApps, you may be more of a target for social engineering or phishing attacks
Never share your login details or let others post on your behalf.
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.
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!
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.

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.

Breaches of security

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

Disclosure of confidential information to any unauthorised person.
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.

Security Awareness Program

FundApps management believes that embedding security into the culture of FundApps is critical to the success of our information security program, and as such this is a management priority.

FundApps implements the following practices to achieve this objective:

New joiners go through an Information Security training when they start at FundApps. This training covers what is Information Security, why it’s important to FundApps and what is expected of FundApps staff and contractors;
Security-themed presentations to all of FundApps’ staff;
Technical Security presentations to engineers on most common vulnerabilities;
Channels in company communication tool with security news;
Monthly security review session for key stakeholders where we actively review security access lists, audit logs and risk register;
Culture of continuous improvement across all areas of the business.

Business Continuity

Personnel & Safety

Policy Change Log

July 2021

Incident Response

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 results in an actual or possible unauthorised release of information deemed sensitive by FundApps or subject to regulation or legislation, beyond FundApps sphere of control.

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.

Level

Level Definition

Typical Incident Categories

Incident Response Time

Incident affecting critical systems or information with potential to be revenue or client impacting.

Denial of service Compromised Asset (critical) Internal Hacking (active) External Hacking (active) Virus / Worm (outbreak) Destruction of property (critical)

60 minutes

Incident affecting non‐critical systems or information, not revenue or client impacting. Employee investigations that are time sensitive should typically be classified at this level.

Internal Hacking (not active) External Hacking (not active) Unauthorised access Policy breaches Unlawful activity Compromised information Compromised asset (non‐critical) Destruction of property (non‐critical)

4 hours

Possible incident, non‐critical systems. Incident or employee investigations that are not time sensitive. Long‐term investigations involving extensive research and/or detailed forensic work.

Email Forensics Request Inappropriate use of property. Policy breaches

48 hours

2.3 Roles and Responsibilities

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

Role

Responsibilities

CTO or Information Security Lead

Incident response team lead (IRTL)

CEO

Participates in incident response team, leading external communications.

IT Team / Engineering

Normally form part of the incident response team, subject to CTO approval after initial assessment.

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 it's 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 a 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 to the 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 a 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 identities of all parties who were a possible witness to events.
B7. Preserve camera logs and sign‐in logs for review by local management and law enforcement.
B8. Notify IRT of 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 best determine the next best course of action, 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 IRT member for 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 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 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 - CEO will deal with any communications with 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 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/container).
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 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 improvements to processes, policies, procedures, etc. will exist beyond the activities required for incident resolution and should not delay closing the Information Security Incident.

Code of Conduct

Our Code is how we put the FundApps values into practice. As a business, we set ourselves high standards both in what we aspire to achieve and how we behave. It reminds us of the personal responsibility we all play in ensure FundApps is, and remains an awesome place to work and a trusted partner to our clients and the community.

We don't want to (nor could we) enumerate every thing people should or should not do in Our Code, nor all of the possible scenarios that might arise. Instead, we prefer to assume everyone at FundApps is a responsible, respectful adult, and trust people to understand it, act accordingly and be able to work through differences as they arise.

Please read this document, and follow both in spirit and letter, bearing in mind each of us has a personal responsibility to live by our values in everything we do at FundApps.

We all play a part

Our role

No matter what job we do or where we do it, we are FundApps. We must keep this in mind in every business relationship, transaction and interaction to ensure our actions always reflect our values, Our Code, and the laws and regulations where we operate.

If you see or suspect anything illegal or unethical, it may seem easier to look the other way or let someone else take the lead—but misconduct affects all of us. No concern is too minor to report. Share your concerns promptly and cooperate fully and honestly as we investigate. We expect all FundAppers to know and follow Our Code. Failure to do so can result in disciplinary action, including termination of employment.

If you manage people, you have an even greater responsibility. Lead by example, making sure your team members know this is a resource for them and that there is no difference between what you do and what you expect from others. Create the kind of workplace where employees feel comfortable coming forward with questions and concerns, and support them when they raise issues. Never retaliate against employees for sharing concerns in good faith, and prevent retaliation by others.

Where to go for help

Whilst we hope nothing ever goes wrong, there are a number of things you can do to address problems and situations with your fellow FundAppers or with our People Ops. We know that you'll do your best work if you're happy and comfortable in your surroundings, so we take concerns about this stuff seriously. Depending on your comfort level and the severity of the situation, here are some things you can do to address it:

Address it directly. If you're comfortable bringing up the incident with the person who instigated it, pull them aside to discuss how it affected you. Be sure to approach these conversations in a forgiving spirit: an angry or tense conversation will not do either of you any good. If you're unsure how to go about that, try discussing with your manager or with People Ops first—they might have some advice about how to make this conversation happen. If you're too frustrated to have a direct conversation, there are a number of alternate routes you can take.
Talk to a peer or mentor. Your colleagues are likely to have personal and professional experience on which to draw that could be of use to you. If you have someone you're comfortable approaching, reach out and discuss the situation with them. They may be able to advise on how they would handle it, or direct you to someone who can. The flip side of this, of course, is that you should also be available when your colleagues reach out to you.
Talk to your manager. Your manager probably knows quite a lot about the dynamics of your team, which makes them a good person to look to for advice. They may also be able to talk directly to the colleague in question if you feel uncomfortable or unsafe doing so yourself. Finally, your manager will be able to help you figure out how to ensure that any conflict with a colleague doesn't interfere with your work.
Talk to People Ops. People Ops are happy to talk to you in person or remotely about the problem and help figure out what steps to take, from small challenges through to situations where more significant action needs to be taken. People Ops will make every effort to stay in clear communication with anyone who reports a problem, maintain confidentiality whenever possible. There may be instances where People Ops are required to escalate or inform others (e.g. CEO, legal advisors etc) about matters.

A safe space to speak up

We don't tolerate retaliation. We know it takes courage to come forward and share concerns. We won't retaliate or permit retaliation against anyone who raises questions or concerns relating to Our Code. Regardless of who you contact, you can be confident that you're doing the right thing and that your concern will be handled promptly and appropriately. We investigate reports of misconduct thoroughly, and will only disclose information to those who need it.

We create our workplace

We're one team, but we represent many ideas, experiences and backgrounds. Essential to our ability to advance our objectives and growth plans is for all FundAppers to have an equal chance to succeed. It is through the diversity and talents of our people that we are successful, so keeping our positive and inclusive work environment

Equal Opportunity

Employment at FundApps is based solely upon individual merit and qualifications directly related to professional competence. We strictly prohibit unlawful discrimination or harassment on the basis of race, color, religion, veteran status, national origin, ancestry, pregnancy status, sex, gender identity or expression, age, marital status, mental or physical disability, medical condition, sexual orientation, or any other characteristics protected by law. We also make all reasonable accommodations to meet our obligations under laws protecting the rights of people with a disability.

Harassment & Bullying

FundApps prohibits harassment and bullying in any form. Harassment is an action, conduct or behaviour that is viewed as unwelcome, humiliating, intimidating or offensive by the recipient. Bullying is repeated verbal, physical, social or psychological abuse by a person or group of people at work.

The test for what is considered unwelcome, humiliating, intimidating or offensive is what a reasonable person in society (ie. If you told a complete stranger about the situation, what would they think?).

Workplace harassment and bullying should not be confused with constructive feedback or coaching on work performance or work-related behaviour of an individual or group for development purposes.

Microaggressions

Much exclusionary behavior takes the form of subtle-isms, or microaggressions – small things that make others feel unwelcome. For example, saying "It's so easy my grandmother could do it" is a subtle-ism with tones of both sexism and ageism. Regardless of intent, these comments can have a significant demeaning impact on teammates.

If you see a microaggression, you can point it out to the relevant person, either publicly or privately, or you can ask your Manager or People Ops to say something.

Standing up for inclusion

If a situation occurs where you believe you have been present for a behaviour or microaggression that doesn't align with Our Code, FundAppers are encouraged to speak up within the moment in order to let that person know that what has happened is not inclusive behaviour. This makes for a situation from which all parties can learn, and is one which promotes understanding. Additionally it makes it possible for that someone to de-escalate the situation by correcting themselves and apologising. This does not ensure, there will be no consequences, it however will greatly reduce the chance of escalation and has the potential to return a situation to once again become comfortable and inclusive.

We do the right thing

Anti-bribery & corruption

Like most global businesses, we are subject to laws that prohibit bribery in basically every kind of commercial setting. The rule for FundApps is simple - don't bribe anybody, anytime, for any reason. This includes pure bribes, kickbacks, illegal payments and any other offer of items of value that may influence behaviour directly or through a third party.

Whistleblowing

Whistleblowing is generally defined as the reporting of certain types of wrongdoing that are in the public interest (ie it must affect others such as the general public). We encourage all of our employees and others who have serious concerns about any aspect of FundApps work to come forward and voice those concerns. The types of whistleblowing covered under legislation include:

a criminal offence, eg fraud
someone's health and safety is in danger
risk or actual damage to the environment
a miscarriage of justice
the company is breaking the law, eg doesn't have the right insurance
you believe someone is covering up wrongdoing

In the first instance, concerns can be raised in writing with the People Ops Manager or CEO. Concerns can also be raised to relevant prescribed bodies under national whistleblowing legislation.

Child Labour & Modern Slavery

We have zero tolerance for suppliers of goods and services, including in relation to child labour, inhumane treatment of employees and forced or compulsory labour.

We protect FundApps

Gifts

It is the nature of global business that we may give or receive gifts as part of maintaining relationships with our clients, suppliers and partners. Employees are to:

Use sound judgment and comply with the law, regarding gifts and other benefits
Never allow gifts, entertainment or other personal benefits to influence decisions or undermine the integrity of business relationships
Never accept gifts or entertainment that are illegal, immoral or would reflect negatively on the company
Never accept cash, cash equivalents, stocks or other securities

Employees may accept occasional unsolicited personal gifts of nominal value such as promotional items and may provide the same to clients and business partners.

Conflict of Interest

When you are in a situation in which competing loyalties could cause you to pursue a personal benefit for you, your friends, or your family at the expense of FundApps or our clients, you may be faced with a conflict of interest. All of us should avoid conflicts of interest and circumstances that reasonably present the appearance of a conflict.

When considering a course of action, ask yourself whether the action you're considering could create an incentive for you, or appear to others to create an incentive for you, to benefit yourself, your friends or family, or an associated business at the expense of FundApps. If the answer is "yes," the action you're considering is likely to create a conflict of interest situation, and you should avoid it.

There are seven common areas where conflicts of interest can arise:

Personal investments
Outside employment, advisory roles, board seats, and starting your own business
Business opportunities found through work
Inventions
Friends and relatives; co-worker relationships
Accepting gifts, entertainment, and other business courtesies
Use of Google products and services

In each of these situations, the rule is the same – if you are considering entering into a business situation that creates a conflict of interest, don't. If you are in a business situation that may create a conflict of interest, or the appearance of a conflict of interest, review the situation with your manager and People Ops. In most cases, a plan can be put in place to mitigate any actual or perceived conflict of interest. Finally, it's important to understand that as circumstances change, a situation that previously didn't present a conflict of interest may present one.

Confidentiality & Privacy

We respect the privacy of our clients, employees and others with whom we conduct business, and we handle their personal information with care. "Personal information" is any information that could be used to identify someone, either directly or indirectly, such as a name, email address or phone number. There are data privacy laws that prescribe how to responsibly collect, store, use, share, transfer and dispose of personal information, and we strive to comply with those laws everywhere we operate.

We do good

Environment

Goodness matters! In everything we do, we strive to do it in an environmentally responsible manner and hold ourselves accountable for compliance with all applicable environmental laws and regulations. Whilst our environmental footprint is not big, we all have a role to play and we are committed to actions that minimise our environmental footprint by reducing energy use in our offices, decreasing waste, only using water when we absolutely have to, and avoiding one-time plastic usage and printing like the plague!

Consider this commitment in everything you do, from how you dispose of waste, to purchasing environmentally friendly products in our physical and home offices. Where there is an opportunity to minimise our footprint as a company, or your own as an employee of FundApps, please take it.

Purchasing

Whilst we may be a small company, FundApps believes in purchasing any items it requires for day-to-day operations of our business from local suppliers or suppliers owned by people from minority backgrounds. This forms part of our commitment to our local communities and doing good as a company beyond the profits we make.

It's what we stand for

FundApps is committed to being a company that does good by our people, our clients and our community. We rely on one another's good judgment to uphold a high standard of integrity for ourselves in everything we do, and we expect all FundAppers to be guided by both the letter and the spirit of Our Code. Sometimes, identifying the right thing to do isn't an easy call. If you aren't sure, don't be afraid to ask questions of your manager or People Ops.

And remember… if you see something that you think isn't right – speak up!