Executive Summary

Overview

This document defines a generalized framework for third-party risk management: the object model, workflows, and data flows required to capture Inherent Risk (IR), Quality of Risk Management (QRM), and Residual Risk (RR) across three levels — the third party, each engagement with that third party, and each risk domain within an engagement. The framework fixes the structures and mechanisms; the scales, weights, thresholds, and rules inside those mechanisms are program parameters, with recommended defaults and implementation guidance provided separately from the framework itself. It is written for a US financial services context and aligned to the 2023 Interagency Guidance on Third-Party Relationships, but the design is not institution-specific.

The central design problem the framework solves is a structural mismatch in third-party risk: risk is engagement-specific, but the vendor relationship is singular. Regulators require due diligence tailored to each specific activity a third party performs; vendors, meanwhile, are one organization with one set of documents, and assessing them repeatedly — once per engagement, each on its own schedule — multiplies cost for the program, burden for the vendor, and inconsistency in the results.

The framework resolves the mismatch by splitting what is assessed from how it is scored. Due diligence is performed once per third party: one document collection, one AI-assisted evaluation of control evidence across the full program catalog, one steward-managed question dialogue covering the union of all engagements’ applicable controls. Ratings are computed per engagement and per risk domain: each engagement’s Inherent Risk Assessment captures the risk characteristics of its specific product/service, and rule-driven scoping determines which controls — and therefore which evaluation results and issues — count toward that engagement’s QRM and Residual Risk. An engagement that requires 25% of the vendor’s evaluated controls is rated on exactly that 25%.

Ratings are living values, not assessment snapshots. Control scores derive from open issues; when a vendor remediates an issue, the affected ratings improve. When an engagement’s risk characteristics change, scoping and ratings recompute — using retained evaluations where they exist, subject to freshness rules and human review — usually without going back to the vendor at all. Every rating carries a full effective-dated history for point-in-time audit and trending.

Benefits

One vendor conversation, engagement-level precision. The vendor experiences a single, consolidated due diligence process on a single clock; the organization gets ratings tailored to each specific activity. This satisfies the regulatory requirement that due diligence be activity-specific while eliminating the duplicate outreach and conflicting reassessment schedules that per-engagement assessment creates.

Assessment effort that compounds instead of repeating. Because AI evaluation runs against the full control catalog — not just currently applicable controls — the marginal cost of evaluating extra controls from documents already in hand is near zero, and the results are banked. When a scope change activates a control, the retained evaluation is used (with steward review): a control already evaluated on still-fresh evidence needs no new vendor outreach at all, unless the banked evaluation found insufficient evidence or found the control ineffective. The same economics apply to growth: adding a new engagement for an existing vendor — a new product or service — engages the vendor only for what fresh, favorable evaluations don’t already cover. The compounding is bounded by the reassessment cycle, since a full reassessment refreshes the entire evidence base; within the cycle, scope changes and new engagements draw on banked work instead of triggering new assessment activity.

Effort proportional to risk. Reassessment cadence follows the vendor’s highest inherent risk tier; oversight intensity and risk-acceptance authority follow engagement criticality and issue severity; controls are evaluated only where engagement characteristics require them. High-risk relationships get more scrutiny, low-risk ones less — with program-defined rules for inherent-risk scoring and control applicability determining which is which.

Defensible, auditable, rules-based ratings. Every rating is produced by systematic, program-defined rules rather than case-by-case judgment: inherent risk is scored from the engagement’s captured risk characteristics; quality of risk management aggregates control evaluations under explicit importance weights and cap rules — including a severe-failure rule that prevents a failed critical control from being averaged away; and residual risk is a transparent lookup of inherent risk against quality of risk management, the construct at the heart of the OCC’s Risk Assessment System. Every rule, weight, cap, and threshold is a versioned, testable parameter an examiner or auditor can inspect, and portfolio-level measures of unaddressed risk show where remediation matters most.

AI leverage with human accountability. AI provides breadth: reading every document against every control, with mandatory source citations and confidence scores. Humans provide judgment: no question reaches the vendor and no rating becomes final without Risk Steward review, and rating recomputations triggered by scope changes require human sign-off. The design anticipates supervisory expectations for model risk management of AI-assisted tools.

Issues managed to resolution, with accountable ownership. Issues track from identification through vendor remediation or formal risk acceptance. Acceptance is decided per affected engagement by its business owner, escalating by severity and criticality — so a shared control failure cannot be silently accepted portfolio-wide by one signature, and a decline in one engagement doesn’t block another’s accepted, documented decision.

Scope

The framework covers the inherent-risk capture that begins in planning, the QRM and residual-risk capture within due diligence, and the rating-maintenance processes that continue through the life of the relationship: issue remediation, scope changes, and scheduled and triggered reassessment. The remainder of planning, contract negotiation, broader ongoing monitoring content, and termination are extension points, positioned within the Interagency Guidance lifecycle but not specified here. Fourth-party risk is handled as a risk domain within the framework rather than a separate structure.

Workflows & Data Flows

Entity and attribute names reference the Object Model section.

Key concepts (full definitions in the Object Model section): a Third Party is the parent of one or more Engagements — the atomic unit of rating. Each engagement’s risk characteristics are captured in a versioned Inherent Risk Assessment (IRA), which drives the engagement’s inherent risk (IR) rating and rule-based scoping of the applicable risk domains and controls. Due diligence runs in a versioned, vendor-level Due Diligence Assessment (DDA) whose AI review evaluates the full control catalog; each control evaluation is active (in at least one engagement’s applicable scope) or latent (evaluated from documents, banked, and unused until a scope change activates it). A vendor’s evidence base is fresh while the last completed full DDA falls within the current reassessment cycle (partial assessment types — incremental, targeted, scope change — do not extend the cycle). Rating calculations and their taxonomy — Quality of Risk Management (QRM), Unmitigated Risk Exposure (URE), and Residual Risk (RR) — are specified in §10.

1. Lifecycle context (thin wrapper)

The Interagency Guidance lifecycle has five stages — Planning, Due Diligence & Third-Party Selection, Contract Negotiation, Ongoing Monitoring, Termination — with governance (oversight & accountability, independent review, documentation & reporting) applied throughout. This framework spans three stages in part: the Inherent Risk Assessment and criticality designation are Planning-stage activities (performed at intake, before third-party selection, and revalidated thereafter); QRM and residual-risk capture live inside Due Diligence & Selection; and the rating-maintenance processes persist into Ongoing Monitoring (issue remediation, scope changes, scheduled and triggered reassessment). The remainder of Planning, Contract Negotiation (beyond the thin Contract anchor for incremental assessments), the broader content of Ongoing Monitoring, and Termination are out of scope and are extension points.

