• Rapptr (customer 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 assessement 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.

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

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 customer 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. A number of our customers have penetration tested the application and do so on a recurring basis.

Deployment of changes of the Rapptr software is a fully automated and hands-off process.

Platform

As we have control over both software and infrastructure we are 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 the clear to be read by third parties.

Access Security

Access to Rapptr is via HTTPS; either for user interactions to the Web UI or for automated interactions with the API endpoints. We are able to provide further access security by applying IP restrictions to customer environments, preventing access from networks other than those of the customer site. These restrictions operate at a high level, before any authentication to the system and prevent any requests being made to the application at all.

Individual customer datasets are isolated at infrastructure level using separate databases. 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.

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.

Amazon Web Services

Our AWS stack is designed with two primary failure modes: Failover and Disaster Recovery. Failover is catered for entirely within a single geographic region using a highly available primary environment. In this primary environment data is replicated synchronously between two database servers and redundant systems are used to ensure the maximum possible continuity of service.

These redundant systems are distributed between two AWS Availability Zones (AZs) in a single geographic region (Dublin, Ireland). AWS have multiple AZs per geographic region, but each AZ has discrete power and internet connectivity. We use two availability zones simultaneously for web traffic, reducing the effect of any failure on the availability of the service.

Disaster Recovery functionality is provided from a secondary geographic region (Frankfurt, Germany) and this mode is intended to meet a 4 hour RTO in case of total loss/failure of the primary environment. This is facilitated by shipping backups on a regular basis to encrypted storage in the region.

Configuration management and automation allows spin up of the other platform components in this region to support a deployment of the system in the absence of our primary geographic location.

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 customers and prospective customers 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.

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 Tolerance

Risk Management Process

Identify

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

1. Monthly company-wide security awareness sessions

2. Monthly security review meetings

3. Incident response and reviews

4. As part of the Software Development Lifecycle

5. As part of the continuous release management

6. As part of everyday working practice

Assess

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:

Residual risk

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

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.

Closing a risk

Risks remain open until we have:

• implemented any new controls identified to reduce the likelihood or impact of the risk, and therefore reduce the residual risk

• re-assessed the risk and ensured it is below High

• decided to accept the residual risk level

Review

Once closed, risks are re-assessed on a timeframe defined in in the risk levels.

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

Each month we have a 30 minute company-wide session to discuss security issues, address any new concerns or risks people can raise, and check in with any security incidents that have been in the press.

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.

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

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

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 - this includes but is not limited to - hard disk encryption, anti-virus installed, a secure password and 3 minute lock timeout.

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 ZIP 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 customer emails you sensitive portfolio data, please advise them that they should not be doing this.

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

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

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

Social media

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

Further reading

For general awareness, we recommend the following sites.

For more technical information, check out

FundApps management believe 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.

We have the following in place to achieve this:

• New starter survey to set the tone for those who join our organization, followed up by IT security survey a month later to raise awareness of our approach including staff security policies, data classification and our BYOD policies

• 6 monthly IT security survey for existing staff to assess awareness and identify improvements

• Monthly company-wide security session, to discuss any issues that may have arisen, clarify policies (such as data classification), identify improvements and new risks

• Channels in company communication tool with security news

• Our secure software development lifecycle and specifically the scoping and review process

• 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

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

Purpose

The primary purposes of this policy are to:

1. Ensure the protection of all FundApps information systems (including but not limited to all computers, mobile devices, networking equipment, software and data) and to mitigate the risks associated with the theft, loss, misuse, damage or abuse of these systems.

2. Make certain that users are aware of and comply with all current and relevant UK and EU legislation.

3. Provide a safe and secure information systems working environment for staff and any other authorised users.

4. Make certain that all FundApps’s authorised users understand and comply with this policy and any other associated policies, and also adhere to and work within the relevant codes of practice.

5. Ensure that all users understand their own responsibilities for protecting the confidentiality and integrity of the data that they handle.

6. Protect FundApps from liability or damage through the misuse of its IT facilities.

7. Respond to feedback and update as appropriate, initiating a cycle of continuous improvement.

Scope

This policy is applicable to, and will be communicated to, all staff and third parties who interact with information held by the FundApps and the information systems used to store and process it. This includes, but is not limited to, any systems or data attached to the FundApps data or telephone networks, systems managed by FundApps, mobile devices used to connect to FundApps networks or hold FundApps data, data over which FundApps holds the intellectual property rights, data over which FundApps is the data owner or data custodian, communications sent to or from the FundApps.

Definitions

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

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

1. Lawfulness, fairness and transparency

2. Purpose limitation

3. Data minimisation

4. Accuracy

5. Storage limitation

6. Integrity and confidentiality (security)

7. 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 the FundApps board and updated regularly to ensure that they remain appropriate in the light of any relevant changes to the law, organisational policies or contractual obligations.

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 not just critical for assets covered by the Data Protection Act but for all customer information 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.

Information Owners

Each type of information in our asset register has an explicitly designated owner, who is responsible for assessing information and classifying its sensitivity. They should then apply the appropriate controls in conjunction with our technology team to protect that information.

Management team

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

Classification guidance

Reporting Violations

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

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 customers 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 customers. 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 customers 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 customer 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 customer). 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 customers. 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.

