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

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

What we do

• We use secure virtual desktops to access client platforms.

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

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

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

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

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

What we are unable to do

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

• We cannot create or edit any data overrides

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

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

• We cannot action any tasks, including approving any rules

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

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

FundApps implements the following practices to achieve this objective:

• New joiners go through an Information Security training when they start at FundApps. This training covers what is Information Security, why it’s important to FundApps and what is expected of FundApps staff and contractors;

• FundApps staff undergo an annual Information Security Training refresher;

• Security-themed presentations to all of FundApps’ staff;

• Technical Security presentations to engineers on most common vulnerabilities;

• Channels in company communication tool with security news;

• Monthly security review session for key stakeholders where we actively review security access lists, audit logs and risk register;

• Culture of continuous improvement across all areas of the business.

Introduction

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

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

Who’s this policy for?

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

What types of social media does this cover?

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

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

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

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

Be yourself

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

Be respectful

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

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

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

Use common sense

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

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

Be aware

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

Did you know?

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

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

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

Protecting our business

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

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

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

Respect intellectual property laws

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

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

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

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

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

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

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

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

Can I use social media during working hours?

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

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

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

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

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

Is social media monitored?

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

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

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

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

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

FundApps has implemented a tiered network architecture to host its services. This tiered architecture allows the restriction of communications between networks in order to reduce the probability and impact of a security incident.

Operational and security logs are monitored 24/7 by the Security team to detect and respond to security incidents.

Access to the administration of the network is limited to a small number of FundApps staff.

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.

This policy covers all FundApps IT systems and information not classified as 'Public' in our data classification policy.

Each information system is recorded in FundApps' Information Systems Register [Restricted to FundApps staff] which includes:

• An owner responsible for managing user access

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

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

Access to each information system is on a least-privilege and as-needed basis. These are managed by the nominated owner of the system and access to each system is managed through FundApps' Identity and Access Management system [Restricted to FundApps staff]. These are reviewed as part of our monthly security stakeholder meeting.

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

Logical access controls for FundApps Platform

Data stored in the FundApps platform is classified as 'FundApps Confidential' (see data classification policy).

User Interface

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

• Access via HTTPS only;

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

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

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

• Ongoing security awareness training;

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

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

JIT has a number of benefits:

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

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

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

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

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

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

More information about JIT is available in our Help Centre.

Production

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

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

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

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

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

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

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

• Access review by CTO on a quarterly basis.

Logical access controls for all IT systems

Our data classification policy classifies data stored across all our IT Systems. Principles we follow include:

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

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

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

• Two-factor should be enabled and mandatory whenever possible

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

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

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

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

Physical access controls

See physical security page.

Types of Authentication mechanisms supported by FundApps' platform

FundApps encourages its clients to implement Single Sign-On in order to automate provisioning/deprovisioning of their accesses, and provide their users with a seamless authentication process. Alternatively FundApps supports two-factor authentication as well as traditional user/password credentials. More information is available on FundApps' Help Centre.

Roles and privileges in FundApps' platform

In FundApps' platform, privileges are provided through roles which are assigned to users. More information on these roles and the privileges they grant is available on FundApps' Help Centre.

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

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

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

Guiding principles & security awareness

Top tips

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

• Be aware of the kinds of information we look after as a company and how we protect them. You can find more in our data classification policy.

• Be aware of social engineering - don't trust an attachment or a hyperlink in an email just because it comes from someone you know or an organisation you trust. Better to type the URL into the browser window yourself and avoid that unexpected attachment.

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

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

• Familiarize yourself with our social media policy

Raising others awareness

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

• Join our #ask-security channel in Slack

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

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

Security Musts

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

• Hard disk encryption enabled (BitLocker, FileVault).

• Windows update enabled and configured for automatic update installs.

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

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

• 1Password must be installed and used for all passwords.

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

• If you use your mobile phone for accessing company systems (including email) your mobile phone must have a PIN set and remote-wipe software installed. You must never store data classified as FundApps Confidential on your phone. You can find more in our data classification policy.

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

Daily habits

• Lock your computer whenever you leave it unattended.

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

• Do not store FundApps confidential data on any removable media or equipment in accordance with our data classification policy.

Policies

Credentials

• Use a different password for each service you access.

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

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

• Never share individual account credentials.

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

• In order to facilitate this, use 1Password for securely storing passwords.

Bring your own device

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

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

• You must comply with our data classification policy and ensure you do not store data in breach of this. In particular, never store confidential data on BYODs.

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

• Confidential data must not be stored on BYODs.

Email

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

• Two factor authentication is enforced for your FundApps email. Instructions are here.

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

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

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

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

Physical security

• Lock your computer whenever you leave it unattended.

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

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

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

Data security

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

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

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

• Client data, particularly portfolio data should be treated with great care and in accordance with our data classification policy.

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

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

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

Acceptable use

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

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

• Sending offensive or harassing material to other users

• Any activity that would violate the privacy of others

• Cause damage or disruption to organisational systems

Monitoring

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

Working from outside the office

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

• lock your laptop whenever you leave it unattended;

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

