SF 1. Situation
This document is part of the Storyfox cybersecurity framework. This document defines the minimum security controls relevant to access control and rights management. These rules are mandatory to all Storyfox information systems for all Storyfox employees, clients and partners.
These rules have been defined by the CISO and validated by the CODIR.

SF 2. Principes

Storyfox is a French company that provides in SAAS mode a video solution for businesses. Safety is at the heart of our business. We devote a lot of resources and energy to:

• Securing our information system;
• Build secure solutions for our customers
• Host our customers' data with maximum security.
  
  Building a lasting and trusting relationship with our customers is essential for us. With the increasing exposure of web platforms to IT security threats, we take our role very seriously to protect our infrastructures and those that our customers entrust to us and work daily to consolidate our services. This is why Storyfox has implemented a security approach with the aim of obtaining benchmark labels and certifications on the market, which are a guarantee of quality and trust for you. Our employees adhere to this approach and actively contribute to it on a daily basis. Responsible, they ensure that the security rules are known, understood and applied, in their area of ​​intervention and within their mission. Vigilant, they are on constant alert during their various uses and uses of information systems, in order to detect possible incidents and adopt the appropriate behavior in a risky situation. This Information Systems Security Policy is applicable in the context of service relationships between Storyfox and its Clients.
  
  At Storyfox, learning and applying security measures begins when employees are hired, so that the culture of security is disseminated throughout the company. Each employee is aware of the threats to information systems and therefore knows their responsibilities in relation to them. This allows him/her to take on a permanent role as an actor.
  
  For this, training in the proper use of IT resources (based on the ANSSI guide: https://www.ssi.gouv.fr/uploads/2017/01/guide_cpme_bonnes_pratiques.pdf) is provided to each employee upon their arrival at Storyfox and is supplemented regularly by additional training.

SF 3. Organization

Chief information security officer (CISO): Nicolas Bellot nicolas@storyfox.io 
Codir: Julie Machillot, Pauline Campanella, Pierre Castanet, Nicolas Bellot
Security Advisory Board: Julie Machillot, Investors

SF 4. Access control and rights management
SF 4.1. Risks
The security controls defined here must be implemented to face the threat on our Information System (IS):
- Cyber attacks
- Confidential data theft/Leak
- Saturation of Infrastructure
- Cyber Espionage

The cybersecurity policy enforcement aims to limit the impacts the major
cybersecurity risks defined at company level:
- Fraud
- Targeted of massive attacks
- Information disclosure or theft
- Data corruption

Therefore, at any time, Storyfox must be able to answer to the following
questions:
- What are the accesses of a user?
- Who has access to information or an asset?
- Who is responsible for validating these accesses?

Through this directive, Storyfox affirms its desire to ensure compliance with
national and international laws and regulations, to enhance its performance
and to preserve the value of its assets.

SF 4.2. Purposes
To prevent unauthorized access to information, this directive defines access
control and rights management rules. Those rules aim to: grant access to
information a known person, grant access to information to authorized user and protect the confidentiality of secret authentication information grant access to information on a need-to-know basis (principle of ’least privilege’) in line with business needs, grant access rights from a reliable source.

SF 4.3. Identification management
SF 4.3.1. Unique identifier (ID)
In order to ensure traceability, each user must have a personal
identifier when accessing an IS resource.

Identifiers must be constructed with a specific naming convention
The usage of the same personal identifier by different users is strictly
forbidden.

SF 4.3.2. Client and technical account
2 types of client accounts:
- Admin to handle client’s workspace
- User to use the service
Technical account purpose is to manage the service and they are
used by Storyfox’s employees.

SF 4.3.3. Administrator ID
Administrator identifiers that grant access with high privileges must be
different from user identifiers assigned to the administrators. All IDs
that grant privileged access (Admin or Operator for example) must be
separated/different from the standard ID of the user.
Administrator identifiers should be used only for administration tasks
and not to access a system as a standard user.

SF 4.4. Authentication management
SF 4.4.1. User authentication
A personal user account and an authentication step are required for
accessing restricted (non public) IT resources. The secret authentication information (password for example) must be defined for each user in respect of local/entity password policy.
Log-on procedure must respect these following's rules:
▪ Not display system or application identifiers until the log-on process
has been successfully completed.
▪ Not provide help messages during the log-on procedure that would
aid an unauthorized user.
▪ Validate the log-on information only on completion of all input data. If
an error condition occurs, the system should not indicate which part of
the data is correct or incorrect.
▪ Terminate inactive sessions after a defined period of inactivity,
especially in high risk locations such as public or external areas
outside the organization’s security management or on mobile devices.
▪ Protect against brute force log-on attempts.

SF 4.4.2. Centralized account management system
Centralized account management is the preferred method for authentication and authorization to control the access to IS components (applications/services/resources).
If a component couldn’t be integrated with a centralized account
management system, this component must implement a high security
level (secure log-on procedure, secret authentication information
protection, traceability...) to provide the same level for credentials
protection.

SF 4.4.3. Strong authentication and prefered secret authentication information
Authentication that allows access to a critical application / service /
resource directly exposed to the Internet from an unmanaged device must enforce a strong authentication, for any type of user.
Collaborative tools are considered critical. If a multi factor authentication is impossible, access to the service must be strictly restricted to internal network or authenticated devices. Authentication that allows access to technical or logical components with high privileges must use a multi factor authentication when possible. This is mandatory in high risk locations such as public or external areas outside the organization’s security management
(remote access for example) or on mobile devices. This multi authentication could be implemented through a VPN access or an administrator bastion.
If a strong authentication is impossible, a more stringent password policy applies to accounts with privileges (password length, lifetime reduced…), access must be IP filtered and a formal list of these accounts must be maintained. As far as possible must be used a Zero-Knowledge Password Policy Check. Authentications must preferably use Single Sign On (SSO) linked to the SSO solution.

Dedicated user / password should be the last choice to authenticate to an application / service / device.
The first sign on to the SSO solution can use the following mechanisms:
1. On device: Biometric solutions (ex: face / fingerprint)
2. Certificate / token / authentication app on smartphone
3. Password

SF 4.4.4. Password management policy and protection
In case of use of password, the following's rules must be respected by default:
▪ Password minimal length: 12 characters
▪ Password complexity: use a least 3 followings rules: both upper-case
and lower-case letters, inclusion of one or more numerical digits,
inclusion of special characters such as @, #, $
▪ Password maximum lifetime: 180 days
▪ Prohibits password reuse: 4 last passwords
▪ Prohibits to change password for 24 hours

The user must change its password on first login.

Default vendor password should be modified following installation of systems or software. If the user wants to change its password, a re authentication is mandatory. For any modification request (forgotten password for example), the identity of the user must be checked, and the request must be logged. For generic accounts (or service accounts), the confidentiality of passwords should be maintained when shared (e.g. changing passwords frequently and as soon as possible when a privileged user leaves or changes job, communicating them among privileged users with appropriate mechanisms…).

The password must be communicated to the user in a secure way. The identifier and the password must be communicated to the user through different channels. Passwords must be kept secret. As it may not be possible for users to remember all their passwords associated with multiple accounts, Usage of password management tools approved by the security team is recommended (OnePassword). Usage of password management tools is mandatory for high privileges users, or if this information must be shared (generic account for example). Proper protection of passwords must be implemented when passwords are used as secret authentication information in automated log-on procedures (ex: encryption mechanism). On the systems/applications, Passwords must be stored in an irreversible way or use strong algorithms and must not be readable/unencrypted by IS administrators.

SF 4.4.5. Authentification audit log
Each unsuccessful or successful authentication attempt (just like brute
force attempt) to IS systems must be logged. It must be timestamped, associated with an account and recorded. Authentication logs are kept during a predefined period, in accordance with legal requirements, for later investigation or access control monitoring. By default, log files are kept for one year.

SF 4.5. Access Rights
SF 4.5.1. RBAC
For each application, links between business roles and application access rights must be formalized in a matrix (“role-based access control” basis). Matrix must describe which function/data can be accessed by a particular role, and the right levels (ex: read, write, delete and execute). Then, access privileges must be granted in accordance with this matrix. Access rights must be granted on a need-to-know basis (principle of ’least privilege’). Access rights must be granted to preserve segregation of duty (SoD). For example, a SoD must be preserved between Run and Development within the IT team.

SF 4.5.2. Right access provisioning and authorization
Access request forms must be used to request, change or delete access privileges. Those forms include the following information:
▪ Date of the request.
▪ Information about the user who needs the access privileges.
▪ Corresponding applications and roles.
▪ Validity date.

Each step of the access privileges management process (request, approval and technical implementation) must be logged and recorded for later use or report.

SF 4.5.3. Access right approval and review
Each access request must be approved by the manager for internal
users and contract manager for external users.
Resource owners must ensure that the principles of ’least privilege’
and ’segregation of duties’ are applied. Requests related to sensitive
access rights or involving segregation of duty conflicts must also be
approved by the CISO.
The review of access privileges is the process of verifying that each IS
account has been granted the correct access privileges. Those privileges must be compliant with the principles of ’least privilege’ and SoD. Authorizations for privileged access rights (administrator accounts for example) should be reviewed at more frequent intervals (at least each 6 months). This review must be done once a year. The scope includes:
▪ User accounts.
▪ Administrator accounts.
▪ External users accounts.
▪ Generic and technical account.

Corrective actions must be carried out, following the results of this
review (deletion or modification of access privileges). This review is performed by the application / resource / service owne and the user managers under the CISO control and must be recorded. Implement a way to get access rights granted to a user ID (or to an application/service/resource) available at any time.

SF 4.6. Recording and deletion
In the case of a process of recording for a client, all its data are exported to usable format. This data will be after validation, fully deleted from our IS.


SF 5. Data security & classification
SF 5.1. Risks
The implementation of these security rules aims to protect Storyfox’s
information from the following threats:
Prevent unauthorized or irrelevant access to information

SF 5.2. Purposes
In order to prevent these threats, this directive defines information classification rules to ensure that information receives an appropriate level of protection in accordance with its importance to the organization.

SF 5.3. Classification
Expose to all Storyfox employees the data management rules within the
company. Evaluate the impacts in the event of a data leak or theft to assign an appropriate level of confidentiality to identify the security measures necessary to protect it.

SF 5.3.1. Process
Each document must belong to an owner in charge of classifying and determining access rights to it. Classify documents at the time of their creation (or when they are taken in charge from external sources).

SF 5.3.2. Levels
L0 - Public: Information and media that can be released publicly.
There is no impact of confidentiality by the dissemination of this
information.
L1 - Internal: Information or support that can be disclosed to Storyfox
users if needed. Uncontrolled diffusion could lead to negative impacts.
This information must not be disclosed, as is, outside the Storyfox
company.
L2 - Restricted: Information or media whose disclosure must be
limited to those who need to know them in order to carry out their
tasks. Disclosure could harm the Storyfox company not in a vital way.
L3 - Confidential: This information or media must only be shared
between a group of clearly identified persons. Information or media
unauthorized disclosure or loss could significantly and durably harm
the Storyfox company.

Set by default to L0 - Internal, documents whose classification has not
been determined.
The document’s owner (or his manager) must be able to declassify the
document. All documents containing sensitive* (as described in GDPR) personal data must be set at least at level L2.

SF 5.3.3. Marking
Carry out the marking of the classification by means of a cartridge on the document. If the storage solution allows it, make an electronic marking of the document. Make it mandatory to mark email headers in case of "confidential" classification. Provide classification marking on all document templates.

SF 5.3.4. Data handling
Respect and enforce the rules presented in the attached tables for the creation, manipulation, storage, transfer and sharing, copying / printing and destruction of data. If any unmarked document is considered a Level L1 - Internal Use document, the rules applicable to that category must be respected by default.

SF 5.3.5. Third parties
Each document must belong to an owner in charge of classifying and determining access rights to it. Classify documents at the time of their creation (or when they are taken in charge from external sources).

SF 6. Services, endpoints and network access
SF 6.1. Risks
This document defines the security rules and requirements related to
Storyfox’s network infrastructures. The implementation of these security rules aims to protect Storyfox’s network (and by extension, all resources connected to the network) from the following threats:
Network intrusion and unauthorized access to Storyfox’s resources, Eavesdropping on network data traffic and / or alteration of transmitted data Denial of service,
The scope of this policy covers all types of networks: both data networks and
voice networks.

SF 6.2. Purposes
In order to prevent from these threats, this directive defines network,
endpoint, services and communications rules to:
- prevent unauthorized physical access or damage to Storyfox’s resources,
- prevent unauthorized logical access, damage and interference to Storyfox's
resources,
- prevent for malicious lateral movement,
- prevent from data leak and or listening on network.

SF 6.3. Physical security
Telecommunications lines of critical information processing facilities (such as datacenter) should be redundant and underground or subject to adequate alternative protection.

Access to the network hardware at the end of the telecommunication line
(router, ADSL box…) must be controlled (ex: mounted in a closed rack system or installed in a separate closed room).
Access to patch panels, cable rooms and networking hardware (ex: switches,
router) must be restricted (ex: mounted in a closed rack system).
If possible, Wi-Fi access points must be put in inaccessible areas.
Switch ports that are not currently used must be disabled.
Network plugs in public areas must not be connected to the network hardware.

SF 6.4. Network access and services
SF 6.4.1. Wifi
The authentication, encryption and user level network access control technologies of modern, standards based wireless networks must be implemented with protocols based on cryptographic specifications. Private VLAN function with isolated mod and WPS function deactivation must be used. Default SSID name must be changed.
For internal devices or users, authentication to Wi-Fi networks through
a directory should be implemented using machine certificates or user
credentials.

SF 6.4.2. Remote access
Remote access must be implemented by using tunneling technologies
(VPN SSL, VPN IPSEC...). Remote access clients must be strongly authenticated (ex: multi-factors authentication as MFA, ...).

SF 6.4.3. Interconnexion with tiers
Interconnexion with partners / suppliers must be implemented by using tunneling technologies (VPN SSL, VPN IPSEC...) and must be formalized and kept up to date. Interconnection must be reviewed at least annually. Authentication of both ends of the tunnel must use strong encryption.

SF 6.4.4. Availability
Availability of data centers networks must be guaranteed to provide a high service level: redundancy mechanism, back-up Internet links, monitoring… must be defined and implemented.
Network recovery mechanisms must be tested on a regular basis and at least once a year.

SF 6.5. Segregation and filtering
Microsegmentation (creating secure zones in data centers and cloud deployments that allows to isolate workloads from one another and secure them individually) is implemented in our services and application implementations and mandatory for the IaaS environment. These segregation and filtering are handled by our Cloud provider. Our different environments (development, staging and production) are also totally different and no data are transferred between them. Also all client’s data and assets are isolated and not accessible to non authorized users.

SF 6.6. Traceability of network traffics
Appropriate logging and monitoring must be applied to enable recording and detection of actions that may affect, or are relevant to, information security. At least, all rejected packets by a filtering system must be logged. All packets rejected and accepted must be logged from / to a sensitive component connected to the network.

Network intrusion detection and prevention systems (IDS/IPS) must be implemented as appropriate for detection and deny of suspicious or unauthorized network activity. Anti-malware systems must be implemented as appropriate to analyze and block malicious traffic.

URL filtering systems must be implemented as appropriate to analyze and
block malicious or forbidden traffic. Reverse Proxy/WAF: Sensitive applications must be monitored from a security standpoint and may require additional security mechanisms such as Web Application Firewall, log collection and correlation… We are using our Cloud provider tools to manage these tasks.

SF 6.7. Endpoint management
Assets associated with information and information processing facilities must be identified. An inventory of these assets must be drawn up and maintained. Assets maintained in the inventory must be owned. Public endpoints must be kept under surveillance, and for those which are not located in offices or in public places, located in a building with enforced
access control. Access control must be operational on the endpoint, especially during startup and to unlock sessions. Standby mode must be activated automatically when an endpoint is not used during a specific period. This period should be chosen according to the risk for the endpoint to be accessed by an unauthorized person.

Advanced rights must not be given to standard users (e.g. administrator rights), unless special dispensations, involving the creation of additional accounts limited to necessary actions, are validated by the security team.
Privileged access rights must be assigned to a user ID different from those used for regular business activities and must not use the same secret authentication information. Regular business activities must not be performed from privileged ID.

Endpoints must be secured by security tools which allow protection against
malwares (e.g. antivirus, antispyware) with an EDR (Endpoint Detection and Response) mechanism.

All Endpoints provided by the entity must be enrolled in the cloud provider
management tool and properly managed.

SF 6.8. Software and hardware protection
Temporary data (system, swap, computer trash…) must be subject to regular and automatic cleaning for the endpoints which have no encryption functionality for those temporary data. Endpoints must be encrypted according to the data classification requirements. The entity responsible must supply all the necessary means to secure professional data according to their level of sensitivity (cryptography, strong authentication…)

Backup mechanisms ensuring availability of professional data must be
implemented on all endpoints supplied by IT Operations, and according to the data sensitivity.

Development and code security is handled by Github Security Advisories.

SF 6.9. usage rules
Users are responsible for the equipment they were assigned (There must be a perception signature). They must keep it secure in order to prevent risks of loss or theft, employing available means in their entity. All users must be aware of the secure use of the endpoint and on the use of the security tools. A specific procedure taking into account legal, and other security requirements of the organization must be established for cases of theft or loss of mobile endpoints.

SF 6.10. Privately owned devices
The use of privately-owned mobile devices is authorized by HR management. There must be a separation of private and business use of the endpoints, including using software to support such separation and protect business data on a private device. The not managed by the entity device must not have access to internal network.



SF 7. Security incidents management
SF 7.1. Risks
This document defines the security rules and requirements related to
Storyfox’s information security incident management. The implementation of these security rules aims to protect Storyfox’s information from the following threats:
Security events;
Security incidents;

SF 7.2. Purposes
In order to prevent these threats, this directive defines information security incident management rules to ensure planned, systematic and calm responses to information security incidents, thus minimizing the adverse impacts of Iincidents.
- detect, report and assess information security incidents;
- respond to information security incidents, including the activation of appropriate controls for the prevention and reduction of, and recovery from,
impacts (for example in the support of crisis management areas);
- report information security vulnerabilities not yet been exploited to
cause information security events and possibly information security
incidents, and assess and deal with them appropriately;
- learn from information security incidents and vulnerabilities, institute
preventive controls, and make improvements to the overall approach
to information security incident management.

SF 7.3. Management of security events
Key event logs must be activated, centralized and archived, then correlated
and analyzed on a dedicated infrastructure in order to enhance incident
detection. SOC use cases - condition or event (usually related to a specific threat) to be detected or reported by the security tool must be defined prior to a SOC deployment. For each defined use case, the minimum necessary security events to be collected must be described and the incident handling procedure must be documented.

All information collected from the Information System (such as security events, application logs or network traffic) must be documented. The information to be logged must be identified in accordance with local regulation.

The information collected must be centralized, and protected against any breaches of availability, integrity and confidentiality by technical and organizational measures (sealing,archiving ...).
Every Information System must collect and centralize security events and logs in a single Data Warehouse. Therefore, new systems must be selected regarding their login and reporting capabilities and must facilitate the data collection.

SF 7.4. Crisis management
An organization, process, procedures and tools must be defined to guide Cyber Crisis Management. After a decision agreed with CISO, the crisis management unit is triggered and the crisis management process is applied. When the Crisis Unit is initialized, and for the duration of the crisis, a crisis diary is kept up-to-date by a duly identified profile.
At the end of the crisis, a summary report must be provided, with preventive actions that must be identified and carried out to avoid the occurrence of a similar crisis. It must be shared to the CISO and Codir. The Crisis Unit provides internal communication on the crisis on a (minimum) daily basis. If necessary, the crisis team asks the communication department to manage external corporate communication. Organization, process and procedures must be tested, on an annual basis, during crisis exercises.

A review of major incidents must be carried out as part of the delivery service monitoring (during steering committee for example) and preventive actions must be identified and carried out to avoid the occurrence of incidents of the same type. This review must be done in each entity then at the company level, at least once a year. Any service contract signed with a supplier must include standard contractual clauses concerning:

- An obligation to report security incidents that may have an impact on the
company within 24 hours,

- An obligation to designate a specific point of contact for the incident
management and possible crisis.


SF 8. Cybersecurity
SF 8.1. Risks
The implementation of these security rules aims to protect Storyfox’s information from the following threats:
Cyber attacks,
Confidential data theft/Leak,
Saturation of Infrastructure.

SF 8.2. Purposes
In order to prevent these threats, this directive defines operation security rules to ensure correct and secure operations of information systems (IS).

SF 8.3. vulnerability and patch management
Each IS asset (hardware, software ...) must be inventoried on a regular basis (at least monthly). Each IS asset must be subject to a vulnerability monitoring that informs administrators as soon as possible whenever a new threat may impact the IS.
Each employee must address the applicable vulnerabilities to its IS, and assign the following priority levels according to their criticality: critical, urgent, standard. The criteria for the evaluation of the priority levels shall be as follows: the level of intrinsic CVSS criticality, the exposure level of the affected component, the criticality of the business supported by this component.

Critical vulnerabilities must be monitored and documented. Any management of a critical vulnerability must be the subject to a formalized feed-back. Each entity must establish a list of monitored critical vulnerabilities, including the list of affected components. To that end, specific tools such as a vulnerability scanner may be used and the information could be consolidated into a database. At the minimum, one up-to-date Excel file must be set. A vulnerability correction process must be  ormalized to take into account the different components to handle, within the following timeframe objectives:
▪ 15 days for critical vulnerabilities,
▪ 45 days for urgent vulnerabilities,
▪ Standard vulnerabilities must be processed at the latest as part of the
upgrades or renewal of the IS components. If business requirements apply,
these vulnerabilities must be handled in accordance with these requirements. OS-1.4.3 The vulnerability handling process must include an exception process to address cases that do not meet the timeframe objectives (e.g. obsolete systems, systems that can only be updated in specific maintenance...).

All of these exceptions for critical or urgent vulnerabilities must be recorded
and documented. An action plan must be defined and propose for instance
the following preventive measures:
▪ The system separation in a confined and isolated area from other systems,
or even a complete disconnection from the company network.
▪ The establishment of an advanced network monitoring the traffic exchanged with this component as well as event logs generated on it.
▪ Hardening of the configuration component to reduce its exposure surface to attacks.

Each entity must implement technical reporting to measure the monitoring and patching effectiveness for no less than the perimeter including workstations and components exposed on the Internet. The different indicators that have to be provided are left to the hand of each entity and clients according to their relevance in measuring the process effectiveness. Some indicators must be provided under recurring automatic or manual controls.

SF 8.4. backup management
Backup operations must be performed in accordance with specific backup
plans. The various backup operations must be monitored. Any malfunctions with execution of these operations must be traceable. In case of recurring malfunctions (e.g. failure of two successive backups), an incident must be recorded and an action plan must be formalized to deal with it.
Traceability backup operations must be ensured. The duration history is to be defined in coherence with the backup strategy and / or the backup plans.

Backups must be protected by the security measures defined in the overall
backup strategy or in the specific backup plans (e.g. backup encryption
outsourcing of physical media ...).

The backup system can also be used for archiving data. In this case, it must
be ensured that the archiving needs have been identified with the business,
and that the implemented backup system meet these needs:
▪ Retention period of archived data (which can be very long)
▪ Ability to read data after the system end of life
▪ Compliance with legal and regulatory obligations for some archives
(timestamp, integrity, non-repudiation ...).

Backup management is handled by our Cloud provider.

SF 8.5. administration management
Access to production environments for their administration must be done
through a unified rebound gateway that guarantees at least the following
security features:
▪ Centralized access management
▪ Filtering administration flows
▪ Traceability administrative operations at least for console connections
It is recommended to apply this rule for access to other environments
(development, pre-production ...).

Access to the production environments of components classified as critical is
done through an administration bastion to add the following security functions:
▪ Full traceability of administration operations regardless of the connection
mode (command mode, access via virtual office ...)
▪ Reinforcement of the administrative actions control (e.g. blocking of certain
modification rights).
▪ Password safe allowing no direct use of the component passwords for those in production.
▪ It is recommended to deploy, in addition to the bastion, the virtual desktops (e.g. VDI) associated with each administrator profile to ensure better control of the administrator position. Cloud environment administration.

Access to the administration interfaces of deployed environments in the Cloud must respect at least the following rules:
▪ Systematic strong authentication (MFA)
▪ Activation of the highest level of traceability of administration operations and export of traces to an external centralization system
▪ Monitoring reinforcement of these accesses (e.g. sending an alert message
when a new administrator account is created, when a new client station
connects...)
▪ Filtering where possible IP addresses allowed to connect to the administration interface.


SF 9. Disaster Recovery Plan
SF 9.1. Availability and resiliency
Storyfox has designed redundant systems to keep its services running even if some parts of underlying infrastructure experience issues. Storyfox services are configured in such a manner so as to withstand long-term outages to individual servers and availability zones. Using AWS infrastructure, all data in Storyfox is replicated in multiple geographic regions to ensure a high level of durability in the case of a disaster.

SF 9.2. Disaster recovery
Storyfox targets a Data Recovery Point Objective (RPO) of 3 hours for at
least 7 days, and up to 24 hours beyond 7 days. Due to the distributed nature
of Storyfox services, RTO for systemic disasters involving data recovery is targeted at 8 hours.

SF 9.3. Notification and communication
Storyfox has established internal communications using industry standard
security protocols so that our employees and management will be notified
instantly during any emergency event, or when any data recovery plan is
initiated or deactivated.


SF 10. Network architecture