Employees

FundApps values each employee, and so has a commitment to protect the personal information which we handle on behalf of the employee. It is our policy that:

• FundApps will collect only that information about employees which is needed and relevant.

• FundApps will strive to make certain that personal information about employees is kept accurate and up-to-date. Please let us know if your circumstances change.

• Information about employees will not be disclosed to any external parties unless appropriate and with your permission

• Employees will be told how they can review information about them, make updates, and report problems.

• FundApps will comply with applicable laws, regulations, and industry standards when protecting employee information. This includes the UK Data Protection Act 1998.

Customers

It is a part of FundApps core values that we will properly value and protect any information entrusted to us about, or on behalf, of our customers. It is our policy that:

• FundApps will collect only that information about customers which is needed and relevant. This includes contact details for vetted business users, including name, email and contact numbers

• FundApps will not disclose information to other parties unless customers have been properly notified of such a disclosure, or instructed by said customer

• It is vitally important to FundApps that information provided by FundApps Customers is always up to date and relevant.

• FundApps will use appropriate technical and procedural controls to ensure that this information is kept secure and accurate, and is only viewed or used by the proper FundApps personnel.

Introduction

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

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.

Process Overview

Figure 1 - A flow chart overview of the FundApps development and deployment process

Development Process

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

   Figure 2 - Work items, tracked across stages.

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.

Figure 3 - A “Pull Request” containing a proposed change to the system

1. 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).

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

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

   Figure 4 - The release process as seen in our CI software, TeamCity

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

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

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

Figure 5 - A completed deployment to the master staging environment in our deployment tool.

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

2. Deploy to customer 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 customers.

3. Deploy to customer staging environment (manually invoked) Given successful completion of all previous steps and check, a team member can manually trigger a promotion of a release from the master staging environment to either one or all customer staging environments.

4. Deploy to customer production environment (manually invoked) Given that a release has been successfully deployed to a customer’s staging environment, a team member is able to promote that release to a customer’s production environment. This process may be conducted for all customers sequentially.

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 UK Legislation, our own stated policies, and the potential of of breaching the trust of our customers 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 customer 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 customer 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 customer 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 are critical to containment and minimizing it's impact on our business and customers. 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 customers.

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 Assessement

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 customers, if possible.

• What is the risk or exposure to FundApps?

• What is the risk or exposure to the customer?

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

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.

• Customers - IRT Lead or CEO will establish communication with Customers, 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.

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 kinds of data it stores and therefore the data classification and controls required to protect that information.

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

We utilise a centralised identity management platform in order to simplify and automate on-boarding and off-boarding for any information systems that support single-sign on or automated user provisioning. Our staff access database and identity management platform is then used during the off-boarding process to ensure all required privileges are revoked in a timely manner.

Logical access controls for FundApps Platform

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

• Access on a least-privilege and as-needed basis, regularly reviewed

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 to a bastion host using a previously authorised key and verified with a physical MFA token (YubiKey).

• 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 on a least-privilege and as-needed basis and regularly reviewed

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

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 8 characters in length, and at least 3 out of 4 of lower case, upper case, digits and symbols).

• Audit logs must provide 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

