Flosum Backup & Archive Security and Compliance Statement

Overview

The purpose of this document is to provide an overview of the security measures implemented for our Backup & Archive web application. It covers architecture, access controls, data protection, availability, incident response, and compliance. We take a multi-layered approach to securing systems and data in our application environment. Combining policies and technology helps us safeguard your sensitive information and provide reliable access to our services. Please direct any other questions regarding our platform or services to [email protected]. Included in this document are:

System Architecture APIs Network Security Authentication Data Management Logging Compliance Cloud Computing Patch Management Protocols Data Protection Risk Management Framework Service Incident and Disaster Recovery Software Development Security Guidelines Vendor Risk Management

System Architecture

The Backup & Archive application frontend and backend are segmented on different subnet zones for security isolation. Our web servers are placed in a DMZ network, and database servers reside on a separate internal network. Firewalls, IPS, and strict access controls limit traffic between application tiers. Flosum has configured Security Groups that allow making requests only on port 443. Backup & Archive also provides a configuration file for self-hosted environments that can be used to re-configure ports as needed. The latest stable versions of frameworks and languages are used to avoid known vulnerabilities. The operating systems and software libraries are frequently patched and hardened. Load Balancing and failover systems maintain uptime during traffic spikes. Infrastructure redundancy removes single points of failure. Logical segregation of database data from other customers is applied. Customer-Hosted is a dedicated-tenant architecture. Flosum-Hosted is multi-tenant segmented by Salesforce Org ID. Flosum Backup & Archive does not have a data sharing mechanism. Communications take place only in the UI, or with the Salesforce orgs being backed up. Stringent access controls are in place to ensure the isolation of every Backup & Archive account within a dedicated virtual machine, in accordance with Backup & Archive SOC2 Type II policies. S3 buckets are never exposed to the public internet. They are set to Private as default and it is never changed. Flosum also uses a reverse proxy server to provide private links to customers.

APIs

User credentials are stored using HASH (SALT) SHA-256 algorithms or when reversible AES-256 or superior. Bulk and Rest API limits can be defined to meet customer requirements. OAuth 2.0 via OpenID Connect is used for SSO for both authentication and authorization, and supports OpenID and related standards. The app limits API usage to a percentage of the available Salesforce API limit per day. The backup log would show the limit is hit and would automatically throttle to ensure Salesforce performance is not impacted.

Network Security

The Network Security group will implement and maintain controls required to protect against risk realization and losses associated with security threats to Flosum networks and network resources. Multiple layers of controls to secure, manage and monitor the network environment are required and shall be implemented as appropriate. Controls must exist to protect network devices against unauthorized entry, protect sensitive information as it traverses through the Flosum network and monitor for any unauthorized access that could compromise the confidentiality, integrity or availability of the network infrastructure. In order to appropriately secure the network, prevent unauthorized entry or access, and to mitigate against potential security or operational threats to the Flosum network environment, perimeter controls are required to be implemented. Perimeter controls include, but are not limited to firewalls, routers, intrusion prevention and detection systems, and security information management systems to provide data gathering, notification and analysis. Active management and monitoring of perimeter devices is required to help ensure that current access controls and settings are appropriate based on security and business needs. Additionally, remote access controls must be implemented to further enhance the protection of the Flosum network environment from inappropriate access. Flosum employees remotely accessing the Flosum environment are required to use a firewall, and anti-malware software. Any device accessing the Flosum network environment (including devices located in remote locations) must meet Flosum security requirements for hardware, interoperability and change management. Where possible, operational responsibility for networks should be managed separately from computer operations. To further strengthen and add an additional layer of security, internal and external transmission controls, such as the use of an encrypted protocol, and controls to monitor network activity must be in place to maintain the confidentiality and integrity of information as it traverses in, across, and out of Flosum’s network environment. Monitoring controls must be implemented on Flosum networks to identify and report anomalous activity to appropriate management or response groups. In the event a security related event is identified, timely investigation and remediation is required. Information technology continues to advance and threats against network environments continue to evolve. To help ensure Flosum network environments are appropriately protected against current and evolving threats, periodic reviews of security practices are required. The scope of network testing must include the security of network entry points into Flosum’s network environments to identify and correct any potential weaknesses that could be exploited. Management oversight should be applied to consistently apply the controls across the applicable infrastructure while continuing to optimize the service to the enterprise.

Mobile Device Policy

