Compliance Document Evidence Ranking Prompt Template

This prompt is designed for GRC platform builders and internal audit engineering teams who need to rank control evidence programmatically before generating a compliance posture summary. Use it when you have retrieved a set of control test results, exception records, and remediation tickets and need to order them by audit significance. The prompt forces the model to weigh testing frequency, exception severity, remediation status, and compensating controls explicitly rather than defaulting to chronological or alphabetical ordering.

The ideal user is an engineering lead or product manager building an audit automation or continuous controls monitoring product. Required context includes a structured list of control evidence records, each with fields for control objective, test result, exception severity, remediation status, and compensating controls. The prompt expects this context to be pre-retrieved and formatted before invocation. It is not a retrieval prompt itself—it assumes evidence has already been fetched from a controls repository, GRC database, or audit management system.

Do not use this prompt for real-time transaction monitoring, regulatory filing extraction, or legal contract review. Those workflows require different evidence models and authority hierarchies covered in sibling playbooks. This prompt also should not be used when evidence records lack structured metadata for testing frequency or exception severity, as the ranking logic depends on those fields. For unstructured document review, use the Regulatory Filing Evidence Extraction prompt instead.

Before deploying, validate that your evidence retrieval pipeline consistently populates the required fields. Missing or null values in exception severity or remediation status will degrade ranking quality. Implement a pre-processing step that rejects evidence records with incomplete metadata and routes them for human triage. This prompt is a ranking and summarization step in a larger audit evidence pipeline—it does not replace evidence collection, validation, or human judgment for high-severity findings.

This template is designed to be pasted directly into your system message or a user turn. It instructs the model to act as a compliance evidence analyst, ranking control test results, exception reports, and remediation records against a specific control objective. The prompt uses square-bracket placeholders for all dynamic inputs—replace these with your retrieved evidence and control metadata before sending. The output is a structured JSON summary that can be parsed by downstream compliance dashboards or audit workflows.

textCopy
You are a compliance evidence analyst. Your task is to rank control evidence by its impact on the control objective, considering testing frequency, exception severity, and remediation status.

## INPUT
[EVIDENCE_LIST]

## CONTROL OBJECTIVE
[CONTROL_OBJECTIVE]

## RANKING CRITERIA
1. Exception Severity: Critical exceptions (control failure) rank highest. Minor deviations rank lower.
2. Testing Frequency: Evidence from continuous or high-frequency tests carries more weight than annual point-in-time tests.
3. Remediation Status: Open, overdue remediation items increase risk ranking. Closed and verified items reduce it.
4. Recency: Evidence older than [STALE_THRESHOLD_DAYS] days must be flagged as potentially stale.
5. Compensating Controls: If a control failure has a documented compensating control, note it and reduce the severity ranking by one level.

## OUTPUT FORMAT
Return a single JSON object with the following structure:
{
  "control_objective": "string",
  "overall_risk_assessment": "LOW" | "MODERATE" | "HIGH" | "CRITICAL",
  "ranked_evidence": [
    {
      "evidence_id": "string",
      "description": "string",
      "exception_severity": "NONE" | "MINOR" | "MAJOR" | "CRITICAL",
      "test_frequency": "string",
      "remediation_status": "OPEN" | "IN_PROGRESS" | "CLOSED" | "OVERDUE",
      "is_stale": true | false,
      "compensating_control_present": true | false,
      "rank": 1,
      "rationale": "string"
    }
  ],
  "summary": "A concise, factual summary of the control posture based on the ranked evidence."
}

## CONSTRAINTS
- Do not invent evidence. Only rank the provided [EVIDENCE_LIST].
- If no evidence is provided, return an empty ranked_evidence array and set overall_risk_assessment to "UNKNOWN".
- If compensating controls are mentioned but not detailed, flag them as present but do not assume their effectiveness.
- Flag any evidence item older than [STALE_THRESHOLD_DAYS] days with is_stale: true.

To adapt this template, replace [EVIDENCE_LIST] with your retrieved control test results, exception logs, and remediation records. Set [CONTROL_OBJECTIVE] to the specific objective being assessed, such as 'Ensure logical access is reviewed quarterly.' Adjust [STALE_THRESHOLD_DAYS] to match your organization's evidence freshness policy—90 days is common for SOX controls, but operational controls may require shorter windows. The output JSON is designed to be ingested by a GRC dashboard or audit evidence repository. Before deploying, run this prompt against a golden dataset of known control failures and compensating controls to verify the model correctly reduces severity when compensating controls are documented. Human review is required before any output is used in a formal audit submission.

The Compliance Document Evidence Ranking prompt is designed to operate as a structured scoring step inside a larger GRC or internal audit pipeline, not as a standalone chatbot. The prompt expects a batch of control evidence records—each already mapped to a control objective—and returns a ranked, scored summary. The application layer is responsible for assembling the evidence batch, enforcing the output schema, validating scores, and deciding when to escalate to a human reviewer. Do not send raw document text directly to this prompt; pre-extract and normalize evidence fields (control ID, test result, exception severity, remediation status, test date) before calling the model.

Wiring pattern: The recommended architecture is a validate → rank → verify → escalate loop. First, validate that each evidence record contains the required fields (control_objective, test_result, exception_severity, remediation_status, test_date). Reject or repair incomplete records before ranking. Second, call the model with the batch and the prompt template, requesting the compliance_posture_summary output schema. Third, run post-generation verification: check that every control objective in the input appears in the output, that severity scores are within the defined range, and that compensating controls are explicitly flagged when exceptions exist but remediation is in progress. Fourth, if the verification step detects missing controls, score anomalies, or unrecognized compensating control patterns, escalate to a human reviewer with the raw evidence and the model's output side by side.

Model choice and retries: Use a model with strong structured output support (GPT-4o, Claude 3.5 Sonnet, or equivalent) and enable strict JSON mode or function-calling output constraints. Set temperature=0 to maximize score consistency across runs. Implement a single retry on schema validation failure with the validation error message injected into the retry prompt. If the retry also fails, log the failure, attach the raw model output, and route to a human review queue. Do not retry more than once for compliance workflows—silent output corruption is worse than a logged failure.

Logging and audit trail: Log every ranking call with: input evidence batch hash, model version, prompt template version, raw model output, post-validation result, and escalation decision. Store these logs immutably for audit review. The output compliance_posture_summary should be stored alongside the evidence batch so that downstream audit reports can trace each severity score back to its source evidence record. For regulated environments, ensure that human reviewers can override model-assigned scores and that overrides are logged with reviewer identity, timestamp, and rationale.

What to avoid: Do not use this prompt for real-time control monitoring or continuous compliance dashboards without a human-in-the-loop gate. The model can rank evidence but cannot verify the accuracy of the underlying test results. Stale test dates are a known failure mode—the prompt includes test_date as a ranking factor, but the application must enforce a maximum test age threshold (e.g., flag any test older than 90 days for review) before evidence enters the ranking step. Finally, do not treat the model's severity scores as definitive audit conclusions; they are evidence prioritization signals that require human judgment for final disposition.