Risk Tier Assignment Prompt for Compliance Reviews

This prompt is designed for compliance analysts, risk officers, and audit engineers who need to map unstructured review findings—such as audit notes, control test results, or incident reports—into a predefined, machine-readable risk tier. The core job is classification with mandatory evidence grounding: the model must select a tier from a controlled vocabulary (e.g., Low, Medium, High, Critical) and produce a structured justification that cites specific observations from the input. This is not a general summarization task; it is a structured data extraction and normalization task where the output feeds directly into governance, risk, and compliance (GRC) systems, dashboards, or regulatory filings.

Use this prompt when you have a stable, well-documented risk tier taxonomy that is owned by your compliance or risk management function. The input must contain sufficient factual observations to support a tier assignment—vague or purely speculative input will produce unreliable results. The prompt expects a [CONTEXT] block containing the review findings and a [TIER_DEFINITIONS] block that maps each tier to its criteria, impact thresholds, and required evidence types. You should not use this prompt for real-time operational alerting where latency is critical, nor for legal advice or final regulatory determinations without human review. It is also unsuitable for domains where the risk taxonomy changes frequently or is highly subjective without clear written criteria.

Before deploying, you must validate the output against your tier schema and test boundary cases where findings could reasonably map to two adjacent tiers. The prompt includes an [OUTPUT_SCHEMA] with a justification field that forces the model to ground its decision in the provided evidence. In production, always route outputs through a validation layer that checks for out-of-vocabulary tier labels and missing justification fields. For high-risk compliance workflows, implement a human-in-the-loop review step for any assignment at the High or Critical tier, and log every assignment with the model version, input hash, and reviewer identity for audit trail purposes. If your review findings are multi-page documents, consider pre-processing them into a structured summary before passing them to this prompt to improve tier boundary precision.

The following prompt template is designed to be copied directly into your AI harness, test suite, or orchestration layer. It uses square-bracket placeholders that your application must resolve before sending the request to the model. Each placeholder represents a variable input, a schema constraint, or a behavioral rule that you control at runtime. Do not ship this template with unresolved placeholders in production—your prompt assembly logic should validate that every required field is populated before the model call is made.

textCopy
You are a compliance risk tier assignment system. Your job is to review the provided compliance finding and assign exactly one risk tier from the controlled vocabulary below. You must provide a structured justification that references specific evidence from the finding. Do not invent risks, assume severity, or assign tiers outside the predefined list.

## RISK TIER VOCABULARY
You may only assign one of the following tiers:
- CRITICAL: Immediate regulatory or legal exposure requiring escalation within 24 hours. Evidence of active violation, imminent harm, or mandatory reporting trigger.
- HIGH: Significant compliance gap with potential regulatory consequences if unaddressed. Evidence of policy violation, control failure, or repeat finding.
- MEDIUM: Notable deviation from expected controls or procedures. Evidence of inconsistent practice, documentation gap, or single-instance lapse without systemic indicators.
- LOW: Minor procedural deviation or documentation improvement opportunity. Evidence of isolated issue with no immediate compliance impact.
- INFORMATIONAL: Observation, recommendation, or best-practice suggestion with no compliance obligation. No evidence of control weakness or policy violation.

## INPUT
[FINDING_TEXT]

## CONTEXT
Review Date: [REVIEW_DATE]
Applicable Framework(s): [FRAMEWORKS]
Business Unit: [BUSINESS_UNIT]
Reviewer Notes: [REVIEWER_NOTES]

## CONSTRAINTS
[CONSTRAINTS]

## OUTPUT SCHEMA
Return a single JSON object with the following structure:
{
  "risk_tier": "<one of: CRITICAL | HIGH | MEDIUM | LOW | INFORMATIONAL>",
  "confidence": "<HIGH | MEDIUM | LOW>",
  "justification": {
    "summary": "<one-sentence summary of the finding>",
    "tier_rationale": "<specific reason this tier was selected over adjacent tiers>",
    "evidence_cited": ["<direct quote or paraphrase from the finding text>"],
    "framework_reference": ["<applicable framework clause or control ID, or null if none>"],
    "escalation_recommended": <true | false>,
    "escalation_reason": "<reason for escalation recommendation, or null if false>"
  },
  "uncertainty_notes": "<any ambiguity, missing information, or boundary concerns, or null if none>"
}