The use of personal devices to connect to Flosum network resources, not directly associated with satisfying work obligations, is strictly prohibited.

Physical devices (i.e. laptops, cell phones, tablets, portable storage media, and other mobile devices) must be securely safeguarded when they are not in use.
Lost or stolen Flosum IT Resources must be reported immediately to the appropriate personnel.
Confidential or client data cannot be stored on portable devices and/or media unless:
- Specifically required to achieve a business purpose
- Authorized by Flosum office of Chief Information Security Officer
- Such storage is not in violation of regulatory or contractual obligations
- Appropriate controls are put into place to safeguard the data
Flosum confidential or client data must be encrypted if stored on portable devices in accordance with encryption standards.

Authentication

Flosum uses a variety of authentication methods, including SAML 2.0 for SSO and IAM, to secure your data and provide the highest levels of security. Our policy supports integration with identity providers in a native way, and does not use intermediary authentication/authorization tools (e.g., Keycloak, Auth0, Cognito, etc.). The system uniquely identifies and authenticates each individual user. Anonymous authentication is prohibited.

Single Sign On (SSO)

We prioritize efficiency and security by implementing an SSO solution. SSO significantly improves security by reducing the risk associated with password-related vulnerabilities and ensuring a more robust and centralized authentication system that maintains the highest standards of data protection. IP restrictions require a customer-hosted instance and configuration of the attendant AWS or GCP environment.

Multi-Factor Authentication (MFA)

Security of our digital assets is paramount, and as part of our comprehensive security measures, we employ MFA. By implementing MFA, we significantly bolster our defense against unauthorized access, safeguard sensitive information, and fortify our systems against potential threats. This proactive approach to security not only aligns with industry best practices but also underscores our commitment to ensuring the utmost confidentiality and integrity of our network. Flosum has enabled Multi-factor Authentication (MFA) delete, which turns on the MFA delete capability to require additional authentication to delete objects in a versioned S3 bucket. We use access points and VPC endpoints. All access points and VPC endpoints allow access to S3 without exposing the entire bucket, which restricts what can be accessed in the S3 bucket.

Access Management

Backup & Archive implements stringent access controls to ensure the isolation of every Backup & Archive account within a dedicated virtual machine, in accordance with Backup & Archive SOC2 Type II policies. The application's functionality is restricted and can be managed through the identity provider. All activities within the application, including those performed by root accounts provisioned via the IDP, are meticulously logged and monitored. Flosum staff are not able to access the customer's org hosting the Flosum application unless temporary support access is granted. For Flosum-hosted versions of Backup & Archive, we practice the principle of least privilege. Less than 1% of our employees have admin access and even fewer have root access to our cloud computing environment. Additionally, we segregate hosted Backup & Archive tenants and allow customers full control over the users allowed to access their instance.Once granted, Flosum and customer staff can collaborate to inspect logs, error messages, and other Salesforce capabilities to troubleshoot. Activity logs undergo regular review and analysis to identify and prevent any potential intrusions or suspicious activities swiftly. Robust password policies are in place to enforce the use of strong passwords, regular password changes, and forced password changes upon first login, reinforcing the overall security of the systems. Access to the Backup & Archive application is controlled through the User Pool service. User Pool provides authentication, authorization, and user management for applications. More information can be found here: https://success.flosum.com/s/article/User-Pool-App. With the User Pool app, not only can you use Flosum-specific credentials but also integrate your own Single Sign On Identity Provider (SSO) for a smoother login experience. For customer-hosted instances of Backup & Archive, Flosum has no access to your instance and we give you full control over access. User permissions prevent users from starting unauthorized backup and restore operations.

Remote Access

Trusted users may only gain access to Flosum as defined:

Users require VPN access for specific services
The device MAC ID may be required depending on firewall configuration for specific service being accessed.
The trusted user needs to have a “tacticalarbitrage.com” user ID. This grants permission and access to Flosum resources (data, services, online hosts, communications, shared content). This provides a basic level of access.

Data Management

Data Encryption

