Lesson 11 A Implement Best Practice Documentation

Question 1

A standard operating procedure (SOP)

Answer 1

Employees must understand how to use computers and networked services securely and safely and be aware of their responsibilities. To support this, the organization needs to create written policies and procedures to help staff understand and fulfill their tasks and follow best practice:

• A policy is an overall statement of intent.
• A standard operating procedure (SOP) is a step-by-step list of the actions that must be completed for any given task to comply with policy. Most IT procedures should be governed by SOPs.
• Guidelines are for areas of policy where there are no procedures, either because the situation has not been fully assessed or because the decision-making process is too complex and subject to variables to be able to capture it in a SOP. Guidelines may also describe circumstances where it is appropriate to deviate from a specified procedure.

Question 2

Typical examples of SOPs are as follows:

Answer 2

• Procedures for custom installation of software packages, such as verifying system requirements, validating download/installation source, confirming license validity, adding the software to change control/monitoring processes, and developing support/training documentation.
• New-user setup checklist as part of the onboarding process for new employees and employees changing job roles. Typical tasks include identification/enrollment with secure credentials, allocation of devices, and allocation of permissions/assignment to security groups.
• End-user termination checklist as part of the offboarding process for employees who are retiring, changing job roles, or have been fired. Typical tasks include returning and sanitizing devices, releasing software licenses, and disabling account permissions/access.

Question 3

ticketing system

Answer 3

A ticketing system manages requests, incidents, and problems. Ticketing systems can be used to support both internal end-users and external customers.

Question 4

The general process of ticket management is as follows:

Answer 4

1. A user contacts the help desk, perhaps by phone or email or directly via the ticketing system. A unique job ticket ID is generated, and an agent is assigned to the ticket. The ticket will also need to capture some basic details:
   - User information—The user’s name, contact details, and other relevant information such as department or job role. It might be possible to link the ticket to an employee database or customer relationship management (CRM) database.
   - Device information—If relevant, the ticket should record information about the user’s device. It might be possible to link to the relevant inventory record via a service tag or asset ID.
2. The user supplies a description of the issue. The agent might ask clarifying questions to ensure an accurate initial description.
3. The agent categorizes the support case, assesses how urgent it is, and determines how long it will take to fix.
4. The agent may take the user through initial troubleshooting steps. If these do not work, the ticket may be escalated to deskside support or a senior technician.

Question 5

Categories

Answer 5

Categories and subcategories group related tickets together. This is useful for assigning tickets to the relevant support section or technician and for reporting and analysis.

Service management standards distinguish between the following basic ticket types:

• Requests are for provisioning things that the IT department has a SOP for, such as setting up new user accounts, purchasing new hardware or software, deploying a web server, and so on. Complex requests that aren’t covered by existing procedures are better treated as projects rather than handled via the ticketing system.
• Incidents are related to any errors or unexpected situations faced by end-users or customers. Incidents may be further categorized by severity (impact and urgency), such as minor, major, and critical.
• Problems are causes of incidents and will probably require analysis and service reconfiguration to solve. This type of ticket is likely to be generated internally when the help desk starts to receive many incidents of the same type.

Using these types as top-level categories for an end-user facing system is not always practical, however. End-users are not likely to know how to distinguish incidents from problems, for example. Devising categories that are narrow enough to be useful but not so numerous as to be confusing or to slow down the whole ticketing process is a challenging task.

One strategy is for a few simple, top-level categories that end-users can self-select, such as New Device Request, New App Request, Employee Onboarding, Employee Offboarding, Help/Support, and Security Incident. Then, when assigned to the ticket, the support technician can select from a longer list of additional categories and subcategories to help group related tickets for reporting and analysis purposes. Alternatively, or to supplement categories, the system might support adding standard keyword tags to each ticket. A keyword system is more flexible but does depend on each technician tagging the ticket appropriately.

Question 6

TICKET MANAGEMENT

Answer 6

After opening an incident or problem ticket, the troubleshooting process is applied until the issue is resolved. At each stage, the system must track the ownership of the ticket (who is dealing with it) and its status (what has been done).

This process requires clear written communication and might involve tracking through different escalation routes.

Question 6