2. Actors

3. Workflow A — Inherent Risk capture (IRA → IR rating)

Triggers: new engagement intake; material change to product/service or its use; periodic revalidation (proposed: business owner re-attests IRA characteristics at each periodic DD assessment — see open point 3).

Steps:

1. Business owner completes IRA version N (risk characteristic values).
2. System calculates, from risk characteristic values: engagement IR score/tier; domain IR scores/tiers (domain IR rules); control applicability (control rules); domain applicability (derived: ≥1 applicable control).
3. Consistency check: any domain with material IR but zero applicable controls → rule-gap flag to Program Office.
4. Criticality designation per program methodology (input to oversight intensity and acceptance escalation).
5. Vendor aggregate IR tier and reassessment cycle recomputed. Retroactive freshness check: if the cycle shortened and the last completed full DD assessment is now overdue, initiate full reassessment immediately.
6. If control applicability changed vs. the prior IRA version → Workflow E (Scope Change Review).
7. If engagement or domain IR score/tier changed but control applicability did not → Calculation Run C (RR recompute). Unlikely, but real — especially when the prior IR score sat near a tier boundary.

flowchart TD
  T1["New engagement intake"] --> IRA
  T2["Material change to product/service"] --> IRA
  T3["Periodic revalidation (at periodic DDA)"] --> IRA
  IRA["Business owner completes IRA vN"] --> C1["Engagement IR score/tier"]
  IRA --> C2["Domain IR scores/tiers (domain IR rules)"]
  IRA --> C3["Control applicability (control rules)"]
  C3 --> C4["Domain applicability (>=1 applicable control)"]
  C2 --> CHK{"Domain IR material but zero applicable controls?"}
  C4 --> CHK
  CHK -- yes --> FLAG["Rule-gap flag to Program Office"]
  C1 --> CRIT["Criticality designation"]
  C1 --> AGG["Recompute vendor aggregate IR tier + reassessment cycle"]
  AGG --> FRESH{"Cycle shortened and last DDA now overdue?"}
  FRESH -- yes --> FULL["Initiate full reassessment (Workflow B)"]
  C3 --> DIFF{"Applicability changed vs prior IRA version?"}
  DIFF -- yes --> SCR["Scope Change Review (Workflow E)"]
  DIFF -- "no, but IR tier changed" --> WC["Calculation Run C: RR recompute"]

4. Workflow B — Due Diligence & QRM capture

Triggers (assessment_type): initial — first engagement with a third party; periodic — reassessment cycle due; triggered — trigger event (§8); incremental — new contract/product introducing newly required controls (scope limited to those not covered by fresh, favorable banked evaluations); scope_change — grouped newly applicable controls from a Scope Change Review (invoked from Workflow E; runs B steps 4–8 only, no freshness reset).

Principles: one assessment per third party covering all engagements; vendor outreach (questions) limited to the union of active applicable controls; AI document review runs against the full program catalog; every AI extraction carries source citations and a confidence score; no vendor outreach and no final rating without Risk Steward review.

Steps:

1. Create DD Assessment version N (type, scope).
2. Collect vendor documents (SOC 2 reports, certifications, policies, business continuity / disaster recovery (BC/DR) plans, etc.).
3. AI extraction against full control catalog → draft evaluations (ai_drafted) with evidence citations + confidence.
4. Per control, the AI derives a draft control effectiveness rating where the evidence supports one:
   • Active control, draft rating Effective → evaluation stands for steward review.
   • Active control, draft rating Partially Effective / Ineffective — or evidence insufficient to support any rating → system drafts residual questions (not yet sent).
   • Latent control → draft evaluation (or no-evidence record) banked; no vendor outreach, no questions drafted.
5. Risk Steward gate: steward reviews the AI output and the drafted question set — approves, edits, drops, or adds questions — before anything goes to the vendor.
6. Iterative vendor Q&A: steward sends approved residual questions plus any general clarifications; vendor answers; evaluations updated; steward follows up as needed until evidence is judged complete.
7. Steward finalizes review and scoring of all active evaluations (steward_reviewed → final). Latent evaluations retained as drafts.
8. Ineffective/absent active controls → Issues opened (severity rating; issue lifecycle in Workflow D) → deficiency_score derived from open issue severity (steward override with rationale).
9. Calculations (full definitions in §10): per control — deficiency score derived from the control’s open issues’ severity ratings, and URE contribution (deficiency score × importance weight); per engagement — domain QRM (sum of active applicable controls’ URE contributions, normalized; uncapped severe failures can force Weak/Insufficient), engagement QRM (blend-then-cap over domain tiers), and domain/engagement URE (raw sums; controls counted once at engagement level); then Calculation Run C (RR).
10. Vendor aggregates: worst engagement rating for IR/QRM/RR; URE sum.
11. DD Assessment finalized: status → complete; completed_date set — anchoring freshness — and DDA version N memorialized, so every rating snapshot from this run references it in computed_from.

flowchart TD
  TRG["Trigger: initial | periodic | triggered | incremental | scope_change"] --> DDA["Create DD Assessment vN"]
  DDA --> DOCS["Collect vendor documents"]
  DOCS --> AI["AI extraction vs FULL control catalog (citations + confidence per extraction)"]
  AI --> SUFF{"Draft control effectiveness rating per control"}
  SUFF -- "ACTIVE + Effective" --> DRAFT["Draft evaluation (ai_drafted)"]
  SUFF -- "ACTIVE + Partially Effective / Ineffective / unratable" --> DRQ["System drafts residual questions (unsent)"]
  SUFF -- "LATENT" --> LAT["Bank latent evaluation (no vendor outreach)"]
  DRAFT --> GATE
  DRQ --> GATE["Risk Steward gate: review AI output + question set (approve / edit / add / drop)"]
  GATE --> NEEDQ{"Questions to send?"}
  NEEDQ -- yes --> SEND["Steward sends residual questions + clarifications"]
  SEND --> ANS["Vendor answers"] --> UPD["Evaluations updated"] --> MOREQ{"Follow-ups needed?"}
  MOREQ -- yes --> SEND
  MOREQ -- no --> RS
  NEEDQ -- no --> RS["Steward final scoring (steward_reviewed -> final; active controls only)"]
  RS --> EFF{"Control effective?"}
  EFF -- "no (active)" --> ISS["Open Issue (severity rating) → Workflow D"]
  ISS --> SCORE["deficiency_score from open issue severity (steward override w/ rationale)"]
  EFF -- yes --> SCORE
  SCORE --> DQRM["Domain QRM per engagement (normalized weighted deficiency; severe-failure forcing)"]
  DQRM --> EQRM["Engagement QRM (blend then cap)"]
  SCORE --> URE["URE scores (raw sums; control counted once)"]
  DQRM --> RRC["Calculation Run C: Residual Risk"]
  EQRM --> RRC
  RRC --> VAGG["Vendor aggregates: worst ratings; URE sum"]
  VAGG --> DONE["DDA finalized: completed_date set (anchors freshness); version memorialized in rating snapshots"]

