## Intro Technology Risk Management (TRM) is the discipline of identifying, assessing, and treating risks so technology delivers business outcomes with fewer surprises. This guide is for CTOs, CIOs, VPs of Engineering, product leaders, and portfolio managers who need a simple, repeatable way to link risks to strategy, architecture, and delivery decisions. The practical takeaway: use a standard lifecycle, a shared taxonomy, and a working risk register to make timely, transparent trade-offs across value, cost, and risk. What you will get: - A recognized risk-management lifecycle adapted to technology organizations - Clear distinctions between TRM, cybersecurity, compliance, issue management, and project risk - A complete risk-register template and a worked example - Governance roles, cadences, decision rights, and reporting tiers - How TRM connects to strategy, architecture, vendors, resilience, data/AI, technical debt, and portfolio funding - Metrics that matter (and those to avoid), anti-patterns, and first steps ## What TRM is — and is not - TRM vs cybersecurity management: Cybersecurity focuses on protecting confidentiality, integrity, and availability of information assets. TRM covers broader technology risks, including delivery, architecture, vendor, resilience, data quality, AI model behavior, and financial exposure. Security risks are a subset of TRM. - TRM vs compliance: Compliance ensures adherence to laws, regulations, and policies. TRM informs compliance by quantifying exposures and prioritizing controls based on risk, not just rules. - TRM vs issue management: Issues are realized problems to resolve now. Risks are uncertain events that may happen. Track issues separately and link them to triggering risks when relevant. - TRM vs project risk: Project risk management focuses on scope, schedule, and budget within a project. TRM spans products, platforms, and run-time operations, aggregating exposures across teams, programs, and time horizons. ## A practical TRM lifecycle Ground your operating model in a recognized lifecycle (e.g., ISO 31000-style), simplified for technology: - Establish context - Clarify objectives, constraints, time horizon, and stakeholders. - Define risk appetite (what you are prepared to pursue) and tolerance (acceptable variation around objectives) by category. - Identify risks - Use workshops, pre-mortems, architecture reviews, incident learnings, vendor assessments, and threat modeling. Capture precise risk statements. - Analyze and evaluate - Assess inherent risk (without additional controls), the strength of existing controls, and residual risk (after controls). Use both qualitative scales and quantitative estimates where feasible. - Treat risks - Choose among avoid, reduce, transfer, accept, or explore (for uncertainty that may hide upside). Specify owners, actions, due dates, and success criteria. - Monitor and review - Track Key Risk Indicators (KRIs), control evidence, and trend. Review risks on a set cadence; escalate when thresholds are breached. - Record and communicate - Maintain a single-source risk register. Provide tiered reporting: team, function, enterprise. ## Taxonomy and shared language Adopt a concise taxonomy so teams speak the same language. Categories (typical): - Strategic, delivery, operational, security, compliance, financial, third-party/vendor, data/AI, resilience/reliability, architecture/technical debt Risk statement pattern: - Because [cause], [risk event] may occur, leading to [effect on objective]. Key attributes and definitions: - Inherent risk: Exposure before considering additional controls specific to the risk. - Controls: Prevent, detect, and respond safeguards. Record control evidence (what proves the control exists and works). - Residual risk: Exposure remaining after controls. Decide to treat further or accept. - Likelihood: Probability of occurrence within the planning horizon (qualitative 1-5 or estimated probability). - Impact: Effect on objectives (e.g., customer outcomes, revenue, cost, compliance, safety). - Velocity: How quickly impact manifests after occurrence (e.g., 1=slow, 3=immediate). - Risk score (illustrative): Score = Likelihood (1-5) x Impact (1-5) x Velocity (1-3). - Appetite: The amount and type of risk the organization is willing to pursue to achieve objectives. - Tolerance: Acceptable variation around objectives within appetite. - Treatment options: Avoid, reduce, transfer/share, accept, explore (uncertainty with potential upside). - Acceptance: Formal decision that residual risk is within appetite and tolerance. - Escalation: Required when residual risk or KRI breaches exceed tolerance or decision rights. - Aggregation: Rolling up related risks to see concentration (e.g., multiple vendor dependencies in the same region). ## Governance: roles, cadence, and decision rights Define who decides what, when, and with what evidence. Roles (adapt to your size): - CTO/CIO: Owns TRM operating model; sets technology risk appetite with the executive team. - CISO (or Security Lead): Owns security risk domain and acceptance thresholds; advises on control strength. - Head of Architecture/Platform: Owns architecture and technical debt risks; chairs design reviews. - Product/Engineering Directors: Own delivery and operational risks for their areas; ensure register quality and updates. - Risk Partner (if present): Facilitates risk lifecycle, aggregation, and reporting. - Risk Owners: Named individuals accountable for each risk and its treatment plan. Committees and cadence (example): - Team risk huddle: Weekly, 15 minutes, top 5 risks, indicators, and upcoming decisions. - Domain review: Monthly, 60 minutes, status of key risks, control evidence, and escalations. - Technology Risk Committee (TRC): Monthly, chaired by CTO/CIO; cross-functional review of high/critical risks, portfolio trends, and decisions requiring acceptance or funding. - Executive Risk & Compliance Committee (ERCC): Quarterly; aligns appetite, major acceptances, and board reporting. Decision rights (illustrative): - Delivery risks up to Medium: Product/Engineering Director can accept. - Security risks Medium-High: CISO co-signature required; High or above must go to TRC. - Financial exposure over a threshold: CFO sign-off. - Any risk exceeding appetite or with enterprise impact: Escalate to ERCC/Board Risk. Reporting tiers: - Tier 1 (Team): One-page dashboard with top risks, KRIs, actions. - Tier 2 (Function): Aggregated heatmap, watchlist, systemic themes. - Tier 3 (Enterprise): Concentration by category/vendor/region; major acceptances; trend lines. ## Metrics and KRIs that matter Classify metrics to avoid noise: - Leading: Change failure rate, dependency churn, early vendor SLA warnings, error budget burn trend, model drift indicators. - Lagging: Incidents by severity, SLA/SLO breaches, audit findings closed, vendor outage minutes. - Diagnostic: Test coverage, vulnerability backlog age, mean time between failures, config drift counts. - Guardrail: Monthly cloud spend vs budget, error budget consumption, access exceptions outstanding. - Vanity (avoid): Pull requests merged, lines of code, number of meetings. KRIs should have explicit thresholds, owners, and actions on breach. ## Risk register: template and worked example Use a single register for technology with clear fields. Minimal fields: - ID, Risk statement, Category - Inherent L/I/V/Score - Key existing controls + control evidence - Residual L/I/V/Score - KRIs and thresholds - Owner, Next review date, Treatment decision Illustrative scoring scale: - Likelihood: 1=rare, 3=possible, 5=likely - Impact: 1=low, 3=moderate, 5=severe - Velocity: 1=slow, 2=moderate, 3=immediate - Score = L x I x V (max 75) Appetite examples (illustrative): - Security: score <= 12 within tolerance - Resilience: score <= 18 within tolerance - Delivery: score <= 24 within tolerance Worked example (hypothetical)
IDRisk statementCategoryInherent (L/I/V/S)Key existing controls + evidenceResidual (L/I/V/S)KRIs (owner, threshold)OwnerNext reviewTreatment
R-01Because the external payments gateway may throttle at peak, our checkout may fail, causing revenue loss during promo events.Third-party/vendor4/5/3/60Contracted burst capacity; synthetic checks every 1 min; vendor premium support; evidence: contract clause 4.2, Grafana panel P-173/4/3/36p95 checkout latency > 800ms for 5 min (SRE, page); vendor 5xx > 1% (SRE)Payments Eng Mgr2024-10-15Reduce: add adaptive retry + queue; explore multi-provider by Q4
R-02Because our data pipeline lacks schema enforcement, PII could leak into analytics, breaching policy.Data/compliance3/5/2/30Data contracts on 4 key tables; DLP scans nightly; evidence: DLP report 2024-09-102/4/2/16DLP hits > 0 critical per day (Data Lead); exceptions > 3 open (Data Lead)Head of Data2024-10-01Reduce: implement schema registry + field-level encryption
R-03Because model prompts call an external LLM, hallucinations may mislead users, harming trust metrics.Data/AI3/4/2/24Guardrails library; human-in-the-loop for flagged outputs; evidence: eval suite v1.2, incident postmortem AI-072/3/2/12AI factuality score < 0.9 weekly (AI Lead); flagged outputs > 0.5% (PM)AI Lead2024-09-30Accept within tolerance for beta; reduce with retrieval augmentation by Q3
R-04Because of deferred upgrades, a critical library vulnerability may be exploited, causing outage.Security/tech debt4/5/3/60Weekly vuln scans; patch SLO 30 days; evidence: Snyk dashboard, CAB approvals3/4/3/36Critical vulns age > 14 days (Sec Eng); exposed CVE count > 0 (Sec Eng)Platform Director2024-09-25Reduce: ringfenced patch sprint; transfer via cyber insurance renewal
R-05Because we lack active-active failover, a zonal outage could cause >30 min downtime.Resilience3/5/3/45Backups daily; runbooks; quarterly DR test (2 hrs RTO); evidence: DR report 2024-Q23/4/3/36SLO error budget burn rate > 2x weekly (SRE); DR test pass rate < 100% (SRE)SRE Manager2024-10-10Avoid/reduce: build multi-AZ by Q1; request funding at TRC
Notes: - Control evidence is concrete: dashboards, reports, contracts, test results. - Treatment decisions include owners and timelines that show up in roadmaps and funding asks. ## Connecting TRM to strategy, architecture, and portfolio funding - Strategy and OKRs: Tie top risks to strategic objectives. Example: an OKR to reduce churn by 2 points should map to resilience and data-quality risks with targets and KRIs. - Architecture and technical debt: Treat material debt items as risks with explicit impact on change failure rate, lead time, and incident probability. Use TRM to justify refactoring in portfolio planning. - Vendors: Concentration risk across cloud region or single-sourced providers is an aggregated risk; monitor exposure limits and diversification plans. - Resilience: Use SLOs (service level objectives) as both targets and KRIs; connect error budgets to risk tolerance and release gating. - Data and AI: Track data quality (completeness, accuracy, timeliness) as KRIs. For AI, treat model drift, bias, and prompt-injection as risks with guardrails and offline evals as controls. - Portfolio funding: Present risk-reduction initiatives with expected risk delta (before/after score) and value impact (e.g., reduced downtime minutes). This turns risk work into investable options. ## End-to-end example: shipping an AI-assisted support feature Context (hypothetical mid-market SaaS): - Objective: Improve first-contact resolution by 15% in Q4. - Scope: AI-assisted replies using an external LLM; rollout to 25% of agents in two regions. - Appetite: Low for security/compliance, moderate for delivery risk, moderate for model quality within beta. Plan using the lifecycle: - Establish context - Stakeholders: Support VP, CIO, CISO, Data/AI Lead, Legal, Vendor Mgmt. - Tolerance: Downtime <= 10 min/month; zero PII exposure; factuality >= 0.9. - Identify risks - Data leakage to vendor; hallucinations misguiding agents; vendor rate limits; latency spikes; model drift; operational on-call readiness; cost overrun. - Analyze and evaluate - Score risks; R-02 (PII leakage) inherent 3/5/2/30; R-03 (hallucinations) 3/4/2/24; R-01 (vendor throttling) 4/4/3/48. - Treat - Reduce data leakage: field-level encryption + redaction; vendor DPA signed; evidence tracked. - Reduce hallucinations: retrieval-augmented generation with curated knowledge base; human-in-the-loop for confidence < threshold; weekly eval suite. - Reduce vendor throttling: adaptive rate limiting; prefetch; pilot 10% traffic; plan secondary vendor by Q1. - Transfer: add usage-based cost cap with alerts; negotiate credits for SLA breach. - Accept: temporarily accept model drift risk in beta within factuality >= 0.9. - Monitor - KRIs: factuality score < 0.9 triggers rollback; PII DLP hits > 0 triggers block; p95 latency > 1s for 10 min triggers failover; cost > budget by 10% triggers review. - Record and communicate - One-page dashboard shared weekly; TRC signs off on security acceptance; progress reported at ERCC quarterly. Outcome (illustrative): - Residual risks within appetite; go/no-go criteria met after 3 weeks of pilot; funding approved for vendor diversification. ## Practical templates - Risk statement: Because [cause], [event] may occur, leading to [effect on objective]. - Scoring formula (illustrative): Score = L (1-5) x I (1-5) x V (1-3). - Control design: At least one prevent, detect, and respond control per top risk. - KRI design: Metric, threshold, owner, and action-on-breach in the register. - Acceptance memo: Risk ID, rationale, residual score, evidence, time-bound review date, signatories. ## Anti-patterns to avoid - Equating TRM with cybersecurity only; non-security risks go unmanaged. - Giant risk logs with no owners, no control evidence, and stale review dates. - Scoring theater: numbers without clear scales, velocity, or appetite linkage. - Treating issues as risks and masking urgent work. - Evergreen yellow: chronic medium risks that never escalate or close. - Accepting risks without time-bound review, sign-off, or KRIs. - No aggregation: multiple dependencies in a single region go unnoticed. - Reporting without decisions: slides instead of actions, owners, and dates. ## When to use TRM, when not, and prerequisites Use TRM when: - Objectives are material (customer, revenue, regulatory, brand) or dependencies are complex. - Decisions involve cross-functional trade-offs (e.g., time-to-market vs resilience). - You need to justify funding for risk-reduction or technical debt. Do not over-rotate TRM when: - Small, low-impact changes with clear rollback exist; use lightweight checklists. - You lack minimum observability; invest first in telemetry and SLOs. Prerequisites and limitations: - Basic observability (logs, metrics, traces) and inventory of critical services. - Named owners for services and risks. - Clear objective setting (OKRs or SMART goals) to tie impact to outcomes. - Recognize uncertainty: quantitative precision is limited; blend qualitative and quantitative judgment. ## Decision and governance checklist - Objectives and appetite - Is the business objective specific and time-bound? - What appetite/tolerance applies by category? - Ownership and roles - Who owns each top risk, control, and KRI? Who can accept which risks? - Identification and sizing - Have we covered delivery, operational, security, compliance, vendor, data/AI, resilience, architecture/tech debt? - Are L/I/V scales and scoring consistent? - Controls and indicators - Do we have prevent, detect, and respond controls with evidence? - Are thresholds and actions documented and tested? - Cadence and reporting - Are reviews on calendar (team weekly, domain monthly, TRC monthly, ERCC quarterly)? - Can executives see exposure, trend, and decisions on one page? - Learning and adaptation - Do we run pre-mortems and after-action reviews? - Do insights change roadmaps, OKRs, and appetite? ## Conclusion Technology Risk Management turns uncertainty into deliberate trade-offs. Anchor your approach in a clear lifecycle, a shared taxonomy, and a living risk register with owners, evidence, and KRIs. Govern with simple cadences and defined decision rights so acceptance and escalation are timely and traceable. Connect risks to strategy, architecture, vendors, resilience, data/AI, and funding, and measure what matters with leading, lagging, diagnostic, and guardrail metrics. If you do only three things this quarter: set explicit appetites and tolerances, stand up a single risk register with control evidence, and run a monthly Technology Risk Committee that makes real acceptance and funding decisions.