Our hosting environments are provided by Amazon Web Services (AWS). AWS data centres are housed in nondescript facilities. Physical access is strictly controlled both at the perimeter and at building ingress points by professional security staff utilising video surveillance, intrusion detection systems, and other electronic means. Authorised staff must pass two-factor authentication a minimum of two times to access data centre floors. All visitors and contractors are required to present identification and are signed in and continually escorted by authorised staff.

AWS keep some details of the physical measures in place at their data centres private; a fuller subset of information is available under mutual NDA with AWS in their SOC 1 and SOC 2 reports.

Our office environment is alarmed and has both a keypad lock and physical key required for opening at start of business. In accordance with our IT policies, all staff equipment is encrypted using BitLocker. See our IT security policies for more information on further controls we have in place.

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

• Applications

  A technical security audit will be conducted annually against FundApps’ application in order to detect vulnerabilities and other security concerns. This assessment will be conducted against an environment identical to the production environment except that it will not contain production or sensitive data. An executive summary of the assessment and it’s finding will be available to clients who request it within 20 working days of the assessment being completed.

• Infrastructure

  An automated scanning of production vulnerabilities will be conducted on a monthly basis.

Vulnerability Severity Ratings

• Applications
• Infrastructure

Vulnerability Acceptance, Mitigation and Correction

• Process

  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.

Onboarding

We follow a task based process in our HR system that ensures correct checks are carried out and crucial training delivered when onboarding new staff.

Background checks

FundApps performs the following checks on our new employees:

• Proof of the person's identity and right to work (e.g. passport)

• Proof of work experience (e.g. résumé/CV and references)

• Proof of academic qualifications (e.g. certificates)

FundApps staff that have infrastructure level access to customer portfolio data have the following additional checks performed by Experian:

• Electronic identity check

• Basic Criminal Record Check

• Adverse financial check

Contractors are subject to reference checks and do not have access to production systems or customer data.

Confidentiality

All FundApps employees have a confidentiality clause in their employment contract, which extends beyond the end of their term of employment. Any breach of the above obligations by the employee is regarded very seriously by FundApps Limited and could result in legal proceedings being taken against the offender.

Training

As part of the on-boarding process, new starters are trained in office and information security. These are then followed up by the ongoing training we do as an organisation.

Ongoing training

We ensure all employees are aware of the importance of maintaining the security of our systems and customer data; use of encryption, transferring sensitive information externally whether via the internet or physical removable media, and general security awareness including virus scanners, phishing scams.

Access control

Offboarding

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 walk outside a grab a random person and tell them 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 customers 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!

AWS has established formal policies and procedures to delineate the minimum standards for logical access to AWS platform and infrastructure hosts. AWS conducts criminal background checks, as permitted by law, as part of preemployment screening practices for employees and commensurate with the employee’s position and level of access. The policies also identify functional responsibilities for the administration of logical access and security.

Overview

Our customers include high profile companies with high availability and service expectations. It is therefore vital that FundApps maintain service and in the event of disruption, are able to effectively manage the incident and communicate with all key interested parties.

Any loss of service from the data centres or our key services will impact the reputation of FundApps, result in loss of revenue through service credits and other compensations, and potentially damage FundApps irreparably in the marketplace.

NOTE: This document describes the management systems framework intended for compliance with ISO 22301. It is designed to provide some documentation that is needed by ISO 22301, with pointers to the other key documents, and is aligned in structure to ISO 22301 for ease of assessing compliance.

Staff welfare

Following a disruptive incident, our highest priority is staff welfare, so they are safe and able to address the other matters arising from the incident.

This includes ensuring safe evacuation from affected premises, safe containment within affected premises, ensuring that staff are paid in a timely manner, and managing all issues arising from disruptive incidents that directly impact on staff.

Technical resilience

Awareness

FundApps’s management team have experience from other organisations that promoted an awareness of the need for business continuity and consequently the resilience of the service has always been a key consideration. This has been re-enforced by some planned activities such as moving office, recent transport strikes and planned maintenance in the data centre requiring a planned failover to the alternate data centre. All such events are recorded within the BCMS.

Needs and expectations of interested parties

FundApps considered all potential interested parties and referred to Figure 2 to ensure comprehensive coverage.

Figure 2: Potential interested parties (from ISO 22313)

FundApps’s key interested parties include:

