Compliance Risk Priority Weighting Prompt

This prompt is engineered for a single, high-stakes job: re-prioritizing an incoming request, incident, or ticket when regulatory exposure demands it. In a standard triage system, a forgotten password and a potential GDPR-violating data leak might both land as 'medium severity' based on operational impact alone. This prompt breaks that false equivalence. It ingests an unstructured input and produces a compliance-weighted priority score that can override operational severity, ensuring that items with mandatory breach notification timelines, data subject rights deadlines, or SOX control implications surface to the top of the queue. The ideal user is a compliance architect, risk officer, or platform engineer embedding regulatory awareness directly into automated triage middleware—not a support agent manually deciding what feels urgent.

Use this prompt only when a specific regulatory framework (GDPR, HIPAA, PCI-DSS, SOX, GLBA, or similar) plausibly applies to the input being scored. The prompt requires a [REGULATORY_FRAMEWORK] parameter to scope its analysis; without it, the model may hallucinate obligations or flag non-issues. It is not a general-purpose priority scorer, a sentiment analyzer, or a replacement for operational severity classification. It is a compliance overlay that shifts priority independently. Do not use it for internal IT tickets with no regulatory surface area, feature requests, or general customer complaints. The prompt is designed to be wired as a post-classification step: first, classify the input's operational severity and topic; then, if the topic touches a regulated domain, invoke this prompt to compute a compliance-weighted adjustment. This separation prevents compliance logic from polluting your base priority model and keeps audit trails clean.

Before deploying, you must calibrate the [COMPLIANCE_WEIGHT] parameter—the multiplier that determines how much regulatory exposure shifts priority relative to operational factors. Start with a weight of 2.0 and adjust based on your organization's risk appetite and historical breach impact data. The prompt also requires a [REGULATORY_REFERENCE_LIBRARY] mapping regulation names to their key obligations, timelines, and reporting triggers. Without this grounding, the model will rely on its training data, which may be outdated or jurisdictionally incorrect. Always pair this prompt with a human-review step for any output that changes a priority level by more than one tier or flags a mandatory reporting obligation. The cost of a false negative here is regulatory penalty; the cost of a false positive is operational noise and alert fatigue. Test both failure modes explicitly in your eval harness before production use.

The prompt below is designed to be pasted into your system instructions or sent as a user message. It forces the model to separate operational severity from compliance exposure, producing a priority score that reflects regulatory risk independently of standard incident severity. Replace every square-bracket placeholder with your actual data before sending. The prompt includes explicit instructions for citing the specific regulation, estimating the exposure timeline, and flagging mandatory reporting obligations—three dimensions that standard priority scoring prompts typically ignore.

textCopy
You are a compliance risk analyst. Your task is to assign a compliance-weighted priority score to the following issue. The score must reflect regulatory exposure independently of operational severity.

INPUT:
[ISSUE_DESCRIPTION]

REGULATORY CONTEXT:
[JURISDICTION]
[APPLICABLE_REGULATIONS]
[REGULATORY_BODY]

ORGANIZATIONAL CONTEXT:
[INDUSTRY]
[DATA_CLASSIFICATION]
[CONTRACTUAL_OBLIGATIONS]

CONSTRAINTS:
- Do not conflate operational severity with compliance risk.
- If no regulation applies, set compliance_weight to 0 and explain why.
- If the input is ambiguous, request clarification rather than assuming.
- Cite the specific regulation, clause, or standard that drives the score.
- Flag any mandatory reporting obligation with a deadline.

OUTPUT_SCHEMA:
{
  "compliance_weighted_priority": {
    "score": "number (1-100, where 100 is maximum compliance risk)",
    "confidence": "number (0-1)",
    "regulatory_basis": [
      {
        "regulation": "string",
        "clause": "string or null",
        "relevance": "string (explanation of why this regulation applies)"
      }
    ],
    "exposure_timeline": {
      "detection_date": "string (ISO date or 'unknown')",
      "reporting_deadline": "string (ISO date or 'none')",
      "remediation_deadline": "string (ISO date or 'none')",
      "urgency_rationale": "string"
    },
    "mandatory_reporting": {
      "required": "boolean",
      "reporting_body": "string or null",
      "reporting_deadline": "string (ISO date or 'none')",
      "consequence_of_non_reporting": "string or null"
    },
    "operational_severity_separate": {
      "score": "number (1-100)",
      "rationale": "string (explain operational impact without compliance weighting)"
    },
    "evidence_excerpts": ["string (quoted from input)"],
    "missing_information": ["string (what you need but don't have)"],
    "recommended_action": "string (next step for the compliance or legal team)"
  }
}