• ensure sensitive conversations cannot be overheard by others;

• do not let anyone use your corporate devices.

Breaches of security

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

• The disclosure of confidential information to any unauthorised person.

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

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

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

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

Further reading

For general awareness, we recommend the following sites.

• Google's Stay Safe Online resources (developed in association with The UK's Citizen's Advice Bureau)

• The UK Government-sponsored Get Safe Online website

• SANS OUCH! Security Awareness Monthly Newsletters

• SANS Security Awareness Video (changes monthly)

For more technical information, check out

• OWASP Top 10 Project

• Security, Cryptography and Privacy (Google)

• SANS reading room

Data Center Physical Security Overview

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

Data Center Access Control

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

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

FundApps Offices Physical Security

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

Logging

FundApps logs system and network events in order to detect and respond to information security threats.

The following events are logged:

• Application events:

  • Login attempts,

  • Changes to users and privileges,

• System events:

  • System accesses,

  • File system accesses,

  • Host-based IPS (Intrusion Prevention System) alerts.

• Network events:

  • Network traffic.

All events are aggregated, stored centrally and protected against alteration.

Monitoring and Alerting

FundApps has processes in place to monitor logs. Automated alerting of certain events or event thresholds allows FundApps staff to detect and respond to a potential security incident 24/7.

Security alerts are reviewed by the Security team and tracked in the Security Incident and Event Management tool, and a summary is provided during the monthly security meeting.

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

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

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

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

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

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

• assess of the seriousness of an incident

• assess the extent of damage

• identify the vulnerability created

• estimate what additional resources are required to mitigate the incident

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

1. Scope & Objectives

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

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

2. Information Security Incidents

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

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

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

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

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

• a firewall is accessed by an unauthorised entity

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

2.1 Categories

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

Unauthorised Access

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

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

• Anomalous traffic to or from the suspected target

• Unexpected changes in resource usage

• Increased response time

• System slowdown or failure

• Changes in default or user‐defined settings

• Unexplained or unexpected use of system resources

• Unusual activities appearing in system or audit logs

• Changes to or appearance of new system files

• New folders, files, programs or executables

• User lock out

• Appliance or equipment failure

• Unexpected enabling or activation of services or ports

• Protective mechanisms disabled (firewall, anti‐virus)

Unauthorised Acquisition

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

• Theft of computer equipment where sensitive data is stored

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

• Illegal entry (burglary)

• Suspicious or foreign hardware is connected to the network

• Normally secured storage areas found unsecured

• Broken or non‐functioning locking mechanisms

• Presence of unauthorised personnel in secured areas

• Disabled security cameras or devices

2.2 Criticality

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

2.3 Roles and Responsibilities

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

3. Key components of our Critical Incident Response Protocol

The Critical Incident Response Protocol consists of these key components

• Detection

• Activation of team

• Containment

• Notification of non-IRT team members

• Assessment

• Notification of external parties

• Corrective Measures

• Washup & lessons learned

• Closure

3.1 Detection

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

3.2 Activation of Team

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

3.3 Containment

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

Containment activities are designed with the primary objectives of:

• Counteract the immediate threat

• Prevent propagation or expansion of the incident

• Minimise actual and potential damage

• Restrict knowledge of the incident to authorised personnel

• Preserve information relevant to the incident

Containment Activities - Unauthorised Access

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

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

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

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

• A4. Disable the affected application(s).

• A5. Discontinue or disable remote access.

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

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

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

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

Containment Activities - Unauthorised Acquisition

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

• B1. Identify missing or compromised assets.

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

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

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

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

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

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

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

3.4 Notification of non-IRT members

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

3.5 Assessment

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

Assessment should consist of the following at a minimum:

Incident data

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

• Who discovered the incident, and how?

Types of information

• What is the nature of the data?

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

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

Risk

• Can we reasonably determine the risk or exposure?

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

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

• Identify the impacted clients, if possible.

• What is the risk or exposure to FundApps?

• What is the risk or exposure to the client?

Next Steps

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

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

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

• What communications need to be established? Provide details

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

• Recap all work and responsibility assignment

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

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

3.7 Gathering Forensic Evidence

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

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

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

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

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

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

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

3.6 Notification of external parties

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

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

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

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

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

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

3.7 Corrective Measures

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

Corrective measures are designed with the primary objectives of:

• Secure the processing environment

• Restore the processing environment to its normal state

Corrective Measures - Unauthorised Access

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

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

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

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

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

• A5. Apply OS and application patches and updates.

• A6. Modify access control lists as deemed appropriate.

• A7. Implement IP filtering as deemed appropriate.

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

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

• A10. Make all personnel “security aware”.

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

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

Corrective Measures - Unauthorised Acquisition

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

• B1. Retrieve or restore assets where possible.

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

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

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

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

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

• B7. Make all personnel “security aware”.

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

3.8 Washup and lessons learned

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

3.9 Closure

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

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

FundApps' privacy policy is available on FundApps' public website.

Objective

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

Scope

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

Policy

Raising Exceptions

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

Approving Exceptions

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

Recording Exceptions

