Factonomy Resilience™ Enterprise Business Continuity . S ervice Definition Section : Terms and conditions explained. Page 1. Overview of our software solution
Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.
Overview of our software solution
Details of this service definition applicable to G2.111.002 - Factonomy BCM & Disaster Recovery are explained in the document. This is a SAAS solution for collecting metrics (known as a Business Impact Analysis) online in wizard style forms , maintaining BCM plans and other associated BCM and ITDR details such as tests and exercises. More details on the functionality can be found on the following pages.
Configuring Factonomy Resilience
The entire interface for making all configuration changes is web based including a dedicated menu for U.I. screen’s and API configuration. These menu’s are not aimed at novice users and will require a certain level of product training. Equally certain configurations can be achieved through interfaces and menu’s by Administrators with business analyst skills.
Out of the box support
Factonomy Resilience is designed to support end to end business continuity and IT DR in organizations with either an existing mature combined BCM and ITDR programme in place or who are looking to develop this capability. This SAAS cloud offering does not contain any subject matter expert support in either BCM or IT DR. Organizations purchasing the solution should have a capable internal BCM Manager or retained BCM Consultant to take advantage of the solution.
This solution aligns and is compatible with many leading management systems for BCM including BS2599-2 and ISO22301 the new leading BCM standard. However the establishment of any management system requires organizational specific culture changes and policy development challenges that must be led by suitable subject matter experts. Factonomy Resilience is not a replacement for those experts.
Unit Pricing Model – End Users
We are offering the solution with a SAAS price of 150 per user per month. This category of user would include anyone who needs to make any form of editing change inside the solution and will need to be supplied with a username and password. This access level is unique and we will track the number of logins against the licenses sold. Each End User could be one of three possible roles –
Business Continuity Co-ordinator
Divisional Continuity Co-ordinator
New roles can be developed inside the solution by those with adequate training or new roles can be created as part of the implementation process.
Unit Pricing Model – AdministratorsTypical implementations will require 1-2 Administrator who oversee the operation of the solution , create and manage environments for other users including building templates and template sections for ‘End Users ‘ to complete. The numbers of administrators will vary but anyone requiring this deep level of access with privileges to make deep changes will be expected to purchase the required number of Administrator licenses. These are offered at 250 per month per user.
Implementation and configuration
The typical implementation of the solution will reflect some of the organizations own nomenclature , terminology and methodology. In many cases this may involve simple field name label changes that can be completed through the interface after appropriate training. We would expect the typical organization purchasing Factonomy SAAS to purchase 10 days of training and configuration. This is priced at 10K GBP.
2 x Days Discovery (On site documenting areas requiring configuration)
3 x Days Factonomy Configuration (off site Configuration of identified areas by Factonomy)
5 x Days Train the trainer
Equally if deeper changes are required a more formal implementation Statement of Works may need to be developed. Users acquiring the service are welcome to explore the ‘standard’ environment and then determine what changes are required. Our rates are a flat fee of 1200 GBP per day.
Our preferred Training Model is ‘Train the Trainer’. Working with the BCM and IT DR core team to empower them to enable them to configure the solution and explain it’s functions to ‘End Users’.
Using off site remote desktop tools where possible or on site visits with chargeable expenses.
Organizations opting for the recommended 10K configuration package will get 5 days of train the trainer.
On-boarding of data
For organizations wishing to integrate with their own datasources we have developed a migration transfer harness. This tool allows for field mappings to be established between source fields and the field in our solution. Typical integrations will see on boarding of the following categories:
Contact or Staff details from a HRMS system (or equivalent)
IT Systems and or Asset details from sources like ConfigDB
Larger Organizations may require:
Locations and Buildings (for larger organizations with multiple buildings and sites)
Seats and Recovery site resources
Smaller organizations who do not have data sources to integrate from can manually enter this data through the interface.
Compatible File formats include .csv and xls and XML. Transfer is completed through secure FTP. These transfers can be batched and performed at set frequencies (monthly/ weekly/ daily/ As required).
Documenting and Developing API’s
Due to our unique architecture any screen or form in the screen can support scripting to API’s. The schema for editing API’s share the same approach as deep UI configuration changes. Both can be completed under ‘Screens and API’ in the browser itself with no third party software and no requirement to interrupt the solution itself. Other users can continue to access the solution even while deep editing changes are made.
SAAS cloud deployment
By default we will offer hosting through Microsoft Azure on the cloud network. Typically hosting will be based out of the node in Ireland (IRE) with failover support provide by the hosting node in Netherlands.
Organizations requiring a greater level of Resiliency can engage with us using our Statement of Works with the potential to exploit multiple nodes across the Windows Azure platform
Backup and Recovery
North Europe - Dublin, Ireland - Primary
West Europe - Amsterdam, Netherlands – Backup
Factonomy is not currently accredited, but we plan to undergo accreditation for core features as part of the UK Government's G-Cloud Pan Government Accreditation process with an initial target of IL2 for Confidentiality and Integrity.
Factonomy has implemented an Information Security management system that aligns to many of the leading standards including ISO27001.
In addition to the policies training , and on going management review processes the following technical mitigations are in place.
Sensitive client data is segmented and cannot be routinely viewed by Factonomy unless expressly requested by client as part of an issue.
Typical implements see clients supported blind with no access to their sensitive data and using record generating tools to create anonymous equivalent records with a similar structure
Any access to the solution is through secure VDI using encryption
Our DR capabilities will rely on the recovery of your hosted solution through Azure. Internally should an incident of any kind interrupt our normal working arrangements at our main Edinburgh office then we would use a remote recovery strategy. However any impact to our main Edinburgh would not affect the hosting of the solution using the Azure network in any material way. The Technical repository uses SVN and is hosted in our secure VDI network with backup across multiple locations using a cloud service. Loss of our main Edinburgh site will not affect this technical repository .All changes are logged through SVN before being committed to the database and developers can simply login from another location and continue ‘committing’ fixes and issues in a seamless process from the client side.
The below is from the MS Azure DR geo-failover document available publically.
Disaster recovery capabilities for Azure Storage (blobs, tables, queues) are provided through Windows Azure Geo-replication. With Geo replication after the initial commit of the transaction, the primary location asynchronously replicates the recently committed transaction to the secondary location. That transaction is then made durable by fully replicating it across three different storage nodes in different fault and upgrade domains at the secondary location.
Our goal is to keep the data durable at both the primary and secondary location. This means we keep enough replicas in both locations to ensure that each location can recover by itself from common failures (e.g., disk, node, rack, TOR switch failing, etc), without having to talk to the other location. The two locations only have to talk to each other to geo-replicate the recent updates to storage accounts. They do
not have to talk to each other to recover data due to common failures. This is important, because it means that if we had to failover a storage account from the primary to the secondary, then all the data that had been committed to the secondary location via geo-replication will already be durable there.
With this first release of geo-replication, we do not provide an SLA for how long it will take to asynchronously geo-replicate the data, though transactions are typically geo-replicated within a few minutes after they have been committed in the primary location.
In the event of a major disaster that affects the primary location, we will first try to restore the primary location. Dependent upon the nature of the disaster and its impacts, in some rare occasions, we may not be able to restore the primary location, and we would need to perform a geo-failover. When this happens, affected customers will be notified via their subscription contact information (we are investigating more programmatic ways to perform this notification). As part of the failover, the customer’s “account.service.core.windows.net” DNS entry would be updated to point from the primary location to the secondary location. Once this DNS change is propagated, the existing Blob and Table URIs will work. This means that you do not need to change your application’s URIs – all existing URIs will work the same before and after a geo-failover.
Off Boarding / Extraction of client data
All clients will be provided a full extraction of all client data upon written confirmation that they wish to cease using the service. Formats for extraction include XLS , CSV and SQL. Clients should communicate their preferences. No charge is made. Downloads can be made from FTP sites or data supplied on DVD’s via post. The efficiency of the database is such that even long running client databases will only contain can be between 1-4 GB of data.