5. Calculation Run C — Residual Risk determination

Not a workflow but a system calculation run, kept separate because multiple workflows invoke it. There is no vendor, human, or AI interaction — it is a call to execute a calculation over current inputs, with results snapshotted.

1. Domain RR per engagement: matrix lookup — domain IR tier offset by domain QRM rating.
2. Engagement RR: matrix lookup — engagement IR tier offset by engagement QRM rating. (Variant: worst domain RR.)
3. Vendor aggregate RR: worst engagement RR.

Why the matrix uses the QRM rating, not raw URE: the QRM rating is the importance-weighted unmitigated-exposure measure — normalized to the engagement’s applicable scope and banded, which is what makes it usable as a matrix axis. Raw URE is deliberately unbanded and scope-sensitive: two engagements with identical management quality but different scope breadth would land in different matrix rows. URE’s job is prioritization, trending, and vendor-level aggregation; the QRM rating carries the same importance weighting into the RR lookup.

Recompute triggers:

All recomputed ratings are point-in-time snapshotted in Engagement Domain Result (domain level) and Engagement Rating Result (engagement level), each recording computed_from (IRA version + DDA version), for audit and trending.

6. Workflow D — Issue management & risk acceptance

Workflow D manages an issue from creation through vendor remediation or formal risk acceptance, and drives rating recomputation as issue state changes (Calculation Run C).

Steps:

1. Issue opened on an ineffective or absent active control — from Workflow B, a Scope Change Review, or a risk event demonstrating control failure (e.g., data breach, regulatory action; typically routed through trigger triage, §8). Severity rating assigned and steward-confirmed.
2. Vendor asked for a remediation plan.
3. Plan received → remediation execution tracked to completion → Risk Steward validates remediation → issue closed; scores recompute (Calculation Run C).
4. Vendor refuses, abandons, or fails remediation → risk acceptance required: one acceptance decision per affected engagement, with accepting authority per the severity-by-criticality escalation matrix.
5. Per-engagement decisions aggregate to the issue-level status: Pending Risk Acceptance while any affected engagement has neither accepted nor declined; Accepted when all accept; Declined when all decline; Partially Accepted when some accept and some decline.
6. Accepted risk (full or partial) is revalidated at each periodic DDA; a failed revalidation or changed risk reopens the issue.
7. Declining engagements follow the do-not-sign / exit-or-remediate path for the declining engagement(s) only — other engagements’ acceptances stand. If the vendor subsequently remediates, the issue returns to Remediating; when all declining engagements have exited, the issue closes (if fully Declined) or converts to Accepted (if Partially Accepted), closing the workflow.

stateDiagram-v2
  [*] --> Open : ineffective/absent ACTIVE control
  [*] --> Open : risk event shows control failure (breach, regulatory action)
  Open --> PlanRequested : vendor asked for remediation plan
  PlanRequested --> Remediating : plan received, execution tracked
  PlanRequested --> PendingRiskAcceptance : vendor refuses
  Remediating --> Remediated : validated by Risk Steward
  Remediating --> PendingRiskAcceptance : abandoned / refused
  PendingRiskAcceptance --> Accepted : all affected engagements accept
  PendingRiskAcceptance --> Declined : all affected engagements decline
  PendingRiskAcceptance --> PartiallyAccepted : some accept, some decline
  Accepted --> Open : periodic revalidation fails / risk changes
  Declined --> Remediating : vendor agrees to remediate
  Declined --> Closed : all declining engagements exit
  PartiallyAccepted --> Accepted : declining engagements exit or drop from scope
  PartiallyAccepted --> Remediating : vendor agrees to remediate
  Remediated --> Closed
  Closed --> [*]

Acceptance rules: one Issue → one Issue–Engagement Acceptance row per affected engagement (engagements whose scope includes the deficient control). Accepting authority per severity-by-criticality escalation matrix: default engagement business owner; high-severity issues on critical engagements escalate to senior committee/board. The issue-level status is an aggregate function of the per-engagement decisions — Pending Risk Acceptance (any undecided), Accepted (all accept), Declined (all decline), Partially Accepted (mixed) — and a decline forces remediation or exit only for the declining engagement(s); other engagements’ acceptances stand. When a scope change adds a newly affected engagement (Workflow E), an Accepted issue reverts to Pending Risk Acceptance until the new engagement decides. Accepted risks are revalidated at each periodic DD assessment. Acceptance is a governance disposition, not a risk reduction: accepted issues remain open for scoring purposes and continue to contribute to the control’s deficiency score — QRM and residual risk improve only through remediation. Issue state changes recompute scores per Calculation Run C.

7. Workflow E — Scope Change Review

Runs when an IRA change makes one or more controls newly applicable to an engagement (invoked from Workflow A).

Steps:

1. All controls made newly applicable by the IRA change are grouped into a single Scope Change Due Diligence Review — one review and, where needed, one vendor conversation, regardless of how many controls changed.
2. Freshness gate: if the vendor’s last completed full DDA now falls outside the current reassessment cycle, stop — a full reassessment (Workflow B) runs instead. Otherwise the review is recorded as a DDA version of type scope_change (covering only the grouped controls; no freshness reset).
3. Per control, branch on its evaluation status in the latest DDA:
   • Activate (latent): the control enters Workflow B’s evidence pipeline — the system drafts residual questions where the draft rating is below Effective or unratable (B step 4), then the Risk Steward gate, iterative vendor Q&A, and final scoring, through issue creation (B steps 5–8) — stopping before ratings are calculated.
   • Extend (active for other engagements):
     • Control effective (including previously remediated) → no work until recalculation.
     • Control not effective, issue in open remediation → the engagement is added to the issue’s affected set; remediation tracking continues (Workflow D).
     • Control not effective, risk accepted → engagement-level acceptance initiates for this engagement (Workflow D), and the issue’s aggregate status reverts to Pending Risk Acceptance until decided. Contract-leverage variant: where a new contract is in flight, use it to press the third party to remediate before permitting business-owner acceptance.