Exceptions must be recorded in the Security Exception Log here[Restricted to FundApps staff].

Reviewing Exceptions

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

FundApps has performed a business impact analysis and maintains a risk register as part of our information security management system. The full risk register is maintained here [Restricted to FundApps staff].

Objective

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

Scope

The policy applies to all FundApps managed Information Systems.

Policy

End user computers

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

Servers

Proxy servers

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

Web servers

Web servers must receive system patches automatically every month.

Other servers

Other servers must receive system patches at least every 3 months.

Objective

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

Scope

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

Policy

Personal Data Retention

Retention of personal data is described in FundApps' privacy policy.

Client Data

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

• Data uploaded to the platform;

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

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

Technical Data

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

FundApps data

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

Objective

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

Scope

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

Vulnerability Detection

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

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

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

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

• Infrastructure vulnerability scanning is performed against our infrastructure weekly.

FundApps' latest penetration test report and response to this report can be found in FundApps' Trust Portal.

Vulnerability Severity Ratings

• Applications

  Application vulnerabilities are rated based on their impact and likelihood. Possible vulnerability ratings are Low, Medium, High and Critical. The rating system is based on the OWASP Risk Rating Methodology (https://www.owasp.org/index.php/OWASP_Risk_Rating_Methodology).

• Infrastructure

  Infrastructure vulnerabilities are rated using the Common Vulnerability Scoring System (https://www.first.org/cvss/user-guide). Possible vulnerability ratings are None (0.0), Low (0.1 - 3.9), Medium (4.0 - 6.9), High (7.0 - 8.9) and Critical (9.0 - 10.0).

Vulnerability Acceptance, Mitigation and Correction

• Process

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

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

• Applications

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

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

• Infrastructure

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

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

Objective

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

Scope

This policy applies to all FundApps projects that have a potential for impacting FundApps Information System or FundApps data as defined in the Data Classification and Protection Standard.

Policy

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

FundApps projects must include information security requirements.

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

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

A list of requirements for new projects is defined in FundApps knowledge management tool [Accessible only to FundApps Staff]

Roles and responsibilities

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

Objective

The purpose of this policy is to define the way in which FundApps maintains the security of information transferred within FundApps and with any external entity.

Scope

This policy applies to all FundApps Information Systems.

Policy

Information transferred within FundApps as well as with external entities must comply with the rules set out in the Transmission section of the Data Classification and Protection Standard, as well as the Acceptable Use section of the Employee guide.

Information must be transmitted through FundApps Information Systems (which include the FundApps managed email system). Exceptions to this requirement must be validated by the Head of Information Security, the CTO or the CEO.

Information transmitted to FundApps through email must be scanned for malware before being downloaded by end users.

Endpoint Detection and Response tools must be deployed to all FundApps devices in order to detect and respond to any malware which may have been transferred to FundApps devices.

Information transferred must be cryptographically encrypted in line with the Cryptographic Policy.

Information protected by a strict ACL (Access Control List) must be transferred in a way which continues to guarantee the ACL is maintained. For example, one should share the link to the information system the information is maintained in, rather than the information itself.

Sensitive information must not be shared over the phone in public places.

Transferring information with clients

When transferring sensitive information with clients, usage of FundApps' platform API or User Interface should be privileged. Sending the information through email as an encrypted password protected attachment is an acceptable alternative.

Upon contract termination, the client may require for FundApps to send information stored in the FundApps platform. The transfer of this information must be made in adherence with any relevant clause in the client contract and the requirements set out in this policy.

Objective

The purpose of this policy is to define the way in which FundApps manages third party risks.

Scope

This policy applies to all FundApps third parties which impact FundApps' Information System.

Policy

Initial Assessment

FundApps assess the risk posed by all third party providers which interact with FundApps' Information System.

This assessment is based on the review of security accreditations the third party might hold (e.g. ISO 27001 certificate, SOC 2 report) as well as specific questions tailored to the Third Party provider.

Regular Review

FundApps reviews the risks posed by critical Third Party providers on an annual basis.

This review is logged in FundApps' monthly security meeting.

Roles and Responsibilities

Objective

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

Scope

The policy applies to all FundApps Information Systems.

Policy

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

Information which requires encryption

The following tables summarises when cryptography must be used:

Encryption of data in transit

All client data sent to or generated inside our platform follows an encrypted data lifecycle and all interactions with the system occur over an encrypted protocol: Secure HTTP (HTTPS). We keep supported cipher suites for the SSL encryption used for HTTPS in line with industry standards and regularly run external tests to verify this, the results of these tests are publicly available.

Encryption of data at rest

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

Encryption ciphers and key lengths

FundApps supports TLS v1.2 and TLS v1.3. The full list of supported ciphers are available on this website.

Encryption ciphers and key lengths used to protect information must comply with requirements set out in NIST Special Publication 800-131A Revision 2.

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

Cryptographic Key Management

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

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

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

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

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

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

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

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

Roles and responsibilities

The system owner (Supplier Relationship Manager), as defined in FundApps' Information System Inventory [restricted to FundApps staff], is responsible for ensuring information to protected by cryptographic controls as set out in this policy.

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