If the input does not contain enough information to produce a reliable score, set confidence below 0.5 and populate missing_information with specific questions.

To adapt this prompt, start by replacing [JURISDICTION] and [APPLICABLE_REGULATIONS] with the specific regulatory environment your organization operates in—GDPR, HIPAA, SOX, PCI DSS, or industry-specific frameworks. The [DATA_CLASSIFICATION] field should reflect your internal data handling tiers. If you are wiring this into a production system, consider injecting the regulatory context from a configuration store rather than hardcoding it, so the same prompt works across multiple jurisdictions. The output schema is deliberately verbose: it forces the model to separate operational severity from compliance risk and to cite evidence. If your downstream system only needs the composite score, you can strip the schema down, but keep regulatory_basis and mandatory_reporting—those are the fields that auditors will ask for.

Before deploying, test this prompt against three categories of inputs: (1) a clear compliance violation with a known regulation, (2) an operational incident with no regulatory dimension, and (3) an ambiguous case where the input lacks enough detail. The second category is the most common failure mode—models tend to hallucinate regulatory obligations when none exist. If your eval shows false compliance flagging above 5%, add a stronger instruction in the constraints block or include a few-shot example of a non-compliance case. For high-stakes environments, route outputs with mandatory_reporting.required == true to a human review queue before any automated action is taken.

The Compliance Risk Priority Weighting Prompt is designed to sit after initial severity classification and before queue dispatch in a regulated triage pipeline. It takes a pre-classified incident or request, enriches it with compliance context, and produces a weighted priority score that can override or adjust the operational severity. The prompt expects a structured input containing the original severity, a description of the issue, the affected data types or systems, and the applicable regulatory frameworks. The output is a JSON object with a compliance-weighted score, the specific regulation cited, an exposure timeline, and mandatory reporting flags. This output should be treated as a decision-support artifact, not an autonomous decision, and must be logged immutably for audit purposes.

Integration pattern: In a typical implementation, a service mesh or workflow engine (e.g., Temporal, AWS Step Functions, a custom Python orchestrator) calls the LLM with this prompt after the initial triage step. The harness must validate the output against a strict JSON schema before allowing the score to influence queue priority. If validation fails, the harness should retry with a repair prompt that includes the schema and the malformed output. After a configurable number of retries (typically 2-3), the system must fall back to a human review queue and log the failure. The compliance-weighted score should be stored alongside the original severity, the raw LLM output, the prompt version, and the model identifier in an append-only audit table. For high-regulation environments (e.g., HIPAA, PCI, SOX), the harness should also capture a cryptographic hash of the input and output for tamper-evidence.

Model choice and latency: This prompt benefits from models with strong instruction-following and structured output capabilities, such as gpt-4o or claude-3.5-sonnet. Because compliance triage is often time-sensitive, the harness should enforce a strict latency budget (e.g., 5 seconds) and fall back to the operational severity score if the LLM call times out. Do not use a smaller, faster model that hallucinates regulations or misses mandatory reporting triggers—the cost of a false negative in compliance flagging is far higher than the latency cost of a capable model. For batch or async workflows, consider using a model with structured output mode (e.g., OpenAI's response_format with a JSON schema) to reduce post-generation validation failures.

What to avoid: Never allow the compliance-weighted score to be the sole determinant of queue position without a human-in-the-loop review for scores above a defined threshold (e.g., any score that triggers mandatory regulatory reporting). Do not log the full prompt input if it contains PII or PHI without redaction—the harness should apply a redaction step before audit logging. Finally, avoid wiring this prompt directly into customer-facing status pages; the compliance risk score is an internal routing signal, not a user-facing SLA metric. The next step after implementation is to build a regression test suite using the eval criteria described in the Testing and Evaluation section, with specific test cases for correct regulation identification and false compliance flagging.