4. When activation and extension complete for all grouped controls, calculations pick up as in Workflow B: affected domain and engagement QRM, URE, and RR recompute (Calculation Run C) — without DDA finalization; the freshness clock is not reset.
5. Human review — Risk Steward plus engagement business owner — before the recomputed ratings are finalized and snapshotted.

flowchart TD
  A["IRA vN: newly applicable control(s)"] --> G["Group into one Scope Change DD Review"]
  G --> FRESH{"Last FULL DDA within current cycle?"}
  FRESH -- "overdue" --> FULL["Full reassessment instead (Workflow B)"]
  FRESH -- "fresh" --> B{"Per control: evaluation status in latest DDA"}
  B -- "latent" --> ACT["Activate: enter Workflow B pipeline (question drafting, steward gate, vendor Q&A, scoring, issues — B steps 4-8)"]
  B -- "active elsewhere" --> EFF2{"Control effective?"}
  EFF2 -- "yes (incl. remediated)" --> WAIT["No action until recalculation"]
  EFF2 -- "no - open remediation" --> ASSOC["Add engagement to issue's affected set (Workflow D)"]
  EFF2 -- "no - risk accepted" --> ACC["Initiate engagement acceptance (Workflow D); contract-leverage variant: press remediation first"]
  ACT --> JOIN["All grouped controls complete"]
  WAIT --> JOIN
  ASSOC --> JOIN
  ACC --> JOIN
  JOIN --> RECOMP["Recompute domain/engagement QRM, URE, RR (Calculation Run C)"]
  RECOMP --> REV["Human review: Risk Steward + business owner"]
  REV --> FIN["Finalize ratings (snapshot) - freshness clock not reset"]

Notes: activation never extends the parent assessment’s completed_date. Because AI review covers the full catalog, every catalog control has at least a latent evaluation after any completed DDA. Controls that become inapplicable simply drop out of the applicable set at recompute (their evaluations revert to latent — evidence retained). One case falls outside this workflow: a control added to the program catalog after a vendor’s latest DDA has no evaluation to activate. Handling it requires a program-wide new-control introduction workflow — at minimum, running AI evaluation of the new control against every active third party’s already-collected documents, then choosing whether the control becomes active for applicable engagements at the point of introduction or only at each vendor’s next assessment. A full recommendation for that workflow is beyond the scope of this document.

8. Reassessment scheduling & trigger taxonomy

Cadence: reassessment cycle assigned from vendor aggregate IR tier (program parameter; e.g., High = 1 yr, Medium = 2 yr, Low = 3 yr, De Minimis = longer at program discretion). One vendor-level clock; next_reassessment_due = last completed DDA + cycle, recomputed on any aggregate IR tier change (with retroactive freshness check).

Trigger triage: every trigger event routes first to Risk Steward triage. The steward reviews the trigger condition and disposes: whether to initiate vendor outreach at all; whether to initiate a full or targeted re-evaluation of controls (triggered DDA); or whether to open an issue to track the condition without reassessment. The table gives typical dispositions, not automatic actions.

When the steward initiates a re-evaluation, AI review still runs full-catalog (documents are already in hand); vendor outreach is what gets scoped.

9. Data flow summary

flowchart LR
  subgraph PC["Program catalogs & parameters"]
    RC["Risk characteristics"]
    RUL["Applicability + domain IR rules"]
    CTL["Control catalog (importance, severe-failure flags)"]
    MAP["Control-domain mapping"]
    PAR["Scales, bands, caps, RR matrices, cadence"]
  end
  IRAV["IRA characteristic values (per engagement, versioned)"] --> RUL
  RUL --> APP["Control + domain applicability (per engagement)"]
  RUL --> IRT["Engagement + domain IR scores/tiers"]
  DOC["Vendor documents"] --> AIE["AI evaluation pipeline"]
  CTL --> AIE
  AIE --> CE["Control evaluations (full catalog; active/latent)"]
  APP --> CE
  CE --> ISS["Issues (active controls)"] --> DS["Deficiency scores"]
  CE --> DS
  DS --> QRM["Domain + engagement QRM"]
  MAP --> QRM
  DS --> URE["URE scores"]
  IRT --> RR["Domain + engagement RR (matrix)"]
  QRM --> RR
  QRM --> VA["Vendor aggregates (worst ratings; URE sum)"]
  RR --> VA
  URE --> VA
  IRT --> CAD["Reassessment cycle + freshness"]
  PAR --> QRM
  PAR --> RR
  PAR --> CAD

10. Calculation summary (normative defaults)

Engagement QRM aggregation — detailed specification (normative default). The algorithm is blend, then cap, take the worst.

Inputs, for each risk domain d applicable to engagement e:

• R(d) — the domain’s normalized deficiency ratio: Σ URE contributions of the domain’s active applicable controls ÷ Σ those controls’ maximum standard deficiency points × importance weight. Uncapped severe-failure scores inflate the numerator only, so a single catastrophic control can push R(d) past any band boundary.
• Q(d) — the domain’s QRM rating, banded from R(d) on the QRM scale thresholds (program parameters).
• T(d) — the domain’s importance tier (High / Medium / Low, from the Risk Domain catalog; overridable by engagement type), with tier weights w(T): suggested 3 / 2 / 1.
• S(d) — the domain’s size: Σ importance-weighted maximum standard points of its active applicable controls (the denominator of R(d)).

Steps:

1. Blend: candidate ratio R(e) = Σ [ w(T(d)) × S(d) × R(d) ] ÷ Σ [ w(T(d)) × S(d) ], over all applicable domains.
2. Band: candidate rating from R(e) using the QRM scale thresholds (illustrative: R < 0.10 → Strong; < 0.25 → Satisfactory; < 0.50 → Insufficient; ≥ 0.50 → Weak).
3. Caps (each a condition → maximum-aggregate-rating rule in a parameter table):
   • Aggregate QRM cannot be better than the worst High-importance domain rating. (Hard cap — the non-negotiable rule.)
   • One Weak Medium-importance domain caps the aggregate at Insufficient; two or more Medium domains at Insufficient-or-worse also cap at Insufficient.
   • Low-importance domains never cap alone; two or more Weak Low domains cap at Satisfactory.
4. Final rating = worst of the banded candidate and all triggered caps.
5. Snapshot to Engagement Rating Result with computed_from (Calculation Run C).

Worked example (all numbers illustrative):

R(e) = (3·100·0.12 + 2·60·0.30 + 1·40·0.55) ÷ (3·100 + 2·60 + 1·40) = (36 + 36 + 22) ÷ 460 ≈ 0.204 → candidate Satisfactory. Caps: worst High domain is Satisfactory (no effect — candidate is not better than it); one Medium domain at Insufficient but none Weak and only one (no cap); one Weak Low domain, but two are required (no cap). Final: Satisfactory. Had Security rated Insufficient, the hard cap would force the aggregate to Insufficient regardless of the blend — that is the cap system doing its job.