Severity

Answer 6

A severity level is a way of classifying tickets into a priority order. As with categories, these should not be overcomplex. For example, three severity levels based on impact might be considered sufficient:

• Critical incidents have a widespread effect on customers or involve potential or actual data breach.
• Major incidents affect a limited group of customers or involve a suspected security violation.
• Minor incidents are not having a significant effect on customer groups.

More discrete levels may be required if the system must prioritize hundreds or thousands of minor incidents per week. A more sophisticated system that measures both impact and urgency might be required. Severity levels can also drive a notification system to make senior technicians and managers immediately aware of major and critical incidents as they arise.

Question 7

Escalation

Answer 7

Escalation occurs when an agent cannot resolve the ticket. Some of the many reasons for escalation include:

• The incident is related to a problem and requires analysis by senior technicians or by a third-party/warranty support service.
• The incident severity needs to be escalated from minor to major or major to critical and now needs the involvement of senior decision-makers.
• The incident needs the involvement of sales or marketing to deal with service complaints or refund requests.

The support team can be organized into tiers to clarify escalation levels. For example:

• Tier 0 presents self-service options for the customer to try to resolve an incident via advice from a knowledge base or “help bot.”
• Tier 1 connects the customer to an agent for initial diagnosis and possible incident resolution.
• Tier 2 allows the agent to escalate the ticket to senior technicians (Tier 2 – Internal) or to a third-party support group (Tier 2 – External).
• Tier 3 escalates the ticket as a problem to a development/engineer team or to senior managers and decision-makers.

The ticket owner is the person responsible for managing the ticket. When escalating, ownership might be re-assigned or not. Whatever system is used, it is critical to identify the current owner. The owner must ensure that the ticket is progressed to meet any deadlines and that the ticket requester is kept informed of status.

Question 8

Clear Written Communication

Answer 8

Free-form text fields allow ticket requesters and agents to add descriptive information. There are normally three fields to reflect the ticket life cycle:

• Problem description records the initial request with any detail that could easily be collected at the time.
• Progress notes record what diagnostic tools and processes have discovered and the identification and confirmation of a probable cause.
• Problem resolution sets out the plan of action and documents the successful implementation and testing of that plan and full system functionality. It should also record end-user or customer acceptance that the ticket can be closed.

At any point in the ticket life cycle, other agents, technicians, or managers may need to decide something or continue a troubleshooting process using just the information in the ticket. Tickets are likely to be reviewed and analyzed. It is also possible that tickets will be forwarded to customers as a record of the jobs performed. Consequently, it is important to use clear and concise written communication to complete description and progress fields, with due regard for spelling, grammar, and style.

• Clear means using plain language rather than jargon.
• Concise means using as few words as possible in short sentences. State the minimum of fact and action required to describe the issue or process.

Question 9

Incident Reports

Answer 9

For critical and major incidents, it may be appropriate to develop a more in-depth incident report, also referred to as an after-action report (AAR) or as lessons learned. An incident report solicits the opinions of users/customers, technicians, managers, and stakeholders with some business or ownership interest in the problem being investigated. The purpose of an incident report is to identify underlying causes and recommend remediation steps or preventive measures to mitigate the risk of a repeat of the issue.

Question 10

Asset management uses a catalog

Answer 10

of hardware and software to implement life-cycle policies and procedures for provisioning, maintaining, and decommissioning all the systems that underpin IT services.

It is crucial for an organization to have an inventory list of its tangible and intangible assets and resources. The tangible inventory should include all hardware that is currently deployed as well as spare systems and components kept on hand in case of component or system failure. The intangible asset inventory includes software licenses and data assets, such as intellectual property (IP).

Question 11

asset-management database system

Answer 11

There are many software solutions available for tracking and managing inventory. An asset-management database system can be configured to store details such as type, model, serial number, asset ID, location, user(s), value, and service information. An inventory management suite can scan the network and use queries to retrieve hardware and software configuration and monitoring data.

Question 12

Asset Tags and IDs

Answer 12