Users provide an AES-256 or equivalent key when connecting Salesforce orgs. This key is used to encrypt the data in-flight between Salesforce and the Flosum tool and at-rest in the Flosum tool. The data is further encrypted by a TLS 1.2 pipe through the HTTPS protocol in-flight and with an AES-256 or equivalent key when at-rest in the tool's disks. We encrypt your data at rest, with server-side encryption (SSE), using S3 managed keys (SSE-S3), AWS Key Management Service (SSE-KMS), and server-side encryption with your customer-provided keys (SSE-C). Flosum Backup & Archive only supports TLS 1.2 and its later versions and data encryption is provided throughout the entire pipeline. Flosum manages data access with Identity Access Management (IAM). We have IAM policies and permissions in place, to ensure only authorized users and services can access AWS S3 buckets and objects, and avoid using root account credentials. And, Flosum restricts bucket policies. Our bucket policies define what requests are allowed or denied on the bucket. We lock these down to deny all requests by default and only allow necessary permissions.

At-Rest Encryption

Confidential Information or PII at rest on computer systems owned by and located within Flosum-controlled spaces, devices, and networks should be protected by one or more of the following mechanisms:

Disk/File System Encryption (e.g. Microsoft EFS technology)
Use of Virtual Private Networks (VPN’s) and Firewalls with strict access controls that authenticate the identity of those individuals accessing the Confidential Information or PII
Sanitizing, redacting, and/or de-identifying the data requiring protection during storage to prevent unauthorized risk and exposure (e.g., masking or blurring PII)
Supplemental compensating or complementary security controls including complex passwords, and physical isolation/access to the data
Strong cryptography on authentication credentials (i.e. passwords/phrases) shall be made unreadable during transmission and storage on all information systems
Password protection to be used in combination with all controls including encryption
File systems, disks, and tape drives in servers and Storage Area Network (SAN) environments are encrypted using industry standard encryption technology
Computer hard drives and other storage media that have been encrypted shall be sanitized to prevent unauthorized exposure upon return for redistribution or disposal

Portable Device Encryption

As a general practice, confidential Information or PII shall not be copied to or stored on a portable computing device or Flosum-owned computing device. However, in situations requiring Confidential Information or PII to be stored on such devices, encryption reduces the risk of unauthorized disclosure in the event that the device becomes lost or stolen. The following procedures shall be implemented when using portable storage:

Hard drives (laptops, tablets, smartphones and personal digital assistants (PDAs)) shall be encrypted using products and/or methods approved by the Flosum office of the CISO. Unless otherwise approved by management, such devices shall have full disk encryption with pre-boot authentication.
Devices shall not be used for the long-term storage of any Confidential Information or PII.
All devices shall have proper and appropriate protection mechanisms installed including approved anti-malware/virus software, personal firewalls with unneeded services and ports turned off, and properly configured applications.
Removable media including CD’s, DVD’s, USB flash drives, etc. shall not be used to store Confidential Information or PII.

In-Transit Encryption

In-transit encryption refers to the transmission of data between end-points. These policies intend to ensure that Confidential Information or PII transmitted between companies, across physical networks, or wirelessly is secured and encrypted in a fashion that protects Confidential Information or PII from a breach. Data transmission and system console access is performed using channel encryption. The Chief Information Security Officer or their designee shall ensure:

Formal transfer policies, protocols, procedures, and controls are implemented to protect the transfer of information through the use of all types of communication and transmission facilities.
Users follow Flosum acceptable use policies when transmitting data and take particular care when transmitting or re-transmitting Confidential Information or PII received from non-Flosum staff.
Formal transfer policies, protocols, procedures, and controls are implemented to protect the transfer of information through the use of all types of communication and transmission facilities.
Users follow Flosum acceptable use policies when transmitting data and take particular care when transmitting or re-transmitting Confidential Information or PII received from non-Flosum staff.
Strong cryptography and security protocols (e.g. TLS, IPSEC, SSH, etc.) are used to safeguard Confidential Information or PII during transmission over open public networks. Such controls include only accepting trusted keys and certificates, protocols in use only support secure versions or configurations, and encryption strength is appropriate for the encryption methodology in use.
Only accepting trusted keys and certificates, protocols in use only support secure versions or configurations, and encryption strength is appropriate for the encryption methodology in use.
Public networks include but are not limited to the Internet, Wireless technologies, including 802.11, Bluetooth, and cellular technologies.
Confidential Information or PII transmitted in e-mail messages are encrypted. Any Confidential Information or PII transmitted through a public network (e.g. Internet) to and from vendors, customers, or entities doing business with Flosum must be encrypted or transmitted through an encrypted tunnel (VPN) or point-to-point tunneling protocols (PPTP) that include current transport layer security (TLS) implementations.
Wireless (Wi-Fi) transmissions used to access Flosum computing devices or internal networks must be encrypted using current wireless security standard protocols (e.g. RADIUS, WPS private/public keys or other industry standard mechanisms).
Encryption or an encrypted/secured channel is required when users access Flosum Confidential Information or PII remotely from a shared network, including connections from a Bluetooth device to a Flosum PDA or cell phone.
Secure encrypted transfer of documents and Confidential Information or PII over the internet uses current secure file transfer programs such as “SFTP” (FTP over SSH) and secure copy command (SCP).
All non-console administrative access such as browser/web based management tools are encrypted using SSL based browser technologies using the most current security algorithm.

