Essential Services¶

Scope: OIT
Type: Guideline
Version: 2025

Goal¶

To help teams running important services see which standards they need to meet, and ensure that they have the resources they need to do so.

Ownership¶

Direct questions to the Owner: Seth A. Roby email redacted

Resources to comply with this standard should be directed to the team’s Division Director.

Timeline & Enforcement¶

This document is purely informative. It does not impose any new requirements; all MUSTs in this document are already required by other standards, which are linked when mentioned. Those linked standards have their own timelines.

Exception Process¶

Use the exception processes in the appropriate linked standard.

Terminology¶

• An IT Resource is defined as per the UCOP IT Glossary (page 24): “A term that broadly describes IT infrastructure, software and/or hardware with computing and networking capability.”
• An IT Service is an IT Resource meant to provide a campus function
• An Essential Service is any IT Service that meets the criteria set out in the scope section of this document
• A Development Team is the group writing code that makes an IT Service work. Not all IT Services have a development team. Not all development teams work at UC; some are external Suppliers.
• An Operations Team is the group responsible for monitoring an IT Service. This team often deploys and hosts the service as well, unless the service is hosted by an external Supplier.
• The Service Record is an entry in the IT Resources Inventory that describes the IT Service
• The IT Resources Inventory is OIT’s shared list of IT Resources
• A service Depends On other services that are required for it to operate; these are its Dependencies. It can be said to be Dependent on those other services.
• The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119

Requirements¶

Scope¶

1. A service is deemed essential if it meets any of the following criteria:
   1. It is rated as Recovery Level 3+
   2. It is rated as Availability Level 4
   3. It is rated as both Availability Level 3+ and handles data rated Protection Level 3+
   4. It meets the definition of Critical IT Infrastructure (see page 13)
   5. It has three of more Dependent Services that rely on it
   6. It has been designated essential by OIT Leadership

Service Record¶

1. Essential services MUST have a complete Service Record, with more detail to come in an upcoming standard
   1. The record MUST be reviewed at least yearly
2. Essential services MUST include a “Responsible Party” in their Service Record
   1. This group SHOULD be the service’s Operations Team or Development Team
3. Essential services MUST include all Dependencies in their Service Record
   1. All Dependencies SHOULD have an Availability Level equal to or higher than the Essential service.
   2. If the Dependency’s Availability Level is lower, the Essential service MUST work to maintain operation even if the Dependency is offline.
4. Essential services MUST have a defined Recovery Level in its Service Record
   1. See IT Recovery for details and information

User Management¶

1. Essential services SHOULD use Single Sign On for authentication
   1. This requirement can be waived by a Director if the service is technologically incapable of doing so
2. Essential services MUST perform user audits per ISS §9 - Access Control

Accessibility¶

1. Essential services MUST comply with IMT-1300 - Information Technology Accessibility and meet the Accessibility Standard therein

Security¶

1. Essential services MUST have a designated Unit Information Security Lead and SHOULD direct security questions to them
2. Documentation
   1. Essential services provided by external suppliers MUST do a Supplier Security Review
   2. Essential services that deal with data of Protection Level 3 or higher MUST have an entry in the Protected Data & Systems Inventory
   3. Essential services that deal with data of Protection Level 3 or higher MUST complete the Risk Assessment process
   4. This must be updated at least every two years
3. Compliance
   1. Essential services MUST comply with UCI’s ISS
   2. Essential services MUST comply with UCOP’s IS-3
   3. Essential services that are subject to external compliance requirements (such as FERPA, PCI, HIPAA, CJIS, etc) MUST comply with those policies
4. Any security incidents with an essential service must be reported to Security

Operations¶

1. Essential services MUST follow the backup and recovery policies found in ISS § 12.5
2. Essential services MUST meet baseline logging requirements
   1. They MUST also follow ISS §12.7 - Logging
3. Essential services MUST have tooling to verify their Availability Level
   1. This tooling SHOULD notify the Operations Team in case of downtime
4. Essential services MAY benefit from Load Balancing
5. Essential services SHOULD have a defined Incident Management process
   1. Their Service Record should have contact information for the Operations Team
   2. Security Incidents MUST follow ISS §16 - Information Security Incident Management
6. Essential services MUST be ranked 2 or higher in the release management maturity for all areas, with more detail to come in an upcoming standard

Development¶

1. The Development Team SHOULD follow modern development practices
   1. They MUST use version control
   2. They MUST do code review
   3. They MUST follow UCOP’s Secure Software Development Standard
2. The Development Team SHOULD verify business and technical requirements before each deployment
   1. This verification SHOULD be as automated as possible, and run using an appropriate testing tool
   2. Tests SHOULD track code coverage and aim for 80% coverage or higher
3. The Development Team and Operations Team SHOULD endeavor to keep all software dependencies up to date
   1. This includes the operating system, programming language, runtime, third party libraries, middleware, and any other software needed to operate the service
   2. All software dependencies SHOULD be audited for critical updates before each deployment
   3. This process SHOULD be as automated as possible

Change Management¶

1. Service deployment SHOULD be routine and well communicated
   1. User disruption SHOULD be minimized as much as possible
   2. Deployments SHOULD follow a regular schedule that allows users to anticipate updates
   3. Deployments SHOULD be announced beforehand so that no one is taken by surprise
   4. Deployment announcements SHOULD include information about all user-facing changes
   5. Deployments SHOULD be coordinated to minimize impact on all Dependent Services
2. The hosting environment SHOULD also follow change management
   1. Changes SHOULD follow a process similar to deploys
      1. This includes resource allocations (storage, memory, compute, etc)
      2. This includes changes to network connectivity, firewalls, etc
      3. This includes changes to permissions and
   2. Environments SHOULD seek isolation from other services through Virtualization, Containerization, etc

Supporting Team¶

1. All Essential services MUST have a Supporting Team that ensures business continuity, with more detail to come in an upcoming standard
   1. This is often the Operations Team, Development Team, or an external Supplier
   2. Teams MUST cross-train to ensure that any given task can be carried out by at least two people
2. Essential services MAY benefit by writing a Service Level Agreement (SLA)
3. Any such documents should be stored in a central location, with more detail to come in an upcoming standard
4. Essential services SHOULD have assigned time from trained personnel
   1. Quality Assurance (QA) SHOULD be available and integrated into the development process
   2. Business Analysis and Design work SHOULD proceed any development effort