• FundApps’ shareholders – FundApps is a privately held company and not quoted on the LSE or elsewhere;

• FundApps’ staff;

• FundApps’ customers;

• Financial Services regulators who preside over the activities of FundApps’ customers.

Media handling

Media handling is undertaken directly by the CEO. Further media handling during an incident is undertaken within the Crisis Management process, with specific guidance in the Crisis Management Plan.

Neighbours

Emergency services

Emergency Services will in most circumstances deal with the landlords – i.e. the hosting provider at the data centres and the landlord’s agents at FundApps office. In some circumstances, FundApps may specifically be contacted and one such circumstance was explored during the 2014 Crisis Management exercise which required working with the Ambulance, Police and HPA.

FundApps Staff

FundApps’s staff have expectations that FundApps will continue to employ them and treat them fairly with due care in the event of a disruptive incident.

All staff are required to provide emergency contact details and these are held in our internal portal, providing a means of contacting staff outside of the normal channels and allowing FundApps to provide information to the emergency services should the need arise.

Pressure groups

FundApps have not been specifically targeted by pressure groups but are aware that they and their customers may be targeted due to the general discontent with financial services firms following the financial crisis. This is specifically reviewed as part of the business continuity risk assessment and is under constant review as part of the maintenance and enhancement of the ISMS.

Compliance with relevant laws & regulations

FundApps complies with all applicable UK Laws including Health and Safety at Work Act 1974 and these are detailed in the ISMS maintained for compliance with ISO 27001. FundApps have no specific legal and regulatory obligations to implement business continuity management. This is reviewed annually as part of the overall BCMS review. This review is a simple process:

1. Identify any key changes to legislation that may apply to FundApps;

2. Review new customers or changes to existing customers’ business to determine if there are any legal and regulatory requirements on them that may imply new or changed requirements on FundApps;

3. Any issues that arise are included as non-conformities within the BCMS where they will be assigned ownership and resolved.

FundApps Customers

New customers’ legal and regulatory requirements are always considered during the sales process.

FundApps’ target customers are Financial Services Firms who have advanced business continuity programmes including There is an expectation in customers that FundApps will have business continuity management in place, this forming an implicit or explicit part of the contractual relationship with the customers.

Customers are responsible for the IT DR relating to their services. FundApps offer and will build resilient services with appropriate IT DR. A plan has been lodged with FundApps within its BCMS. FundApps are therefore contractually obligated to enact these when a major incident occurs. Customers therefore have a reasonable expectation that FundApps have the capacity and capability to do this.

Shareholders

FundApps’s shareholders have a reasonable expectation that the company will continue to operate and make returns on capital. Consequently ensuring that unexpected and difficult incidents are managed effectively is an implied requirement on FundApps of their financial backers.

Scope of the BCMS

The BCMS scope includes:

• The following locations:

  • FundApps offices (London, GB; New York, USA; Singapore, Singapore)

  • Amazon data centres in:

    • Dublin

    • Frankfurt

• Included in the scope are all FundApps staff and any key contractors working on behalf of FundApps

All data centre provision and hardware operations are outsourced to Amazon Web Services. FundApps do not have cause to visit these locations. All data centre staff and operations are outside the scope. All of FundApps’ products and services are within scope.

Leadership

Top management commitment

Top management commitment is demonstrated through the policy endorsed by the management team including Andrew White, CEO, Toby O'Rourke, CTO, and the participation of the top management team in the Crisis Management Team and their active involvement in the associated exercising alongside operational teams.

Management commitment

Management commitment is shown by:

• Minuted agreement to develop a BCMS compliant with ISO 22301;

• Policy and objectives endorsed by the CEO;

• Integration of business continuity into the FundApps process model;

• Commissioning of Oprel to provide expertise and resources to develop and establish the BCMS;

• Appointing the CTO to be responsible for to implement business continuity and supporting the CTO to do so (e.g. through the provision of budget);

• Promoting the improvement of the existing business continuity provisions to meet good practice as now recognized in ISO 22301;

• Committing all business areas to supporting business continuity development;

• Participation of management in BIA process and encouraging relevant team members to contribute too;

• Participation of management, deputies and team members in exercising at business unit level.

As part of establishing the BCMS the following has been undertaken:

• Establishing roles, responsibilities and competencies and associated training programme;

• Defining acceptable risk;

• Establishing internal audit procedures and programme;

• Establishing management review processes that monitor the effectiveness of the BCMS;

• Demonstrating continual improvement.

Policy

The Business Continuity Policy is maintained by the CTO and is endorsed by:

• Andrew White, CEO,

• Toby O'Rourke, CTO.

It is an open document and available to all employees through our internal portal, and on request to any interested party.

Roles, responsibilities and authorities

The Business Continuity Management System (BCMS) is the responsibility of the CTO. It is his responsibility to ensure that the BCMS is established, implemented, operated and maintained to meet the needs of FundApps and to comply with ISO 22301. It is his responsibility to ensure that accredited certification is obtained and maintained for the BCMS.

The BCMS defines the incident response structure, and what supporting business continuity plans are required. The BCMS defines the Exercise Programme which is agreed for each coming calendar year and approved by management through the business continuity management forum. Each plan has a designated owner.

Each business continuity plan owner and they are responsible for:

• Defining impacts to their business area that may arise following a disruptive incident

• Identifying risks to their business

• Defining their requirements following any disruptive incident

• Populating a standard FundApps business continuity plan and maintaining this plan

• Reviewing their business continuity plan on a 6 monthly basis and when significant changes occur to ensure details are current

• Undertaking basic exercises as required in the Exercise Programme according to the guidelines provided

• Participating in other exercises as agreed in the annual Exercise Programme

• Notifying the CTO of issues arising from reviews, exercises or any other pertinent matters.

Planning

Risks and opportunities

FundApps currently has three offices in London, New York and Singapore. The team work from home and away from the office on a regular basis and no data is uniquely held in the office or on the laptops with which they access the systems. Consequently there is little direct dependence on the office and the team are able to work away from this location with little difficulty.

Oprel were engaged to provide the necessary expertise in business continuity as it was recognised that FundApps did not have the necessary in-house expertise. FundApps will take on FundApps ongoing support and maintenance of the BCMS FundApps, following hand-over and assessed training if required. In addition, specific training may be undertaken to enable auditing of compliance with ISO 22301.

Business continuity objectives

FundApps’ business continuity objectives are:

• Ensure that FundApps have competent and confident people who can deal with disruptive incidents howsoever caused, in a timely and controlled manner.

• Ensure the safety of staff and other occupants for which they are responsible, within the buildings;

• Minimize disruption to clients and hence protect reputation and standing;

• Enable a return to normal operations in the shortest practical time with the minimum of disruption;

• Establish, implement and maintain a BCMS compliant with ISO22301 demonstrated through accredited certification.

FundApps’ legal obligations are to be found in our information security policy.

Planning implementation

Toby O'Rourke, CTO, is charged with implementing business continuity management to meet the requirements of ISO 22301 in his capacity as CTO, FundApps.

Expertise will be provided by Operational Resilience Ltd, specifically led by Dave Austin, who will lead FundApps through the implementation and check that this is compliant with the needs of ISO 22301.

The work to establish the BCMS began in June 2014 and is anticipated to complete by the end of 2014, with accredited certification to follow depending on the availability of auditors. All areas of the business will need to take part including in the BIA, plan development and exercising. CTO will assist in the facilitation of the risk assessment, in ensuring that the documentation is stored in the FundApps document repository and in FundApps document formats.

The success of the implementation will be judged by the achievement and maintenance of accredited certification.

Awareness

The business continuity policy is published on the FundApps Web site and within the FundApps Intranet and is freely available to all staff. Their attention is drawn to it at induction and on regular occasions at least annually as part of the online tool used by Security and Compliance. The tool allows for the dissemination of key messages, tracks that all staff have undertaken the necessary modules and checks that they have understood the key points. Security and Compliance monitor these results and take action where issues are identified. See also 5.4.

Communication

FundApps communicate to staff:

• At induction

• Regularly in accordance with the Awareness Plan

This communication will ensure that all staff:

• Are aware of FundApps’s ISO 22301 certification and the importance of this in assuring customers, both existing and potential

• Are aware of their role in business continuity and what will be expected of them following a disruptive incident

• Understand their role in maintaining and improving the BCMS.

