Technology Decision Rights

Technology decision rights assign accountability for decisions to specific roles based on decision type, financial impact, and organisational risk. This reference defines the categories of technology decisions, the authority levels required to approve them, and the escalation paths when decisions exceed delegated thresholds or require cross-functional input.

Decision rights function as a control mechanism within the broader governance framework established in IT Operating Models. They translate governance principles into operational rules that determine who can commit the organisation to technology choices, expenditures, and architectural directions.

Decision categories

Technology decisions divide into four categories based on their scope, reversibility, and organisational impact. Each category carries distinct approval requirements and documentation standards.

Strategic decisions

Choices that set technology direction for 3 or more years, affect multiple business functions, or commit the organisation to vendor relationships exceeding £100,000 annually. Examples include enterprise platform selection, cloud provider commitment, and major architectural shifts such as adopting zero trust security models.

Architectural decisions

Choices that establish technical patterns, integration approaches, or standards affecting multiple systems. These decisions constrain future technical options without necessarily involving large expenditure. Examples include API design standards, data model conventions, authentication protocols, and infrastructure patterns.

Operational decisions

Choices about running and maintaining existing systems within established parameters. These decisions have limited organisational impact and are generally reversible. Examples include patch scheduling, capacity adjustments within budget, vendor support tier selection, and monitoring threshold configuration.

Procurement decisions

Choices to acquire technology products, services, or contractor support. Procurement decisions overlap with other categories but carry specific requirements around competitive process, contract terms, and financial controls. The procurement category applies additional approval layers rather than replacing category-specific requirements.

The distinction between strategic and architectural decisions warrants clarification. A decision to adopt Microsoft 365 as the collaboration platform is strategic because it commits the organisation to a multi-year vendor relationship with substantial financial and operational implications. A decision to require all internal APIs to use OpenAPI 3.0 specification is architectural because it constrains technical implementation without vendor commitment. Some decisions span categories: selecting Kubernetes as the container orchestration platform is both strategic (vendor ecosystem commitment) and architectural (infrastructure pattern establishment).

Authority matrix

The authority matrix maps decision types to approval requirements based on financial thresholds and risk levels. Thresholds represent total cost of ownership over the commitment period, not annual cost alone.

Strategic decisions

Risk levels derive from data sensitivity, operational criticality, and reputational exposure. A £50,000 decision affecting beneficiary data protection carries higher risk than a £50,000 decision about internal productivity tools. The IT Director assesses risk level; disagreements escalate to the CEO for determination.

Architectural decisions

Reversibility assessment considers the cost and disruption of changing direction after implementation. Adopting a logging format is easily reversed; adopting a database engine is difficult to reverse. When reversibility is uncertain, treat the decision as difficult to reverse.

Operational decisions

Operational decisions require no formal approval process when made within delegated authority. Documentation requirements still apply for decisions affecting system configuration, security posture, or service levels.

Procurement decisions

Procurement approval layers add to category-specific requirements rather than replacing them. A strategic procurement decision requires both strategic decision approval and procurement approval.

Competitive requirements admit exceptions for sole-source procurement when technical requirements preclude alternatives, existing integration mandates specific vendors, or emergency circumstances prevent competitive process. Sole-source exceptions require documentation of justification and approval one level above the standard authority for that threshold.

RACI matrices

RACI assignments clarify involvement beyond the primary decision authority. Responsible roles do the work of analysis and recommendation. Accountable roles make or ratify the final decision. Consulted roles provide input that must be considered. Informed roles receive notification of decisions.

Strategic decision RACI

The executive sponsor role falls to the senior leader whose function derives primary benefit from the decision. For enterprise-wide decisions without clear functional ownership, the COO serves as executive sponsor.

Architectural decision RACI

Architecture review board composition and meeting cadence depend on organisational scale. Organisations without a formal architecture review board assign architectural consultation to senior technical staff or external advisors.

Operational decision RACI