For an inventory database to work, each instance of an asset type must be defined as a record with a unique ID. The physical hardware device must be tagged with this ID so that it can be identified in the field. An asset tag can be affixed to a device as a barcode label or radio frequency ID (RFID) sticker. Barcodes allow for simpler scanning than numeric-only IDs. An RFID tag is a chip programmed with asset data. When in range of a scanner, the chip powers up and signals the scanner. The scanner alerts management software to update the device’s location. As well as asset tracking, this allows the management software to track the location of the device, making theft more difficult.

Question 13

Network Topology Diagrams

Answer 13

A diagram is the best way to show how assets are used in combination to deliver a service. In particular, a network topology diagram shows how assets are linked as nodes. A topology diagram can be used to model physical and logical relationships at different levels of scale and detail.

In terms of the physical network topology, a schematic diagram shows the cabling layout between hosts, wall ports, patch panels, and switch/router ports. Schematics can also be used to represent the logical structure of the network in terms of security zones, virtual LANs (VLANs), and Internet Protocol (IP) subnets.
Schematics can either be drawn manually by using a tool such as Microsoft Visio or compiled automatically from network mapping software.

Question 14

ASSET DOCUMENTATION

Answer 14

An asset procurement life cycle identifies discrete stages in the use of hardware and software:

• Change procedures approve a request for a new or upgraded asset, taking account of impacts to business, operation, network, and existing devices.
• Procurement determines a budget and identifies a trusted supplier or vendor for the asset.
• Deployment implements a procedure for installing the asset in a secure configuration.
• Maintenance implements a procedure for monitoring and supporting the use of the asset.
• Disposal implements a procedure for sanitizing any data remnants that might be stored on the asset before reusing, selling, donating, recycling, or destroying the asset.

Question 15

Warranty and Licensing

Answer 15

Each asset record should include appropriate procurement documentation, such as the invoice and warranty/support contract (along with appropriate contact information). For software, it should record the licensing details with device/user allocations and limits.

Question 16

Assigned Users

Answer 16

Hardware assets such as workstations, laptops, smartphones, tablets, and software licenses might be assigned to individual user accounts. Alternatively, assets might be allocated to security groups representing business departments or job roles. Shared-use assets, such as servers, routers, switches, and access points, might be allocated to individual technicians or security groups for management responsibility. This is better practice than sharing default administrator accounts.

Question 17

knowledge base (KB)

Answer 17

A knowledge base (KB) is a repository for articles that answer frequently asked questions (FAQs) and document common or significant troubleshooting scenarios and examples. Each inventory record could be tagged with a cross-reference to an internal knowledge base to implement self-service support and to assist technicians.

An asset notes field could be used to link to external knowledge base articles, blog posts, and forum posts that are relevant to support. Be sure to take into consideration who wrote the article and any verifiable credentials so you can determine the legitimacy of the article content.

Question 18

Change management

Answer 18

Change management refers to policies and procedures that reduce the risk of configuration changes causing service downtime. Change management is closely related to configuration management.

Question 19

IT Infrastructure Library (ITIL)

Answer 19

IT Infrastructure Library (ITIL) is a popular documentation of good and best practice activities and processes for delivering IT services. Under ITIL, configuration management is implemented using the following elements:

• Service assets are things, processes, or people who contribute to the delivery of an IT service.
• A configuration item (CI) is an asset that requires specific management procedures for it to be used to deliver the service.
• Configuration baselines are the settings that should be applied to the CI to ensure secure and reliable operation.
• Performance baselines are metrics for expected performance to provide a basis for comparison for ongoing monitoring of a CI.

The main difficulty in implementing a workable configuration management system is in determining the level of detail that must be preserved. This is not only evident in capturing the asset database and configuration baseline in the first place, but also in managing moves, adds, and changes (MACs) within the organization’s computing infrastructure.

Question 20

Change Requests

Answer 20

A change request is generated when a fault needs to be fixed, new business needs or processes are identified, or there is room for improvement in an existing SOP or system. The need to change is often described either as reactive, where the change is forced on the organization, or as proactive, where the need for change is anticipated and initiated internally.

In a formal change-management process, the need or reasons for change and the procedure for implementing the change are captured in a request-for-change (RFC) form and submitted for approval.

Question 21

Change-request documentation should include:

Answer 21