Staff who hold specific roles receive training and take part in exercising to ensure that they are ready to fulfil those roles. Any enquiries from staff requiring further details are passed to the CTO.

External communication includes existing and prospective customers and suppliers:

• Existing customers will be informed of FundApps’ business continuity arrangements in outline and will receive a copy of the policy on request. A standard Customer Statement originated by the CTO is provided for this purpose.

• Prospective customers will be informed of ISO accreditation as part of assurance to them

• Suppliers are asked to provide information on their business continuity arrangements during the procurement process and this is updated annually.

Customer enquiries are initially deal with by the business teams based on the Customer Statement originated by the CTO. Where additional detail is required, these are referred to the CTO.

In addition, shareholders and customers will be informed of the achievement of ISO 22301 certification.

Any communication with the local community would be by the landlord or the emergency services. Media communications are dealt with by the CEO.

The Environment Agency and the Met Office provide information on flooding and weather, and these have been identified as the only regional or national threat advisory systems. FundApps monitor these when necessary, i.e. when a warning is issued that is pertinent to FundApps. As no direct flood risk has been identified, the focus on the monitoring is on the effect it may have on staff and travel disruptions. This is considered business as usual activity and is incorporated into the incident response when necessary, and is included in the exercising programme too.

FundApps have recognised that communication following a disruptive incident can be challenging and that normal means of communication may not suffice. In order to address this, FundApps have sought to ensure that many communication channels are available including but not limited to:

• Slack which enables rapid communication through a messaging system and details of who is available.

• Mobile phones. Mobile phone numbers are the main point of contact for customers to senior management, for sales and technical staff.

• Email (both personal and FundApps) can be used to communicate to all staff and to customers and suppliers.

• SMS Text messaging to provide short messages.

• Landline numbers where possible for staff.

It is recognised that in extreme circumstances all of these channels can become unavailable. Communication methods are exercised as part of the exercise programme and reviewed following incidents.

All communications processes relating to management of disruptive incidents are documented in the incident response structure and the related plans. In summary:

• Detection:

  • Incidents within the data centres are detected by:

  • FundApps own monitoring detects the external availability of our service, and the internal availability and correct functioning of our internal services. Alerts will be raised through our monitoring software and dealt with through the incident management process.

  • Data centre staff and automated monitoring also notify FundApps of underlying issues with infrastructure via a public status page.

• Incidents at FundApps office are detected by:

  • The landlords’ agents who follow their procedure to notify occupants of the building, specifically via FundApps facilities

  • Directly by FundApps staff who raise this with FundApps facilities or the MMC out of hours.

• Incidents externally are detected by:

  • Media coverage

  • Directly by contact with the Emergency Services.

  • Once notified, the relevant personnel assess whether the incident is managed through normal business as usual procedures or whether further escalation is required. This is based on both experience and knowledge of the individuals and by reference to the impact criteria table in the Crisis Management Plan where necessary.

• The CMT have received training and have responded to several challenging incidents. Post incident reports are available.

• Ongoing exercising is designed to ensure that the CMT are well equipped to deal with incidents of all sorts and this includes relevant deputies. Similarly every business area has undertaken basic training and exercising, has had to respond to real incidents and ongoing exercising is aimed at ensuring that the whole incident response structure operates effectively.

Maintenance of staff contact details

In the event of an incident which requires the full or partial invocation of the Business Continuity Plan, it is vital that the Company is able to contact all of its personnel quickly and efficiently.

In preparation for this, a number of actions take place:

• Employee contact information is stored in the Google Drive which is externally hosted.

• In addition, each employee has contact numbers already stored in their mobile phones.

FundApps Documentation

In order to maintain consistency, legibility and accessibility all BCMS documentation is held as an electronic copy within FundApps’s document management system GitHub.

A summary of the principle documents and its owner can be found in this document. Each document will be approved by the owner prior to issue, as will any subsequent updates. The approval process will typically be conducted via email.

GitHub has built-in version control which allows anyone with sufficient access to view previous versions and therefore facilitates comparison between versions. Unwanted documents are removed from the repository but are retrievable by IT. Documents can only be checked out for update by those with appropriate access. Each document has an assigned Owner and GitHub tracks whether documents have been appropriately approved.

Operation

Operational planning and Control