Cap rules live in a parameter table so programs tune conditions and thresholds without changing the algorithm — and so auditors can test them. Documented variants: worst-domain-only; pure weighted blend without caps.

All scales (IR tiers, control rating scale, issue severity points, QRM bands, domain importance tiers) are program parameters with the defaults above.

Implementation Recommendations

Positioning: everything in this section is a recommendation for the detailed implementation of framework components, not part of the generalized framework. A program can adopt the framework and implement these components differently; these represent current (2026) leading practice for a US financial services context.

1. AI-assisted evidence extraction and control evaluation

The framework requires that due diligence collect vendor documents, evaluate control evidence against the full program catalog, generate vendor questions only for applicable controls with insufficient/weak evidence, and finalize nothing without Risk Steward review. Recommendations for implementing that pipeline:

1.1 Extraction discipline. Every AI-extracted evidence item must carry (a) a citation to source document, page/section, and (b) a confidence score. Route by exception: high-confidence extractions are fast-tracked to steward confirmation; low-confidence and high-importance-control extractions get full steward scrutiny. Ground extraction strictly in the collected document set (retrieval-based), never on model general knowledge; log every AI determination in an audit trail. This citation + confidence + exception-routing pattern is the de facto standard in current third-party risk management (TPRM) platforms (ProcessUnity Evidence Evaluator, Bitsight, Whistic, Conveyor, Vanta), and industry guidance stresses human oversight at key decision points (Shared Assessments).

1.2 Deterministic checks for what LLMs fumble. Extract SOC 2 structured metadata with deterministic parsing (or mandatory steward checklist), not LLM interpretation: report scope and system boundary (is the system you use actually in scope?); audit period vs. reliance date (SOC reports are point-in-time; stale periods create false assurance); opinion type and exceptions; carve-out subservice organizations (a “clean” SOC 2 with your critical dependency carved out is not clean for you); complementary user entity controls (CUECs — control effectiveness conditional on your organization performing its part; route CUECs to internal control owners). Published critiques of SOC 2-only review document exactly these failure modes (Rivial Security).

1.3 Sampling QA. Periodically re-review a random sample of AI-drafted evaluations end-to-end by a human without sight of the AI output; measure and trend disagreement rates by control domain and document type. Falling steward-edit rates are not evidence of AI accuracy — they may be evidence of steward over-trust. The sampling program is the control on the control.

1.4 Model risk management. Treat the extraction tool as a model or model-adjacent under the bank’s model risk management (MRM) framework — or, where the organization has stood up a separate generative-AI risk domain, under that framework: either way, inventory it, document conceptual soundness, validate independently, and monitor ongoing performance. Note the April 2026 revised interagency MRM guidance (OCC Bulletin 2026-13) explicitly deferred generative AI, with an interagency RFI pending — so document to SR 11-7-style expectations now and flag genAI-specific guidance as an open regulatory item. Steward review is a compensating control, not a substitute for validation. Include LLM-specific validation: output-variance testing across runs, prompt-injection resistance (vendor documents are untrusted input), and guardrail testing.

1.5 The tool is itself a third party. Per the Interagency Guidance (fn. 7), an external assessment service or utility is a business arrangement belonging in the TPRM inventory. If the AI evaluation capability is vendor-supplied, it must go through this very framework.

2. Scoring and aggregation defaults

All scales are program parameters; recommended defaults:

These scales are highly customizable — the program document must say so explicitly. The RR matrix pattern (2.2) is industry standard, but everything in the table above and every point value in 2.1 is a program choice. Issue severity, for example, may be an ordinal 1–4 (1 most severe) or a weighted scale like 100/50/10/1 where the values themselves carry the deficiency arithmetic. The framework fixes the mechanisms — normalized weighted deficiency, severe-failure forcing, blend-then-cap, matrix lookup; every scale and constant inside those mechanisms is a parameter.

2.1 Deficiency points. Map issue severity to deficiency points per open issue (illustrative: severity 1 = 8 pts, 2 = 4, 3 = 2, 4 = 1); a control’s URE contribution is its deficiency score × importance weight (weight applied at aggregation, not inside the deficiency score). Severe-failure-eligible controls scored uncapped: calibrate the severity-1 point value so a single total failure of a high-importance control pushes the domain’s normalized score past the Weak boundary regardless of domain size. Document the uncapped mechanism explicitly as the severe-failure forcing rule so auditors can test it. The point values here are illustrative calibrations, not framework constants — tune them against portfolio backtesting.

2.2 Residual risk matrix. Illustrative default, consistent with the industry convention that strong controls move residual at most 1–2 levels below inherent and weak controls leave residual ≈ inherent:

Any program-configured matrix must satisfy two validity constraints, enforced as parameter-validation rules: residual risk never exceeds inherent risk (controls can only offset risk — their absence or failure leaves inherent risk intact, it does not add to it), and the matrix is monotonic (residual never decreases as inherent risk rises, and never increases as QRM improves). Two consequences under the first constraint: the De Minimis-IR row is uniformly De Minimis (nothing can take residual below the floor tier, and nothing may raise it above inherent), and the Insufficient and Weak columns converge — the distinction between them still drives issue severity, escalation, and reporting even where the residual tier coincides.

2.3 QRM semantics note (include in the program document). The QRM rating used throughout is importance-weighted — it measures unmitigated exposure relative to the engagement’s applicable scope, which is the common industry usage for offsetting inherent risk. This deliberately differs from the strict OCC RAS definition of quality of risk management as independent of quantity of risk; in examiner practice, deficiency materiality weighting is standard, so the deviation is defensible — but state it. Note also that the framework retains the strict OCC RAS sense at the control level: the control effectiveness rating (Effective / Partially Effective / Ineffective — the audit convention) is deliberately importance-independent, so quality in the regulatory sense is captured there, before importance weighting enters at aggregation.

2.4 URE reporting. Report URE (raw importance-weighted deficiency sums, controls counted once at engagement/vendor level) alongside ratings: vendor-level URE is the portfolio’s best “where does the most unaddressed risk live” ranking, and its trend is a program effectiveness metric. Never band URE or use it in the RR matrix.

3. Control catalog and applicability rules

