Service Continuity Management

Continuity or disaster recovery plan records can be created to record the following information: examples of common plan information can include, but are not limited to:

On the platform, the continuity process is available divided into four large stages with 3 sub-stages.

Stages: Initiation, Requirements and Strategy, Implementation and Continuous Operation.

In each sub step, fields and links are available to identify each of the plans, actors, processes and criteria.

In the Initiation part, we have: The policy, scope and project, where we find the linked resources and processes, such as change, for example.

In the area of requirements and Strategy we find: Visual Functions, BIA (Business Impact Analysis) Risk Assessment and IT Continuity Strategy.

In the Implementation substages: Continuity menu there are Plan and its relationships, Organizational Planning and Testing Strategy.

Finally, in Continuous Operation, we find all the operation menus and relationships such as: Awareness, Review and Audit, Tests, Continuity Plan Invocation, Problem, Change and Release.

______________________________________________________________________________________________

The continuity or disaster recovery plan records can be linked to other records within the toolset, or reference other critical information. This must include, at a minimum:

·        Service and component records

·        Business functions or processes supported by the service(s)

·        Related external continuity or disaster recovery plan documents

·        Service agreements and internal support agreements

·        Related knowledge articles

·        Related external procedure documentation

In the area of requirements and Strategy we find: Visual Functions, BIA (Business Impact Analysis) Risk Assessment and IT Continuity Strategy.

______________________________________________________________________________________________

Resources required to test plans, respond to, participate in, or manage continuity situations can be identified and documented. This should include contact information, as well as their availability which may be obtained through integration or using information from resource management capability or tools

In the Implementation menu there are substages: Continuity Plan and its relationships, Organizational Planning and Testing Strategy, there are a placeholder for manage all continuity plan.

______________________________________________________________________________________________

Continuity plan records can be associated with and supported by the workflow management capability to support the review and testing of plans. The workflows can be systematically triggered by certain thresholds or criteria. Examples of this can include but are not limited to:

Yes, on Implementation Continuity Plan all Review Plan, Tests, Changes Related etc.

______________________________________________________________________________________________

The invocation of continuity or disaster recovery plans can be systematically triggered, along with associated workflows; examples of conditions or thresholds that could trigger plan invocation can include, but are not limited to:

·        Outages to related components or services from monitoring and alerting

·        Performance thresholds on related components or services from monitoring and alerting

·        The status or elapsed time of incidents logged against specific components or services that are active beyond a predefined time threshold

Based on Incident/Continuity Criteria the platform trigger continuity plans

______________________________________________________________________________________________

Continuity levels or tiers for service and component records that underpin vital or critical business functions, as well as continuity thresholds for outages and performance, can be identified and documented.

When these service/component records are linked to an incident, this information and thresholds can be used to trigger the invocation of a continuity or disaster recovery plan.

Customer can define the components or vital/critical business functions for trigger continuity plans and document all on Knowledge Bases.

______________________________________________________________________________________________

Notifications to responsible stakeholders and participants, including vendor personnel, for plan review and testing, as well as for responses to the invocation of plans, can be triggered systematically.

All continuity plans triggered send notifications for all responsible and stakeholders.

______________________________________________________________________________________________

Information and procedures needed to manage and communicate logistics (travel and transportation, lodging, meals, etc.) for tests and the invocation of plans can be identified and documented.

Yes, it does. All Information and procedures needed to manage and communicate logistics can be documented on Knowledge Base and linked with all process

______________________________________________________________________________________________

Service performance metrics related to recovery times, minimal service levels, and restoration times can be identified for each plan as well as the ability to report this performance against service targets in the continuity plan or related service agreements.

On Continuity plan recovery times, minimal service levels, and restoration times can be identified for each plan as well as the ability to report.

______________________________________________________________________________________________

Testing requirements for each plan can be identified, including the frequency and dates, the results of the tests, and resulting action items and improvements.

In Continuity Operations, Test Tab there are a calendar where testing requirements for each plan can be identified, including the frequency and dates, the results of the tests, and resulting action items and improvements.

______________________________________________________________________________________________

Changes can be requested and linked to the plan record, to plan, authorize and control changes to the plans.

On implementation tab, Continuity plan the plan can be linked with change for control all change to the plans.

______________________________________________________________________________________________

Cost elements can be identified and tracked related to managing continuity or disaster recovery plans (review and testing) and to provide this information to financial management.

In the Platform, Continuity process, Requirements and Strategy Tab, there are a Business Impact Analysis and all Cost elements can be identified and tracked related to managing continuity or disaster recovery plans (review and testing) and to provide this information to financial management.

______________________________________________________________________________________________

Cost elements can be identified and tracked related to the invocation and management of live plans (actual continuity situations) and provide this information to financial management.

Yes, using Dashboards customer can track continuity plans and track related invocations, also can link continuity plan invoked linking on Apportionment Tab Tasks

______________________________________________________________________________________________

Supports analysis of business impact and risk assessments of proposed service changes and service failure or degradation

On risk assessment tab customer can analyze business impact and risk