Known planned changes include the take-on of more staff and the transfer from the existing data centres to a new provider in new locations. The transition and change in the business will require the BIA to be under review throughout this period, and any steps arising to be taken.

Risk and Impact assessment

Please see our (risk management framework)[../risk-management/] for information about how we assess risks, their likelihood impact and our risk appetite.

Business Continuity Strategy

The BC Strategy is detailed in the BC Strategy section of the BIA report in the BCMS.

Establish and implement business continuity procedures

Exercising and testing

An annual programme of exercising is documented and agreed. This is then executed by the CTO and the relevant business areas. Audit processes ensure that business exercises are completed and are effective. Actions arising are captured by the CTO and ownership assigned for execution.

The team undertake regular tests of the IT recovery and these are recorded in Google Drive. Any issues arising are tracked through the raising of tickets as part of business as usual fault resolution.

Performance evaluation

Monitoring, measurement, analysis and evaluation

FundApps will monitor the progress of the BCMS implementation and will measure this by completion, ensuring that all documentation is accessible on Google Drive.

Management Review

The FundApps Business Continuity & Security Management Forum is the forum through which the management review of business continuity is undertaken. This corresponds to the Monitor and Review (Check) stage of the BCMS. The Management Forum reviews the FundApps’s BCMS quarterly to ensure its continuing suitability, adequacy and effectiveness and seek opportunities for improvement where appropriate. The FundApps CTO is responsible for ensuring that these meetings are documented and that records are maintained for inspection.

• Plan owners;

• CTO.

FundApps’s BC Management Forum undertakes a formal review of business continuity through regular meetings. The agenda for these meetings includes, during the course of 12 months:

1. Results of BCMS audits;

2. Reports on BCM arising from internal review, including self-assessment;

3. Reports on key supplier capability, in particular DC PROVIDER;

4. Any relevant feedback from external parties such as customers and regulators;

5. Techniques, products and procedures that could improve FundApps’s BCMS performance and effectiveness;

6. The status of corrective actions previously agreed and authorised;

7. The contents of the risk register and in particular, outstanding unmanaged risks, threats and vulnerabilities not fully addressed and newly identified risks. Particular account will be taken of the National Risk Register;

8. Any changes to FundApps or externally that may impact on the effectiveness and efficiency of the BCMS;

9. Recommendations for improvement;

10. Results from exercises and the status of the exercise programme;

11. Lessons from incidents;

12. Emerging good practice and guidance;

13. Results from the education, training and awareness programme;

14. The FundApps business impact analysis, business requirements and overall arrangements.

The minutes of these meetings document where these items are discussed and the actions arising. These are tracked through a spreadsheet that is discussed as a standing item on the Management Forum’s agenda. The outcomes generally are decisions and actions relating to:

a) vary the scope of the BCMS;

b) improve the effectiveness of the BCMS;

c) modify BCM strategy and procedures, as necessary, to respond to internal and external events that could impact on the BCMS, including changes to:

a. business requirements;

b. resilience requirements;

c. business processes affecting the existing business requirements;

d. statutory, regulatory and contractual requirements; and

e. levels of risk and/or levels of risk acceptance;

f. key suppliers;

d) meet resource needs; and

e) ensure relevant funding and budget requirements are met.

The management review is formally recorded by the minutes of each meeting and determines and authorizes the preventive and corrective actions (see below). The overall process is described by figure 1.

Improvement

Nonconformity and corrective action

When deviations from the policy are identified, these are raised with the CTO and logged on the nonconformities spreadsheet. Ownership is assigned according to appropriate responsible business area and acted upon. The nonconformities are then tracked for completion of appropriate actions to resolve the issues by the Compliance and Security team, and status is reported through the business continuity management forum.

Continual improvement

The overall operation of the BCMS is designed to ensure that FundApps continue to maintain and enhance their business continuity capability and effectiveness over time. The periodic review of policy and objectives, the management review process encompassing audit results, responses to actual incidents, preventive and corrective actions and changes to the FundApps organization and environment ensures that continual improvement is inherent in the operation of the system.

Overview

Risk assessement

Location of critical items

Health and Safety Policy

Andrew White has overall and final responsibility for Health and Safety

Hana Sekerez has day-to-day responsibility for ensuring this policy is practiced