Encryption Key Management

Effective enterprise public and private key management is a crucial element in ensuring encryption system security. Key management procedures must ensure that authorized users can access and decrypt all encrypted Confidential Information or PII using controls that meet operational needs. Flosum key management systems are characterized by following security precautions and attributes:

Flosum uses procedural controls to enforce the concepts of least privilege and separation of duties for staff. These controls apply to persons involved in encryption key management or who have access to security-relevant encryption key facilities and processes, including Certificate Authority (CA) and Registration Authority (RA), and/or contractor staff.
Chief Information Security Officer shall verify backup storage for key passwords, files, and Confidential Information or PII to avoid single point of failure and ensure access to encrypted Confidential Information or PII.
Key management should be fully automated. Flosum Chief Information Security Officer should not have the opportunity to expose a key or influence the key creation.
Keys in storage and transit must be encrypted.
Private keys must be kept confidential.
Application and system resource owners should be responsible for establishing data encryption policies that grant exceptions based on demonstration of a business need and an assessment of the risk of unauthorized access to or loss of Confidential Information or PII.
Decryption keys are not associated with user accounts. They are cached in RAM for a short duration but not stored in the application.
Documentation and procedures exist to protect keys used to secure stored Confidential Information or PII against disclosure and misuse.
Restrict access to cryptographic keys to the fewest number of custodians necessary.
Cryptographic keys are stored in the fewest possible locations.
Key management processes and procedures for cryptographic keys are fully documented.
Retirement or replacement (for example, archiving, destruction, and/or revocation) of keys as deemed necessary when the integrity of the key has been weakened or keys are suspected of being compromised.

Note: If retired or replaced cryptographic keys need to be retained, these keys must be securely archived. Archived cryptographic keys should only be used for decryption/verification purposes. Cryptographic key custodians shall formally acknowledge that they understand and accept their key-custodian responsibilities.

Audit Controls and Management

On-demand documented procedures and evidence of practice should be in place for this operational policy as part of Flosum operational methodology.

Flosum shall inventory encrypted devices and validate implementation of encryption products at least annually.
Documentation shall exist for key management procedures.
At-Rest encryption procedures exist and can be demonstrated.
In-Transit encryption procedures exist and can be demonstrated.
Exception logs exist and can be produced for those resources that are excluded from this policy.

Data Geo-Fencing

Geo-fencing for certain regions. This ensures that specific data can be kept in specific regions as required by the clients.

Data Residency

Flosum Hosts Backup & Archive in the US Ohio and in Germany and customers can use both of those hosted sites if they have residency requirements. Customers can also self-host in countries/regions if needed. Each Salesforce org is connected to one Flosum tenant.

Logging

Logging is done with our S3 server access and object-level API activity. We utilize versioning to track changes over time, which allows easy rollback to previous versions. Flosum also uses cross-region replication for geographically separate backups and enhanced availability. We maintain object locks and MFA delete on backup buckets. Logs are collected through Syslog from multiple instances and tiers, including application, network, and OS events. These logs are then centrally reviewed and analyzed for further insights and actions. Additional logging is available in the AWS Cloud Trail for the tool. Extensive audit trails record all actions performed by users (login/creation/change/addition/deletion of content, settings, parameterizations, etc.) and on users (creation/change/deletion of users, inclusion/change/deletion of access profiles, password changes, etc.).

Compliance

We ensure compliance with industry-specific regulations and standards (e.g., GDPR, HIPAA, PCI DSS). Flosum is SOC 2 Type II certified. Flosum completes regular audits and assesses compliance annually. It is also compliant with ISO 27001 equivalents. We conduct annual security assessments and run Snyk Security scans after every production release.

Cloud Computing