3.1 Catalog sourcing. Anchor the Security/Resiliency portions to the Shared Assessments SIG (Standardized Information Gathering) content library (maps to 31 frameworks including NIST CSF, ISO 27001, DORA), which also gives vendors a familiar questionnaire dialect. The Financial (viability) and much of the Compliance domain sit outside SIG’s scope — source those from financial-analysis practice and regulatory obligations respectively. Define domains at the lowest level at which the program rates, with a domain_category attribute grouping them for reporting (the category may earn its own object later; the framework doesn’t require it). The domains named in this document — Security, Business Resiliency, Financial, Compliance — are examples, not a taxonomy: programs commonly add Privacy, HR, ESG, Fourth-Party Management, and others, and organizations group domains differently.

3.2 Rule design. Model applicability rules on the Shared Assessments TPSIRR (Third-Party Service Inherent Risk Rating) pattern (inherent-risk “areas of impact” → domains/controls): rules must be versioned, individually testable, and owned by the Program Office. Every rule change re-runs applicability for affected engagements (→ Scope Change Review). Run the domain-IR-without-controls consistency check (Object Model §2) after every rule change, not just every IRA. Criticality-driven assessment scoping in NIST SP 800-161r1 applies the same principle at supply-chain scale.

3.3 Importance weight governance. Importance weights are the highest-leverage parameters in the entire calculation chain. Set them by domain-expert panel, document rationale per control, review annually, and version changes — a weight change silently re-rates every engagement using that control. Documented option (Object Model §3 variant): each domain sets its own importance weight for a shared control; that domain’s QRM/URE uses its own weight, while engagement-level QRM/URE uses the highest applicable weight for the control.

4. Due diligence positioning (examiner-readiness)

4.1 Write the vendor-level DD section defensively. The Interagency Guidance requires due diligence “tailored to the specific activity.” The framework complies — the vendor-level assessment is the union of activity-tailored scopes, engagement applicability drives every rating, and new activities trigger incremental assessment — but the program document must say so explicitly, because “one assessment per vendor” pattern-matches to the entity-level-review shortcut the guidance rejects. The agencies illustrate the expectation concretely: a bank buying a new service from its existing core provider performs fresh, service-specific due diligence (Community Bank Guide, May 2024). Note that none of the major platforms whose public documentation was reviewed for this section — Archer, ServiceNow, ProcessUnity, OneTrust, Prevalent, Aravo, Venminder — implements this hybrid out of the box: Archer and ServiceNow generate assessments per engagement, assessment exchanges apply vendor-level results uniformly, and Venminder documents the examiner expectation of product/service-level assessment. At the same time, every reviewed platform already implements substantial pieces of this framework — engagement-level inherent risk, rule-driven assessment scoping, issue management, vendor-level document collection — and several are configurable enough that the framework could plausibly be implemented on the current application through configuration alone, without waiting for vendor product changes. Expect custom configuration rather than custom development, and validate the scoping logic accordingly.

4.2 Documentation set per assessment: retain documents, extractions with citations, question threads, steward decisions and overrides, issues with remediation plans and “quality and sustainability” evidence (guidance language), acceptance records with authority chain, and the ratings history records — this is the examiner narrative from evidence to rating.

4.3 Fourth parties — treat as a Risk Domain. Fourth-party risk is a Risk Domain in the program catalog: controls evaluate the vendor’s own third-party oversight (cf. the SIG “Nth Party Management” domain), with applicability driven by IRA characteristics like any other domain, and it participates in QRM/URE/RR the same way. Dedicated fourth-party objects (subcontractor inventory) remain a later extension; the domain treatment ensures the risk is rated now.

5. Governance recommendations

Complete third-party inventory with criticality flags is the precondition for everything above; document the criticality-designation methodology separately from IR tiering. Provide board/committee reporting on: worst-rated vendors, aggregate URE trend, vendors supporting multiple critical activities (concentration), overdue reassessments, aging open issues, and accepted risks by authority level. Subject the TPRM process itself to periodic independent review. Maintain a terminology map (“third party” = “vendor”; “engagement” = the guidance’s “business arrangement/activity” level) in the program glossary.

References

Each reference is linked inline at the specific claim it supports; this list consolidates them.

Regulatory and supervisory

• Interagency Guidance on Third-Party Relationships: Risk Management (June 2023)
• Third-Party Risk Management: A Guide for Community Banks (May 2024)
• SR 11-7 — Guidance on Model Risk Management
• OCC Bulletin 2026-13 — revised interagency Model Risk Management guidance
• OCC Bulletin 2015-48 — RAS quality-of-risk-management scale

Standards and industry guidance

• Shared Assessments SIG and TPSIRR inherent risk rating
• Shared Assessments — AI and TPRM
• NIST SP 800-161r1 (C-SCRM)

Platform and practice references

• ProcessUnity AI-Based Control Reviews
• Bitsight — AI questionnaire and document automation
• Whistic AI features
• Conveyor — AI agents for security questionnaires
• Vanta — questionnaire automation
• Archer TPRM
• ServiceNow TPRM data foundations
• Venminder — assessing vendors’ products and services
• Aravo — inherent vs. residual risk
• Rivial Security — beyond SOC 2-only reviews

Object Model

Terminology: “Third Party” per the Interagency Guidance; “Vendor” retained as a permitted synonym in the glossary.

This object model is a sketch: it defines the base objects, their key attributes, and their relationships — it is not a comprehensive data dictionary. Convention: every object is introduced by a heading and an attribute table (even a minimal one); anything without an attribute table is behavior, a rule, or a note — not an object. Relationship notation: 1:N — one-to-many (one parent record, many child records); M:N — many-to-many (realized through a junction entity); 1:1 — one-to-one. The Entity-Relationship Diagram (§9) renders the same relationships in crow’s-foot notation. Acronyms used throughout: inherent risk (IR), Quality of Risk Management (QRM), Unmitigated Risk Exposure (URE), residual risk (RR), Inherent Risk Assessment (IRA), Due Diligence Assessment (DDA), personally identifiable information (PII).

1. Core hierarchy

Third Party

The legal entity with which the organization has one or more business arrangements. Parent of Engagements (1:N).

Engagement

One or more closely related products/services from a Third Party (e.g., SaaS software + hosting + support). The atomic unit for inherent risk, applicability scoping, QRM, and residual risk.

Contract (thin entity)

Child of Third Party (1:N); M:N with Engagements. Deliberately thin in this framework — it anchors the incremental-assessment trigger (new contract for new product/service) and will carry more weight in lifecycle stages (contract negotiation, termination) not built out here.

Footnote (one product/service per engagement variant): A program may enforce one product/service per engagement. This makes risk-characteristic capture more granular, improving analysis and risk management, but multiplies the number of engagements and the management workload. This framework treats the engagement as atomic either way.

2. Inherent risk capture

Inherent Risk Assessment (IRA)