Operational decisions follow streamlined RACI because their limited scope and reversibility reduce coordination requirements. The Change Management Policy governs operational changes affecting service availability.

Escalation paths

Escalation transfers decision authority upward when circumstances exceed delegated thresholds, when stakeholders disagree, or when risk factors warrant senior oversight.

Threshold escalation

Decisions exceeding financial or scope thresholds automatically escalate to the next authority level. No judgement is required; the threshold triggers escalation regardless of other factors.

Disagreement escalation

When required consultees disagree with a proposed decision, escalation provides resolution. The escalation path depends on the nature of disagreement.

Escalation timelines begin from formal notification of disagreement. If resolution authority does not decide within the timeline, the original recommendation proceeds unless resolution authority explicitly blocks it.

Risk-based escalation

Certain risk factors mandate escalation regardless of financial threshold or normal authority.

Risk-based escalation adds consultation or notification requirements without necessarily changing decision authority. The IT Director retains authority for a £30,000 decision involving beneficiary data but must consult the Data Protection Officer before proceeding.

Documentation requirements

Decision documentation creates an audit trail, enables future reference, and supports organisational learning. Requirements scale with decision significance.

By decision category

Decision record contents

Strategic decision records include the following elements:

The decision statement captures what was decided in unambiguous terms. “Adopt Microsoft 365 E3 licensing for all staff” rather than “Proceed with collaboration platform project.”

The context section documents the business need, triggering event, and constraints that shaped the decision. This section should enable someone unfamiliar with the decision to understand why it arose.

The options considered section summarises alternatives evaluated, including options rejected. For each option, document the key factors favouring and disfavouring selection.

The rationale section explains why the selected option was chosen. Reference specific evaluation criteria and how the selected option performed against them.

The consequences section describes expected outcomes, implementation requirements, and known risks accepted. This section sets expectations for measuring decision success.

The approvals section records who approved the decision, when, and under what authority. Include evidence of required consultations.

Architecture decision records

Architecture decision records follow a structured format enabling technical reference:

# ADR-[number]: [Title]

## Status
[Proposed | Accepted | Deprecated | Superseded by ADR-xxx]

## Context
[Technical and business context requiring a decision]

## Decision
[The architecture decision made]

## Consequences
[Resulting context after applying the decision]

## Compliance
[How this decision aligns with organisational standards]

Architecture decision records reside in version control alongside affected system documentation. The Documentation Standards specify repository structure and naming conventions.

Worked example

A country office proposes adopting a new mobile data collection platform to replace paper-based beneficiary registration. The platform costs £35,000 for a 3-year licence with £8,000 annual support, totalling £59,000 commitment.

Category determination: The decision is strategic (affects programme delivery, multi-year commitment) with procurement overlay (software acquisition).

Authority identification: At £59,000 total commitment, strategic decision authority rests with IT Director with CEO or COO secondary approval. Procurement approval requires IT Director plus Finance Director with formal tender process.

Risk assessment: The platform processes beneficiary personal data including protection-sensitive information. Risk level is high regardless of financial threshold, triggering Data Protection Officer consultation.

RACI application: The Programme Director serves as executive sponsor (primary beneficiary of the system). IT Director is accountable for recommendation. Country IT lead is responsible for requirements and evaluation. Finance Director consults on financial analysis. DPO consults on data protection assessment.

Documentation requirement: Full strategic decision record plus procurement file with tender evaluation. Retention minimum 7 years.

Escalation check: No threshold escalation required. If Programme Director and IT Director disagree on platform selection, CEO resolves within 10 working days.

The decision record documents: selection of Platform X over Platforms Y and Z; rationale based on offline capability, local support presence, and data residency options; consequences including 6-month implementation timeline and staff training requirements; risks accepted including vendor financial stability concerns mitigated by data export provisions.

See also

• IT Operating Models
• IT Planning and Prioritisation
• Change Management Policy
• Documentation Standards