- 22 Jul 2025
- 11 Minutes to read
- Print
- PDF
Configure Underpinning Contract Specification
- Updated on 22 Jul 2025
- 11 Minutes to read
- Print
- PDF
An Underpinning Contract (UC) is a formal agreement between the IT service provider and an external third-party/vendor that supports service delivery under an SLA. While SLAs define the commitments to the customer, UCs ensure that external suppliers meet specific service levels that enable the internal team to fulfill the SLA.
The UC Specification in SLA Management allows you to define, track, and govern the terms, scope, and responsibilities of external parties contributing to the overall service performance.
To Configure UCS, perform the following steps:
Log in to the application as an Admin.
Navigate to SLA > User > Underpinning Contract > New Underpinning Contract Specification.
New UCS configuration screen is displayed.
Figure: New Underpinning Contract Specification
To configure UCS at the Tenant level, select and enter the required fields in the left layout of the configuration screen.
The following table describes the Field Description:Field
Description
Department
Select Department from the dropdown list. It will display a list of Tenants based on the configuration under Admin > Tenant for which the SLA module will be available.
Customer
Select Customer from the dropdown list. It will display the list of customers based on the configuration under Admin > Customers > Customer List.
Location
Select Location from the dropdown list. It will display the list of locations based on the configuration under Admin > Infrastructure > Common Masters > Common Master Type.
Date
Displays the system date and time.
Example: 2025-07-10 12:42:25 PM
Service Name
Enter the Service Name.
Status
Displays the status of the UCS, following are the other Statuses available after configuration.
New - As a new UCS configuration is selected, the status by default is New and field is grayed.
Approve - This status is displayed when the UCS is approved from the approver.
Publish - This status is displayed If it is ready to publish.
Service Workgroup
Select Service Workgroup, the dropdown list displays all the workgroups under the selected Tenant.
Service Level Manager
Displays the Service Level Manager name, it is displayed based on the service level manager configured for the Workgroup under SLA > Configuration > Service Level Approver.
Service Handling
Select Service Handling from the dropdown list.
Description
Enter a Description about this UCS configuration.
Services Offered
Displays the CMDB list.
Attachment
Upload the files that support Underpinning Contract Specifications configuration.
The Service Availability section is used to define and track the availability-related targets and expectations for specific infrastructure components that support a service. It captures measurable service-level requirements such as maximum interruptions allowed, acceptable downtime, utilization benchmarks, and notification methods.
By mapping these parameters to specific entities like servers or network components, this ensures that service uptime and reliability are properly governed as per business needs.
Figure: Service Availability
For more information, refer to the following Field Description:
Field | Description |
---|---|
Entity | Select the type of infrastructure entity for which availability is being measured. Dropdown options include Server, Network Device, Network Link. Example: Choose Server to configure availability for application or database servers. |
Configuration Name | Enter Configuration Name for the Underpinning Contract. |
Entity List | Displays available entities based on the selected Entity type. |
Service Catalog | Select Service Catalog, it is the associated service from the Service Catalog that this entity supports. |
Period | Select Period for service availability measurement from the options: Monthly, Quarterly, Semi-Annually, and Annually. Defines the evaluation frequency for availability measurement. Example: Choose “Monthly” if you want to measure uptime and interruptions on a monthly basis |
No. of Interruptions | Enter a value for No. of Interruptions, this specifies the maximum number of acceptable service interruptions during the selected period. Example: Enter "2" if only two unplanned interruptions are acceptable per quarter. |
Availability Threshold Target | Enter value for Availability Threshold Target, this is the minimum acceptable percentage of uptime for the selected entity within the defined period. Example: 99.9% monthly uptime means only ~43 minutes of downtime is acceptable per month |
Scheduled No. of Downtime | Enter a value for scheduled no of downtime, this is the expected or planned number of downtime events (example: maintenance) within the evaluation period. Example: Enter "1" if monthly maintenance is expected and allowed without impacting SLA compliance. |
Utilization Target | Indicates target usage levels of the selected entity, such as CPU, bandwidth, or memory utilization. |
Notification Methodology | Describe the Notification Methodology, how and when notifications should be triggered when availability drops below target. Example:
|
Effective Date | The date from which the availability metrics and thresholds become enforceable. |
The Performance section in the UCS configuration screen is designed to capture and enforce internal expectations for service quality and operational readiness. This includes how much workload a support function is expected to handle, the application's responsiveness, and how quickly incidents must be addressed and resolved.
These parameters help align internal teams with the agreed performance standards to ensure consistent delivery of services that support the overall SLA targets.
Figure: UCS Performance Configuration
Required Capacity: This defines the minimum capacity (example: resources, personnel, infrastructure) that the operational team must ensure is available to support the service.
Example: 10 agents should be available at all times to handle Level 2 support tickets.
Service Usage: Specifies the acceptable limits of usage or workload the internal team can handle over a specific time frame
Example: 500 tickets per day.
Response Time from Application: Indicates the maximum time the associated application should take to respond to an action or request initiated by the internal team.
Example: Application must respond to data retrieval requests within 2 seconds.
Response and Resolution Times:
Response Time: Time taken by the internal team to acknowledge or begin working on an issue after it is reported.
Example: Acknowledgment within 15 minutes of ticket assignment.
Resolution time: Time by which the issue should be fully resolved and service restored.
Example: Critical issues must be resolved within 4 hours.
The Performance tab ensures the internal operations team is informed about what is expected of them in terms of resource allocation, system response behavior, and turnaround times. Defining these parameters correctly supports effective service delivery, avoids SLA violations, and improves collaboration across service functions.
The Maintenance section in the UCS configuration screen is intended to define UCS and expectations related to planned or unplanned maintenance activities, especially those occurring during emergencies. This ensures that internal teams are aligned on how to respond and act when critical service components require urgent intervention or updates.
By capturing these details within a Underpinning Contract Specification, organizations can maintain service continuity, minimize risk, and ensure that emergency actions are authorized and traceable.
Figure: Configure UCS Maintenance
Maintenance Requirements (In Case of Emergency): This field captures the predefined requirements, steps, or conditions under which emergency maintenance can be carried out by the operational team or vendor.
Example: Downtime window allowed only between 10 PM–12 AM with prior 30-minute notice to all stakeholders.
Attachment Upload * : This is a required field that you must upload a supporting document outlining the emergency maintenance process, approvals, contact list, or any contingency plan related to the entry in the text field.
Example: Emergency maintenance standard operating procedure (SOP), Emergency contacts List, Risk assessment or impact analysis report, Downtime mitigation plan or rollback procedure.
Approvals process and facilitates structured review and formal agreement. Ensures the designated approver from the Service Workgroup approves or rejects the Approval.
Figure: UCS Approvals Configuration
For more information, refer to the following Field Description:
Field | Description |
---|---|
Approver | Displays the Approver name of based on the selected Service Workgroup. |
Status | Select Status option from the dropdown list. Options displayed are as follows:
|
Remarks | Enter Remarks, this is a field where the approver can provide comments, justifications, or feedback regarding their approval decision. |
In Underpinning Contracts (UC) within SLA Management, the Service Composition (External) section is used to define and track third-party services that contribute to the delivery of a business service. This is essential when parts of the service are outsourced or rely on external vendors or partners.Figure: Service Composition
For more information, refer to the following Field Description:
Field | Description |
---|---|
External | The Service Composition section under UCS defines the individual components that make up a service. When the External option is selected, it indicates that part of the service delivery relies on an external service provider (third party or vendor). Ensuring they are properly governed by contractual agreements and aligned with internal SLAs. |
Service Name | Enter Service Name, the name of the external service that contributes to the overall service offering. |
Service Provider* | Select Service Provider from the dropdown. The displayed list is the external team or workgroup responsible for providing the underlying service or operational support. |
Underpinning Contract* | Select Underpinning Contract. It is the reference to the contract or agreement between the organization and the external service provider. |
Remarks* | Enter Remarks, you can enter where additional comments, context, or notes about the service composition can be provided. |
Required Changes* | Enter Required Changes, this is a field to capture any requested modifications to the existing OLA. If the OLA is not sufficient for the service to be established. |
Attachments | Upload file to attach supporting documentation related to the service, workgroup responsibilities, or OLA dependencies. However, this field is optional. |
The Financial Details section to captures the cost-related information associated with delivering the operational service defined in the UCS. This section enables organizations to track, manage, and justify internal costs of service provision, which is especially important for budgeting, cost optimization, and internal chargeback or cost allocation processes.
By recording cost types, accounting methods, and currency, this tab helps align financial accountability with service delivery expectations.
Figure: UCS Financial Details Configuration
For more information, refer to the following Field Description:
Field | Description |
---|---|
Cost Type | Select Cost Type from the dropdown list. Categorizes the nature of the cost being recorded. Helps break down service costs into identifiable categories for better tracking and analysis.
|
Cost | Enter Cost value, this is the numerical value (amount) associated with the selected Cost Type. |
Accounting Method | Enter Accounting Method, this field specifies how the cost is accounted for within the organization’s financial system. Examples:
Ensures financial records align with organizational accounting policies and reporting frameworks |
Currency | Select Currency from the dropdown. The selected value is the currency in which the cost is recorded. Example: INR, USD, EURO, POUNDS |
Date | Select Date, this is the date on which the financial entry is recorded or becomes effective. |
Remarks | Enter Remarks to capture additional details, context, or justification for the cost entry. |
The Target section defines the Service Level performance goals that the service workgroup must meet for incident handling and request fulfillment. It captures measurable targets such as response and resolution times based on different priorities. This ensures that internal service levels are clearly defined and aligned with organizational or customer expectations.
Figure: UCS Target Configuration
Incident Management Targets
This section sets the expected Response and Resolution times for different incident priorities. These targets ensure that critical incidents are addressed faster than lower-priority ones and help track internal compliance with SLA-driven commitments.
For more information, refer to the following Field Description.
Field | Description |
---|---|
Priority | Select Priority from the dropdown. Represents the severity level of the incident (example: Critical, High, Medium, Low). |
Response Target | Enter Response Target. The value entered here is represented as % hence, it is the percentage of incidents (of a given priority) that must be responded to within the defined SLA time.
|
Resolution Target | Enter Resolution Target. The value entered here is represented as % hence, it is the percentage of incidents that must be resolved within the agreed SLA time. Example: For P2 incidents: 90% is the Resolution Target, 90% of P2 incidents must be resolved within the SLA (example: 4 Hours). |
Effective Date | Select Effective Date, specifies from when the Targets become active or enforceable. |
Click Add to save the configuration in the Incident Management Target. |
Request Fulfillment Targets
This section mirrors the incident targets but is focused on service requests (example: password resets, access requests, software installations). These targets help manage the delivery expectations of routine service tasks. For Field Description, refer to the Table described above.
The Contract Details section captures all key lifecycle information related to the Underpinning Contract, including its validity, scope, business rationale, and financial value. It ensures that vendor contracts supporting service delivery are formally documented, trackable, and aligned with internal SLAs.
Figure: Underpinning Contract - Contact Details
Contract Details further has the following sections:
Contract Duration
Warranty
Contract Value
For more information, refer to the following Field Description:
Field | Description |
---|---|
Contract Duration | |
Start Date | Select Start Date, this is the date when the contract becomes active. |
End Date | Select End Date, this is the date when the contract officially ends. |
Termination Rules | Enter Termination Rules to define the conditions under which the contract may be terminated early. |
Business Justification | Enter Business Justification, the reason for selecting this vendor or establishing this contract |
Processes / Activities | Enter Activities, capturing the business or IT processes supported by the vendor’s service. |
Desired Outcome | Enter Desired Outcome, the expected benefit or result of having this contract in place. |
Warranty | |
Start Date | Enter Start Date, this is the date the warranty coverage begins. |
End Date | Enter End Date, this is the date the warranty ends. |
Attachments | Upload warranty documents such as PDFs, service statements, or warranty terms. |
Contract Value | |
Value | Enter contract agreement value, specifying the total financial worth of the contract. |
Currency | Select the Currency from the dropdown. The list will display the available currencies such as CAD, Euro, Pounds etc. |
The Risk tab is designed to assess the business criticality and operational impact of the service being defined under the UCA. This section ensures that risk exposure is evaluated based on the importance of the service to vital business functions (VBFs), dependencies on critical assets, and the potential impact of service failure or degradation.
Figure: Risk
Identifies which business functions and assets are supported by the service, and assesses the associated business risk if the service becomes unavailable.
VBFs Supported: Lists the critical business functions or operations that depend on this service.
Other Critical Assets: Lists non-VBF assets (applications, databases, infrastructure components) that are crucial for the service to function.
Business Justification: Enter a description of the consequences or severity of impact on the business if the service fails or is disrupted.