Service Incident and Disaster Recovery

Incident and Response

Flosum's Hosted cloud instance is built on AWS, while the Self-Hosted instance is built on the customer’s cloud or hardware. Flosum interacts with Salesforce, both retrieving and sending data. As such, aspects of Flosum's functionality are directly tied to Salesforce's uptime and availability and are therefore subject to Salesforce's uptime, restore, and recovery SLAs. When Flosum is self-hosted by the customer, aspects of Flosum's functionality are directly tied to the customer's uptime and availability and are therefore subject to the customer's uptime, restoration, and recovery SLAs.

Incident Management and Response

Third-party SLAs guarantee our database availability at 99.95%. The Web Application Firewall (WAF) maintains logs and generates reports of all traffic activities. These logs are used for analysis and forensic purposes, helping our security team identify potential security breaches and take appropriate measures to strengthen the overall security posture of the application. Our policy delineates roles within the Computer Security Incident Response Team (INFOSEC) and outlines which members of Flosum's executive and operational management should be involved in different types of security incidents.

Roles and responsibilities

Incident response will be addressed based on the severity of the incident.

• Chief Information Security Officer (CISO)—The CISO is responsible for assessing the initial scope of a security incident, assembling the Enterprise Incident Management Team, and appointing the Incident Manager.

• Incident reporting—All staff of Flosum are required to report actual or suspected security incidents. All suspected security incidents should be reported to [email protected].

• Incident manager—This role is designated by the CISO and will lead the response to the incident. This is a technical role and will coordinate the work of log collection, evidence preservation, and analysis activities.

• Enterprise Incident Management Team—When a breach of Category 1 data has been declared, the following business administration roles will be added to the incident response team:

  • Senior administrator for impacted unit(s)

  • CISO

  • Others on an as-needed basis

The Enterprise Incident Management Team will, if required, inform individuals outside the EIMT regarding the incident. Members of the Enterprise Incident Management Team and all IT staff shall receive annual incident response training. Tabletop exercises recreating a significant security incident will be conducted at minimum every two years.

Threat Monitoring

Flosum has an intrusion detection and prevention system employed to detect and prevent unauthorized access attempts and to identify and block suspicious or malicious traffic in real-time. By continuously monitoring network traffic, our WAF can analyze incoming requests and identify any abnormal patterns or behaviors that might indicate an attack. Upon detection, the WAF takes immediate action to block or mitigate the malicious traffic, thereby protecting the web application from potential threats.

Platform Backup and Restoration

Data privacy and protection of Flosum client data is of the highest importance to Flosum. Our upgrade policy is inline with the Salesforce release schedule. Our architecture runs across four docker nodes, and we have versioning on our storage so that we can rollback. Flosum is built on Public Cloud environments and backed-up there. Full disaster recovery tests are executed (including failover and failback) annually.

Computing Platform Backup Data

Flosum has a “moment in time” backup, stored as bi-directionally encrypted CSV files, which you can choose to restore your data from a specific restore point. Binary files and big objects are stored in their original format. The backup shows how many records will be backed up, and you have the ability to view and to check the fields and data that was backed up. You can also easily restore records in bulk or look for specific records or sets of records. Users can click on the record ID link to view the record Backup logs can be regularly viewed and alert for prompt issue resolution. Flosum implements a structured backup exclusion policy for selective omission of objects, and ensures related records can be restored alongside primary records for comprehensive data recovery. The following volumes are made available to automated backup, using best available technology for each.

• Production is deployed to Salesforce instances, backed up regularly

• Dev, Staging, Demo instances, backed up nightly

• Workstation data should be backed up to source control or Google Drive - company information should not be stored locally unless it is backed up to a cloud storage at the same time.

Flosum-hosted Backup & Archive is completely segregated from our internal systems, running on AWS. And for customer-hosted Backup & Archive instances, the Backup & Archive Docker image is completely unconnected to Flosum and access is controlled by you.

Computing Platform Backup Schedule

Full backups occur at 09:05 GMT and 17:30 GMT. Backups can be scheduled hourly, if required and manual backups can be triggered at any point in time.

Computing Platform Backup Retention

Well-defined data retention and disposal practices are in place to ensure that data is retained for the necessary duration and securely disposed of when it is no longer needed. This meticulous approach minimizes the risk of unauthorized access or misuse of data. At a minimum, database backups should be retained for a period of at least 5 days and personal backup data shall be retained for one year. Flosum will keep backups for however long the customer requires. Flosum does not impose a retention limit. Return and disposal of data in cases of termination of contract/provision of services is possible. Tenant and associated data will be destroyed/deleted at your request at the termination of the contract.

Disaster Recovery

In the event that your files become corrupt, they can be restored from a Recovery Point, which is the last backup before the corruption event occurred. You have the additional ability to filter by records or by fields to reduce the amount of data restored to a specific dataset.