Versioned questionnaire per engagement capturing risk characteristics (Workflow A). Only one version is current per engagement. A new version (material change in characteristics) re-runs applicability scoping — → Workflow E if applicability changes; → Calculation Run C if only IR tiers change — and may fire reassessment triggers (Workflows §8).

Risk Characteristic (program catalog)

Program-defined characteristics: data confidentiality, PII type, customer interaction, financial transaction processing, criticality of supported internal processes/products, etc.

IRA Characteristic Value (association entity)

One record per IRA version and Risk Characteristic: the captured value. Inputs to all applicability and IR calculations.

Risk Characteristic Rules (program catalog)

Business rules over IRA risk characteristic values. Two separate rule sets operating on the same input attributes:

• Control applicability rule: predicate over characteristic values → Control applicable (y/n) for the engagement (drives scoping — Workflow A).
• Domain IR rule: predicate/formula over characteristic values → domain-level IR score/tier for the engagement.

Domain applicability is derived, not rule-set: a Risk Domain is applicable to an engagement iff at least one control mapped to that domain is applicable. (Because controls map M:N to domains, one applicable control activates every domain it maps to.) Note the distinction: domain applicability has no rules of its own; domain IR ratings do (the domain IR rule set above).

Consistency check (recommended): flag any domain whose computed IR score exceeds a threshold but which has zero applicable controls. That combination indicates a gap in the control applicability rules — risk identified with nothing evaluating it — not a genuinely inapplicable domain. Run after every IRA change and every rule change (Implementation Recommendations §3.2).

3. Control catalog

Risk Domain (program catalog)

Domains are defined at the lowest level at which the program rates (QRM/URE/RR). Example domains — Security, Business Resiliency, Financial, Compliance, Privacy, HR, ESG, Fourth-Party Management — are illustrative, not a taxonomy; organizations group domains differently.

Control (program catalog)

The full list of controls the program evaluates across all product/service types.

Control–Domain Mapping (junction entity)

M:N. One control may map to multiple risk domains.

URE counting rule: a control mapped to two applicable domains contributes its deficiency points to both domains’ QRM and URE — correct, since it weakens both domains. But engagement- and vendor-level URE sums each control evaluation once (sum over controls, not over domain sums), so the metric measures unaddressed risk rather than mapping fan-out. This is a single framework-level rule applied uniformly to all calculations — fixed behavior, not a configurable rule set.

Engagement Control Applicability (derived, versioned)

One record per engagement–control pair, computed from the current IRA version via the control applicability rules (Workflow A). The union of these rows across a Third Party’s engagements defines the active scope of due diligence questioning (Workflow B).

Scope Change Review (Workflow E): when an IRA change makes controls newly applicable to an engagement, they are grouped into a single Scope Change Due Diligence Review, recorded as a scope_change DDA version. Latent evaluations are activated through Workflow B’s evidence pipeline; already-active evaluations extend to the engagement, with issue association and acceptance handling per Workflow D. Ratings are recomputed at the close of Workflow E (Calculation Run C), with Risk Steward + business owner review before finalization.

Engagement Domain Result (derived, append-only history)

One record per engagement–domain pair per computation. Every recompute (Calculation Run C) closes the current record (sets effective_to) and appends a new one — the historical record of all domain-level ratings over time.

Engagement Rating Result (derived, append-only history)

Engagement-level analogue of the domain result, on the same append-on-recompute pattern (recomputes fire from Calculation Run C on issue state changes, new IRA versions, Scope Change Review finalization, and DDA completion). The current-rating attributes on Engagement (§1) are a projection of the is_current record. Vendor-level aggregates are derivable at any historical date from these records; programs may optionally materialize a Vendor Rating Result on the same pattern for reporting performance.

4. Due diligence

Due Diligence Assessment (vendor-level container, versioned)

Point-in-time assessment of the Third Party (process: Workflow B). One assessment covers all engagements (union of applicable controls); AI document review runs against the full program catalog.

Document

Vendor evidence artifact attached to a DD Assessment (collected in Workflow B, step 2).

(Implementation recommendation: deterministic extraction of SOC 2 scope, audit period, carve-outs, CUECs, and opinion — Implementation Recommendations §1.2.)

Control Evaluation

Child of DD Assessment; one per control in the full program catalog (the full-catalog AI review is a framework rule — Workflow B).

Latent-evaluation lifecycle: when an IRA change makes a latent control applicable, the evaluation is activated through Workflow B’s evidence pipeline within a Scope Change Review (Workflow E; recorded as a scope_change DDA version): residual questions may be drafted and issues generated, and affected engagements’ QRM/URE/RR are recomputed at the close of Workflow E — subject to the freshness rule (a scope-change review never extends the freshness clock; if the vendor’s cycle has shortened and the last full assessment is now overdue, a full reassessment fires instead). Recomputed ratings are not finalized without human review.

Evidence Citation (association entity)

One record per evidence item linking a Control Evaluation to its source Document. Every AI-extracted evidence item must cite its source location (Workflow B step 3; Implementation Recommendations §1.1).

Residual Question

Child of Control Evaluation — system-drafted only for active controls whose draft effectiveness rating is below Effective or unratable; gated, edited, and sent by the Risk Steward (Workflow B, steps 4–6).

5. Issues and risk acceptance

Issue

Child of Control Evaluation (1:N); opened only on active controls where the vendor’s process for the control is ineffective or absent, or where a risk event (e.g., data breach, regulatory action) demonstrates that the control failed. Lifecycle and acceptance aggregation: Workflow D.

Issue–Engagement Acceptance

One Issue can affect every engagement whose scope includes the deficient control. Acceptance is per engagement.

Score linkage (normative): a control evaluation’s deficiency_score is calculated from its open issues’ severity points; the Risk Steward may override with documented rationale. Consequence worth stating explicitly: when an issue is remediated and closed, the control’s deficiency_score — and the affected domain/engagement QRM, URE, and RR — recompute, so ratings improve as remediation completes and degrade if new issues open. Risk-accepted issues remain open for scoring and continue to contribute deficiency points: acceptance is a governance disposition, not a risk reduction. Ratings are living values anchored to issue state, not frozen assessment outputs.

6. Reassessment triggers

Reassessment Trigger Event

Logged event against a Third Party (or Engagement) that may initiate assessment activity outside the cycle. Every trigger routes through Risk Steward triage; the trigger taxonomy and typical dispositions are specified in the Workflows section, §8.

7. Calculations

