Operational Procedures and Responsibilities

FreshDesk Support

ThingLogix uses the Freshdesk platform to manage support for customers, issues raised by security reviews, operational problems reported, and emergency issues related to the Foundry platform. Tickets are assigned to internal personnel for responses/follow-up, and customers can also be included for customer follow-up and tasks related to support tickets. The COO is responsible for assigning tickets and ensuring tickets are tracked to a status of Resolved or Closed.

Types of tickets include:

• Foundry Account Setup - routed to team members who can setup a new Foundry account for a customer in the customer's AWS account.
• Feature Request - if a customer requests a feature request, it is routed to the owner of that account to discuss for a future proposal or statement of work.
• Pre Sales Request - this is primarily used to do pre-sales work related to Demo's of Foundry, et al. These are being phased out and replaced with a Trello demo board for tracking purposes.
• Question - these are usually customer questions about functionality, features, or operating procedures. These are routed to support personnel for follow up, or account manager's for follow-up with the customer.
• Incident - these are customer reported incidents where urgent follow up is necessary. These are routed to support personnel or account management as appropriate.
• Problem - these are customer reported problems in their production environment. If the customer is under support contract, this is routed to a support person for follow-up. If the customer is not under support contract, this is given to the account manager to see if the customer wants a new statement of work.
• Lead - this is no longer utilized and has been replaced with automated web leads coming from the website into a dedicated mail account.
• Change - this is a customer requested change to something in their production environment. This is routed to the account manager to verify the change, and authorize it, before being routed to a support person for action.

Ticket status is as follows:

• Open - this is the initial default status when the ticket is entered.
• Pending - a support person can change this to Pending once it is assigned to them and they are working on it.
• Resolved - this means the ticket has been resolved and no further work is necessary on the ticket.
• Closed - this is primarily used to close tickets that do not need to be resolved such as support tickets from customers without annual support plans, or automated tickets opened by applications that generate notifications of volume of work such as customer Azevedo.
• Waiting on Customer - a support or account manager may assign this status if they have to ask the customer for further feedback, or have the customer take action, based on the potential resolution of the ticket.
• Waiting on Third Party - a support or account manager may assign this status if there is a third party vendor involved with the customer, such as hardware provider or firmware provider, and that third party needs to take action to resolve the ticket.

Change Management

Changes to operational systems will be agreed between the system users, business management, system owner and administrators and, if applicable, IT Service Providers.

Change Management Process:

https://www.lucidchart.com/documents/edit/7345e2e2-a618-426d-9d87-305f7b3185ba/0

Refer to process diagram:

https://sites.google.com/s/1d5iN8wUBI1X7cygCHrAKVphc5BDAV--u/p/1x6Qk585TsBfEk08KjGXyiKL77n1RsClz/edit

In emergency cases, to prevent system outages or recover a failed system, the emergency change procedure will be followed.

An emergency change as "A change that must be introduced as soon as possible – for example, to resolve a major incident or implement a security patch." . The need to have an incident in order to initiate an emergency change is not mentioned in the definition of an emergency change.

Due to the nature of the Emergency Changes, it’s clear that there is no time to wait for a formal review or review meeting, nor is it possible to even attempt to organize an impromptu meeting. However, Emergency Changes should not be handled outside of Change Management (FreshDesk). The Emergency Change process should still retain a high level of authorization and control, but those processes can be looser than those for a normal change. The number of Emergency Changes should be kept to an absolute minimum, with every Emergency Change being reevaluated after implementation to determine whether it was actually an Emergency Change, and if not, how to prevent such changes from being processed as Emergency Changes in the future.

Segregation of Duties

All changes to and sensitive operations carried out will be subject to an authorization process. This is to reduce the likelihood of unauthorized or unintentional modification or misuse of information or information processing assets.

Separation of Development, Test, and Operational Facilities

Where different environments exist within the infrastructure, these should be segregated using either physical or logical control mechanisms to prevent unintentional or unauthorized access to live systems and the data they contain.

In software deployment, an environment is a set of AWS and application components deployed and executed. In very simple cases, such as prototyping, developing and immediately executing an application there may be a single environment, but in industrial use the development environment (where changes are originally made) and production environment (what end users use) are separated; often with several stages in between like QA / Staging.

A structured release management process allows phased deployment (rollout), testing, and rollback in case of problems. Separating operational environments from development and test activities reduces the risks of modifications to the operational system that could compromise the production system’s integrity or availability and therefore impact business operations.

Key Benefits of segregated environments

• Reduce risks of blocking business and software development
• Reduce risks of production data getting into the wrong hands or getting intermingled with test data or destroyed
• Ensure that parallel development, testing occurs in separate environments for better planning
• Ensure strict quality adherence is followed from Dev to Staging and to Production environment
• Robustness and certainty of one environment that has not changed (Production Environment

Secure Development Standards during SDLC or migrating from environment to environment

Angular Development - ThingLogix developers shall follow the standards set forth at https://angular.io/guide/security for securing all Angular code. Developers shall design their code to comply with these security standards and ensure these standards are applied and kept as code is migrated through the standard environments/tier documented below.

Release and Deployment Cycle

Release and Deployment Cycle