Flosum uses the Amazon Web Services automated Functional Technical Review framework to audit and evaluate our security controls, and make changes regularly to support their suggested best practices. Cloud Trail and other AWS services to monitor our environment and notify us of issues we need to resolve. Hosted services are audited every six months by reputable 3rd parties. For AWS, see https://aws.amazon.com/compliance/programs, for Salesforce, see https://compliance.salesforce.com/en/documents/a005A00000k50uvQAA.

Patch Management Protocols

Patch management is a crucial process that involves keeping software and systems up to date in order to address known vulnerabilities. It involves regularly applying patches, updates, and fixes to software and operating systems to ensure their security and stability. By keeping software and systems up to date, Flosum effectively mitigates the risk of potential security breaches and cyberattacks. Patch management helps to address known vulnerabilities by closing security loopholes and fixing bugs that could be exploited by malicious actors. Flosum’s patch management strategy includes regularly monitoring for available patches, testing them in a controlled environment, and deploying them across the organization's infrastructure, as well as:

A risk-informed systems patch cycle for all server operating systems (OS) shall be scheduled, as appropriate, for Information Systems and related subsystems.
Any emergency patching outside of the routine patching schedule shall be done according to level of risk, as determined by the Information System Owner in consultation with the CISO.
Servers, services, or applications shall be maintained with current OS, application, or security patch levels, as recommended by the software manufacturer and informed by risk, to protect Flosum Information from known information security issues.

In addition to addressing security vulnerabilities, our patch management also plays a vital role in maintaining system performance and reliability. Software updates often include performance enhancements and bug fixes, which can result in improved functionality and reduced system downtime. Overall, patch management is an essential practice to proactively protect our software and systems from potential threats. By keeping software up to date, we maintain a secure and resilient IT environment.

Data Protection

At Flosum, we are committed to protecting the privacy and security of our customers' data. Our SaaS application fully complies with the General Data Protection Regulation (GDPR), ensuring that we handle personal data in accordance with the highest standards of data protection and privacy. We have implemented robust technical and organizational measures to safeguard the personal data we process on behalf of our customers. This includes:

Strict data access controls and authentication mechanisms
Encryption of personal data both in transit and at rest
Regular security audits and assessments
Data processing agreements with our sub-processors
Providing customers with tools to manage data subject requests
Ensuring data portability and the right to be forgotten

Our dedicated privacy team continually monitors and updates our practices to maintain compliance with GDPR and other relevant data protection regulations. We are transparent about our data processing activities and provide our customers with clear information about how we collect, use, and protect their personal data.

Trust, Availability, and Business Continuity Plans The Flosum Disaster Recovery Plan documents our processes to recover from outages. More information can be found here: https://success.flosum.com/s/article/Security-Compliance.

Risk Management Framework

Flosum understands the importance of risk management in maintaining the security and compliance of our software applications. To effectively manage risks, we follow a risk management framework that is designed to identify, assess, and mitigate risks throughout the software development lifecycle. The risk management framework comprises the following steps.

Risk Identification - During the planning phase of the SDLC, we identify potential security risks that could affect the software application. This is done by considering factors such as user authentication and access control, data protection, and threat modeling. We use risk assessment templates and checklists to help identify potential risks.
Risk Assessment - Once we have identified potential risks, we assess the likelihood and impact of each risk to determine its priority for mitigation. We use quantitative and qualitative methods to assess risks, such as conducting risk surveys or using risk matrices.
Risk Mitigation - Based on the results of the risk assessment, we develop a plan to mitigate the identified risks. This may involve implementing security controls, such as access controls, encryption, or intrusion detection systems, to reduce the likelihood or impact of the risk. We prioritize mitigation activities based on the level of risk and available resources.
Risk Monitoring - After implementing mitigation measures, we continue to monitor and assess the effectiveness of the controls. This includes conducting regular security audits, vulnerability assessments, and penetration testing to identify any new or existing vulnerabilities. We also monitor the system logs and user activity to detect any unusual activity that could indicate a security breach.
Risk Reporting - We maintain a risk register that documents all identified risks, their likelihood and impact, and the status of mitigation measures. We report on risk management activities to stakeholders, such as management and regulatory bodies, to ensure transparency and accountability.

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.

Productiondeployed 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 termination of a 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.

PreviousBackup & Archive Pentest Report NextSystem Architecture

Last updated 1 month ago

Was this helpful?