• Purpose of the change—This is the business case for making the change and the benefits that will accrue. It might include an analysis of risks associated with performing the change and risks that might be incurred through not performing the requested change.
• Scope of the change—This is the number of devices, users, or customers that will be affected by the change. Scope can also include costs and timescales. For a complex project, it might include sub-tasks and stakeholders. Scope should also include the factors by which the success or failure of the change can be judged.

Question 22

CHANGE APPROVAL

Answer 22

When a change request has been drafted and submitted, it must go through an approval process.

Question 23

Change Board Approvals

Answer 23

If the change is normal or minor, approval might be granted by a supervisor or department manager. Major changes are more likely to be managed as a dedicated project and require approval through a Change Advisory Board (CAB). The role of the CAB is to assess both the business case and the technical merits and risks of the change plan. The CAB should include stakeholders for departments, users, or customers who will be impacted by the change as well as those proposing it, technicians who will be responsible for implementing it, and managers/directors who can authorize the budget.

Question 24

Risk Analysis

Answer 24

For the CAB to approve a change, it must be confident that risk analysis has identified both things that could go wrong and positive enhancements (or mitigation of negative effects) that will be made from completing the change. Risk analysis is a complex and demanding skill, but in simple terms it involves two types of approach:

• Quantitative risk analysis calculates discrete values for the impact and likelihood of each factor affecting the change proposal.
• Qualitative risk analysis seeks to identify and evaluate impact and likelihood factors through previous experience and informed opinion to replace or supplement metrics.

The outcome of risk analysis is the assignment of some risk level to the change request. This could be expressed as a discrete value or as a traffic light–type of indicator, where red is high risk, orange is moderate risk, and green is minimal risk. If the change is approved despite a high level of risk, stakeholders must be informed of these risks so that they can anticipate and react to them appropriately as the change implementation project proceeds.

Question 25

Test and Implement the Change Plan

Answer 25

When a change is approved, a responsible staff member is appointed to manage implementation of the change.

The implementation of change must be carefully planned, with consideration of the impact on affected systems. For most significant or major changes, organizations should attempt to test the change first. This might involve sandbox testing in a computing environment designed to replicate the production environment but isolated from it.

The change implementation in the production system should be scheduled at an appropriate date and time to minimize risks of system downtime or other negative impact on the workflow of the business units that depends on the IT system being modified. Most organizations have a scheduled maintenance window period for authorized downtime. Stakeholders should be notified in advance if there is risk of downtime.

Every change should be accompanied by a rollback plan so that the change can be reversed if it has harmful or unforeseen consequences.

Question 26

End-user Acceptance

Answer 26

As well as the technical implementation, the change plan must account for end-user acceptance. It can be difficult for people to adapt to new processes and easy for them to magnify minor problems into major complaints of the “It worked before” kind. There are three principal strategies for mitigating these risks:

• Change requests should be considered by stakeholders on the change board who represent end-user and/or customer interests.
• A project that will have significant impact should incorporate user-acceptance testing (UAT) to allow end-users to work with the updated system and suggest improvements before release.
• Training and education resources must be available before the change is initiated. The support team must be ready to deal with incidents arising from the change as a priority.

Question 27

acceptable use policy (AUP)

Answer 27

An acceptable use policy (AUP) sets out what someone is allowed to use a particular service or resource for. Such a policy might be used in different contexts. For example, an AUP could be enforced by a business to govern how employees use equipment and services such as telephone or Internet access provided to them at work. Another example might be an ISP enforcing a fair use policy governing usage of its Internet access services.

Question 28

Enforcing an AUP is

Answer 28

important to protect the organization from the security and legal implications of employees (or customers) misusing its equipment. Typically, the policy will forbid the use of equipment to defraud, defame, or to obtain illegal material. It is also likely to prohibit the installation of unauthorized hardware or software and to explicitly forbid actual or attempted intrusion (snooping). An organization’s acceptable use policy may forbid use of Internet tools outside of work-related duties or restrict such use to break times.

Further to AUPs, it may be necessary to implement regulatory compliance requirements as logical controls or notices. For example, a splash screen might be configured to show at login to remind users of data handling requirements or other regulated use of a workstation or network app.