Technology Services Glossary: Key Terms for Business Buyers

Business buyers evaluating IT vendors encounter a dense layer of technical vocabulary that shapes contract terms, service expectations, and liability boundaries. Misreading a single term — such as confusing "recovery time objective" with "recovery point objective" — can result in contractual obligations that do not match operational requirements. This glossary defines the core terms used across technology services procurement, from infrastructure support to managed services agreements. The scope covers terminology relevant to US-based organizations sourcing third-party IT services across commercial and regulated industries.


Definition and scope

A technology services glossary provides authoritative definitions for the vocabulary that appears in vendor proposals, service-level agreements, statements of work, and compliance documentation. The terms below span five functional categories: service delivery models, performance metrics, contract and legal terminology, infrastructure and architecture concepts, and compliance and security frameworks.

The IT Infrastructure Library (ITIL), maintained by Axelos and adopted globally as a foundational service management framework, defines many of the service-delivery terms that appear in vendor contracts. For security-related terms, the NIST Computer Security Resource Center publishes authoritative definitions in NIST SP 800-53, NIST SP 800-34, and the NIST Cybersecurity Framework (CSF). Business buyers should cross-reference vendor-supplied definitions against these public standards to identify divergences before signing.

Core term categories:

  1. Service delivery models — how support is structured and delivered (managed services, break-fix, staff augmentation, co-managed IT)
  2. Performance and availability metrics — how uptime, response, and restoration are measured
  3. Contract and commercial terms — legal and financial language governing the relationship
  4. Infrastructure and architecture — technical concepts describing the environment being supported
  5. Compliance and security frameworks — regulatory and standards-based requirements that shape service scope

For a fuller taxonomy of service types, see Technology Services Types and Categories.


How it works

Service Delivery Model Terms

Break-Fix Support — A reactive model in which the provider is engaged only when a failure occurs. No ongoing monitoring or maintenance is included. Billing is typically per incident or per hour.

Managed Services — A proactive model in which a provider assumes ongoing responsibility for defined IT functions under a recurring contract. For a detailed treatment, see Managed IT Services Overview.

Co-Managed IT — A hybrid arrangement in which an in-house IT team retains ownership of strategic functions while a third-party provider supplements with specific capabilities (e.g., 24/7 help desk, patch management). Contrasted with fully outsourced managed services in Outsourced vs In-House IT Services.

Staff Augmentation — Temporary placement of technical personnel within a client organization. The client retains management control; the vendor supplies the labor.

Performance and Availability Terms

Uptime / Availability — Expressed as a percentage of total time a system is operational. A 99.9% uptime guarantee equates to approximately 8.77 hours of allowable downtime per year; 99.99% ("four nines") equates to approximately 52.6 minutes per year.

SLA (Service-Level Agreement) — A contractual document specifying performance commitments, measurement methodology, and remedies for non-compliance. For procurement guidance, see Service Level Agreements in Technology Services.

RTO (Recovery Time Objective) — The maximum acceptable time to restore a system or function after a disruption. Defined by NIST SP 800-34 as part of contingency planning guidance.

RPO (Recovery Point Objective) — The maximum acceptable data loss measured in time. An RPO of 4 hours means no more than 4 hours of data may be lost in a recovery scenario. RTO governs restoration speed; RPO governs data currency — these are distinct and both must appear in any Disaster Recovery Services contract.

MTTR (Mean Time to Repair) — The average time required to restore a failed component or service. Lower MTTR indicates higher operational efficiency.

MTTF (Mean Time to Failure) — The average time a component functions before failure. Used primarily for hardware lifecycle planning under Hardware Support and Maintenance Services.

Contract and Commercial Terms

Statement of Work (SOW) — A document attached to a master services agreement that defines the specific deliverables, timelines, and acceptance criteria for a discrete engagement.

Master Services Agreement (MSA) — The overarching contract governing the relationship between client and provider. Individual projects or services are governed by SOWs executed under the MSA.

Auto-Renewal Clause — A provision that extends the contract for an additional term (commonly 12 months) unless the client provides written notice of cancellation within a defined window (commonly 30–90 days). Failure to track this clause is one of the most common sources of unintended multi-year commitments.

Limitation of Liability — A clause capping the provider's financial exposure for damages. Caps are frequently set at the total fees paid in the preceding 12 months, which may be inadequate for high-stakes recoveries.

Indemnification — A party's obligation to compensate the other for specified losses. In technology services contracts, indemnification language commonly covers IP infringement, data breaches caused by the provider, and third-party claims.


Common scenarios

Scenario 1: SLA misalignment
A healthcare organization contracts for help desk support with a 4-hour response SLA, but assumes this means the issue will be resolved within 4 hours. ITIL terminology distinguishes "response time" (acknowledgment of the ticket) from "resolution time" (closure of the incident). The ITIL 4 Foundation framework defines these as separate metrics. Contracts must specify both.

Scenario 2: RPO/RTO confusion in backup contracts
A financial services firm negotiates a 2-hour RTO without specifying an RPO. After a ransomware incident, the provider restores systems within 2 hours but from a backup that is 48 hours old — technically compliant with the contract but operationally catastrophic. Both metrics must be explicitly stated. See Data Backup and Recovery Services for procurement checklists.

Scenario 3: Break-fix vs. managed services scope creep
A retail organization engaged under a break-fix model requests routine patch deployment. The provider bills this as a separate engagement because patch management falls outside the incident-response scope of break-fix. The IT Service Management Frameworks page covers how ITIL and ISO/IEC 20000-1 define service request management separately from incident management.


Decision boundaries

Managed Services vs. Break-Fix: When Each Applies

Factor Managed Services Break-Fix
Infrastructure complexity High (50+ endpoints, multi-site) Low (fewer than 10 endpoints, single location)
Regulatory exposure HIPAA, PCI-DSS, SOC 2, CMMC Minimal or none
Budget structure Predictable monthly spend preferred Variable, as-needed spend preferred
Downtime tolerance Low (RTO measured in hours) Higher tolerance acceptable
Internal IT staff None or limited Capable in-house team present

The NIST Cybersecurity Framework (CSF), version 2.0 published in 2024, provides a governance structure that effectively requires continuous monitoring practices — aligning more naturally with managed services than break-fix for organizations in regulated sectors.

Key Decision Triggers

  1. Compliance mandate present — If the organization is subject to HIPAA, PCI-DSS, FTC Safeguards Rule, or CMMC, the continuous monitoring and documentation requirements of managed services are almost always necessary.
  2. Fewer than 3 internal IT staff — Organizations with thin internal teams typically cannot sustain 24/7 coverage without a managed services partner.
  3. Multi-vendor environment — When more than 5 distinct technology vendors are in the environment, vendor management complexity generally justifies a managed services model.
  4. Prior breach or significant outage — Post-incident remediation frequently reveals gaps that break-fix models cannot address systematically.

For guidance on evaluating which service model matches an organization's profile, see How to Evaluate Technology Service Providers. Contract-specific language appears in the Technology Services Contract Terms Glossary.


References

Explore This Site