All rating and scoring calculations — the control-level taxonomy (effectiveness rating, deficiency score, URE contribution) through domain and engagement QRM, URE, residual risk, and vendor aggregates — are specified in the Calculation summary within the Workflows & Data Flows section. The object model records their outputs in Engagement Domain Result and Engagement Rating Result (§3).

8. Actors (roles, not modeled as entities)

Risk Steward (reviews/scores control evaluations); Engagement Business Owner (owns IRA input, risk acceptance); Senior committee/Board (escalated acceptances, reporting); TPRM Program Office (catalogs, rules, methodology); Vendor contact (documents, question responses).

9. Entity-Relationship Diagram

erDiagram
    THIRD_PARTY ||--o{ ENGAGEMENT : "parent of"
    THIRD_PARTY ||--o{ DUE_DILIGENCE_ASSESSMENT : "assessed by (versioned)"
    THIRD_PARTY ||--o{ REASSESSMENT_TRIGGER_EVENT : "logged against"
    THIRD_PARTY ||--o{ CONTRACT : "party to"
    CONTRACT }o--o{ ENGAGEMENT : "covers"

    ENGAGEMENT ||--o{ INHERENT_RISK_ASSESSMENT : "captures risk via (versioned)"
    INHERENT_RISK_ASSESSMENT ||--o{ IRA_CHARACTERISTIC_VALUE : "records"
    RISK_CHARACTERISTIC ||--o{ IRA_CHARACTERISTIC_VALUE : "valued in"
    RISK_CHARACTERISTIC ||--o{ RISK_CHARACTERISTIC_RULE : "input to"
    RISK_CHARACTERISTIC_RULE }o--o| RISK_DOMAIN : "targets (domain IR rating rules only)"
    RISK_CHARACTERISTIC_RULE }o--o| CONTROL : "targets (control applicability rules)"

    CONTROL ||--o{ CONTROL_DOMAIN_MAPPING : "mapped via"
    RISK_DOMAIN ||--o{ CONTROL_DOMAIN_MAPPING : "mapped via"
    ENGAGEMENT ||--o{ ENGAGEMENT_CONTROL_APPLICABILITY : "scoped by"
    CONTROL ||--o{ ENGAGEMENT_CONTROL_APPLICABILITY : "in scope via"
    ENGAGEMENT ||--o{ ENGAGEMENT_DOMAIN_RESULT : "rated per domain"
    RISK_DOMAIN ||--o{ ENGAGEMENT_DOMAIN_RESULT : "result for"
    ENGAGEMENT ||--o{ ENGAGEMENT_RATING_RESULT : "rating history"

    DUE_DILIGENCE_ASSESSMENT ||--o{ DOCUMENT : "collects"
    DUE_DILIGENCE_ASSESSMENT ||--o{ CONTROL_EVALUATION : "produces (full catalog)"
    CONTROL ||--o{ CONTROL_EVALUATION : "evaluated by"
    CONTROL_EVALUATION ||--o{ EVIDENCE_CITATION : "supported by"
    DOCUMENT ||--o{ EVIDENCE_CITATION : "cited in"
    CONTROL_EVALUATION ||--o{ RESIDUAL_QUESTION : "generates (active only)"
    CONTROL_EVALUATION ||--o{ ISSUE : "raises (active only)"
    ISSUE ||--o{ ISSUE_ENGAGEMENT_ACCEPTANCE : "accepted per engagement"
    ENGAGEMENT ||--o{ ISSUE_ENGAGEMENT_ACCEPTANCE : "accepts via"
    REASSESSMENT_TRIGGER_EVENT |o--o{ DUE_DILIGENCE_ASSESSMENT : "may initiate"

    THIRD_PARTY {
        string id PK
        string legal_name
        string aggregate_ir_tier "derived: worst engagement"
        string aggregate_qrm_rating "derived: worst engagement"
        string aggregate_rr_tier "derived: worst engagement"
        number aggregate_ure_score "derived: sum of engagements"
        string reassessment_cycle "from aggregate IR tier"
        date next_reassessment_due
    }
    ENGAGEMENT {
        string id PK
        string third_party_id FK
        string product_service_description
        string business_owner
        string criticality_flag
        string ir_tier "from current IRA"
        string qrm_rating "derived from domains"
        number ure_score "sum of domain URE"
        string rr_tier "derived"
    }
    INHERENT_RISK_ASSESSMENT {
        string engagement_id FK
        int version
        string status "draft|current|superseded"
        number ir_score
        string ir_tier
    }
    CONTROL {
        string id PK
        string name
        number importance_weight "mitigation significance"
        boolean severe_failure_eligible
    }
    CONTRACT {
        string id PK
        string third_party_id FK
        date effective_date
        date expiry_renewal_date
        string status
    }
    RISK_DOMAIN {
        string id PK
        string name
        string domain_category "grouping for reporting"
        string importance_tier "High|Medium|Low; engagement QRM input"
    }
    RISK_CHARACTERISTIC_RULE {
        string id PK
        string rule_type "control_applicability|domain_ir"
        string predicate "over risk characteristic values"
        string target_id "control or risk domain per rule_type"
    }
    CONTROL_DOMAIN_MAPPING {
        string control_id FK
        string risk_domain_id FK
        number importance_weight_override "variant only"
    }
    DUE_DILIGENCE_ASSESSMENT {
        string third_party_id FK
        int version
        string assessment_type "initial|periodic|triggered|incremental|scope_change"
        string status
        date completed_date "full assessments anchor freshness"
    }
    CONTROL_EVALUATION {
        string dd_assessment_id FK
        string control_id FK
        string applicability_status "active|latent"
        number ai_confidence
        number deficiency_score "from open issue severity; uncapped for severe"
        number steward_override_score "with rationale"
        string effectiveness_rating
        string review_status "ai_drafted|steward_reviewed|final"
    }
    ISSUE {
        string control_evaluation_id FK
        int severity "4-point"
        string status
    }
    ISSUE_ENGAGEMENT_ACCEPTANCE {
        string issue_id FK
        string engagement_id FK
        string acceptance_status
        string accepting_authority "severity-by-criticality matrix"
    }
    ENGAGEMENT_DOMAIN_RESULT {
        string engagement_id FK
        string risk_domain_id FK
        boolean applicable
        string domain_ir_tier
        string domain_qrm_rating
        number domain_ure_score
        string domain_rr_tier
        string computed_from "IRA ver + DDA ver"
        date effective_from
        date effective_to
        boolean is_current
    }
    ENGAGEMENT_RATING_RESULT {
        string engagement_id FK
        string ir_tier
        string qrm_rating
        number ure_score
        string rr_tier
        string computed_from "IRA ver + DDA ver"
        date effective_from
        date effective_to
        boolean is_current
    }