## EXAMPLES
[EXAMPLES]

## INSTRUCTIONS
1. Read the finding text carefully. Identify the core compliance issue, if any.
2. Compare the finding against the risk tier definitions. If the finding straddles two tiers, select the higher tier and explain the boundary decision in tier_rationale.
3. Cite specific evidence from the finding text. Do not paraphrase without quoting or closely referencing the source language.
4. If the finding text is insufficient to determine a tier confidently, set confidence to LOW and explain what information is missing in uncertainty_notes.
5. If no compliance issue is present, assign INFORMATIONAL and explain why no higher tier applies.
6. Recommend escalation only when the assigned tier is CRITICAL or HIGH, or when the finding suggests a pattern that could become CRITICAL or HIGH if unaddressed.
7. Return only the JSON object. No markdown, no commentary, no additional text.

To adapt this template for your environment, replace each placeholder with concrete values or application logic. [FINDING_TEXT] should receive the raw text of the compliance finding. [FRAMEWORKS] should list the specific regulatory or internal frameworks in scope, such as SOC 2, HIPAA, or PCI DSS. [CONSTRAINTS] is your injection point for additional business rules—for example, 'Auto-escalate any finding related to customer data exposure' or 'Downgrade first-time procedural findings to LOW unless systemic.' [EXAMPLES] should contain few-shot demonstrations covering boundary cases, such as a finding that appears HIGH but resolves to MEDIUM due to mitigating controls. If your compliance team maintains a tier decision log, sample from it to keep examples grounded in real organizational patterns. Before deploying, validate that your prompt assembly pipeline rejects requests with missing [FINDING_TEXT] or [FRAMEWORKS] fields, and log every assignment with the full prompt context for auditability.

The risk tier assignment prompt is not a standalone document—it is a classification step inside a larger compliance review workflow. In production, this prompt typically sits behind an API endpoint that receives a structured review finding (evidence summary, control references, reviewer notes) and returns a tier label with justification. The application layer is responsible for enforcing the output contract: the model must return exactly one tier from the predefined set, a non-empty justification grounded in the provided evidence, and a confidence indicator. Before the response reaches any downstream system (case management, regulatory filing, audit log), it must pass automated validation against the tier schema and evidence-grounding rules.

Wire the prompt into your application with a validate-then-escalate pattern. After the model returns a JSON response, run a validator that checks: (1) the risk_tier field matches one of the allowed enum values, (2) the justification field is non-empty and references at least one specific fact from the input evidence, (3) the confidence field is within the expected range, and (4) no extra or missing required fields exist. If validation fails, retry once with the validation error message appended to the prompt context. If the retry also fails, route the review to a human compliance analyst with the original inputs, the failed model outputs, and the validation errors clearly flagged. For high-severity tiers (e.g., CRITICAL or HIGH), consider requiring human approval even when validation passes—add a review queue step before the tier assignment is committed to the system of record.

Model choice matters here. Use a model with strong instruction-following and low refusal rates on compliance content. Temperature should be set low (0.0–0.2) to minimize tier boundary drift. If your compliance framework changes—new tiers, renamed categories, updated evidence requirements—update the [TIER_DEFINITIONS] and [EVIDENCE_RULES] placeholders in the prompt template and run your regression test suite before deploying. Log every assignment with the full prompt, model response, validation result, and human review outcome. These logs become audit evidence for demonstrating consistent, defensible tier assignment decisions over time. Avoid using this prompt for real-time blocking decisions (e.g., transaction holds) without human-in-the-loop confirmation; the cost of a misclassified tier is too high to automate fully without review gates.