Configuration Drift Risk Scoring Prompt

This prompt is designed for platform engineering and security teams who need to assign consistent, defensible risk scores to configuration drift findings before they enter a compliance report or remediation queue. It takes a structured drift finding as input and produces a risk-scored output with likelihood, impact, and composite risk ratings aligned to an organizational risk taxonomy. Use this prompt when you have already detected drift through IaC reconciliation, runtime snapshot comparison, or audit tooling, and you need to transform raw findings into a prioritized, auditor-ready inventory. The core job-to-be-done is risk normalization: converting heterogeneous drift signals from multiple detection sources into a single, scored format that remediation teams and compliance reviewers can trust.

This prompt does not detect drift itself. It scores findings that have already been identified and structured. It assumes each input finding includes the resource identifier, the property that drifted, the expected value, the actual value, and the environment where drift was detected. Before invoking this prompt, you must have completed drift detection and structured your findings into a consistent JSON schema. If your input is raw terraform plan output, live API responses, or unstructured log lines, use a detection or extraction prompt first. Do not use this prompt for real-time alert triage where latency is critical; it is designed for batch or sequential scoring of findings that have already been collected. For high-security environments, always route the scored output through a human review step before it reaches an auditor or triggers automated remediation.

The ideal user is a platform engineer, SRE, or security analyst who owns configuration compliance and needs to produce risk-scored reports for stakeholders. The prompt requires that your organization has defined a risk taxonomy—or is willing to adopt the one embedded in the prompt—so that likelihood and impact ratings are consistent across teams. If your organization lacks a defined risk taxonomy, invest time in customizing the [RISK_LEVEL] and [CONSTRAINTS] placeholders before running this prompt at scale. Next, proceed to the prompt template section to copy the ready-to-use template, or jump to the implementation harness to learn how to wire this prompt into a production scoring pipeline with validation, retries, and logging.

This prompt template assigns a structured risk score to each drift finding in your inventory. It is designed to be wired into a drift detection pipeline where raw findings—such as an IAM policy change, a missing environment variable, or a Terraform state deviation—have already been identified. The prompt takes those findings plus your organization's risk taxonomy and produces a scored inventory with likelihood, impact, composite risk ratings, and a brief justification per finding. Use this when you need consistent, auditable risk scores for compliance reporting, remediation prioritization, or operational review queues.

textCopy
You are a configuration drift risk scorer for a platform engineering team. Your task is to assign a risk score to each drift finding using the organization's risk taxonomy.

## INPUT
- Drift Findings: [DRIFT_FINDINGS]
- Risk Taxonomy: [RISK_TAXONOMY]
- Environment Context: [ENVIRONMENT_CONTEXT]

## DRIFT FINDINGS SCHEMA
Each finding in [DRIFT_FINDINGS] is a JSON object with:
- finding_id: string
- resource_type: string (e.g., IAM_POLICY, ENV_VAR, K8S_DEPLOYMENT, TERRAFORM_RESOURCE)
- resource_id: string
- drift_description: string (what changed, what was expected, what was observed)
- detection_timestamp: ISO 8601 string
- affected_environments: array of strings (e.g., ["production", "staging"])
- blast_radius: string (description of affected services, users, or data)
- is_security_related: boolean
- is_compliance_related: boolean
- manual_change_evidence: string or null (evidence of intentional manual intervention)

## RISK TAXONOMY
[RISK_TAXONOMY] defines the scoring dimensions and levels. It includes:
- Likelihood levels with definitions (e.g., RARE, UNLIKELY, POSSIBLE, LIKELY, ALMOST_CERTAIN)
- Impact levels with definitions (e.g., NEGLIGIBLE, MINOR, MODERATE, MAJOR, CATASTROPHIC)
- Composite risk matrix mapping likelihood + impact to a risk rating (e.g., LOW, MEDIUM, HIGH, CRITICAL)
- Any domain-specific overrides for security, compliance, or production environments

## ENVIRONMENT CONTEXT
[ENVIRONMENT_CONTEXT] provides additional information about the environments:
- environment_tier: production, staging, development, or other
- deployment_freeze_active: boolean
- recent_incidents: array of related incident summaries
- change_window_status: open, closed, or emergency

## OUTPUT SCHEMA
Return a JSON object with a single key "scored_findings" containing an array of objects. Each object must have:
- finding_id: string (from input)
- likelihood: string (must match a level in the risk taxonomy)
- likelihood_rationale: string (1-2 sentences explaining why this likelihood was chosen)
- impact: string (must match a level in the risk taxonomy)
- impact_rationale: string (1-2 sentences explaining why this impact was chosen)
- composite_risk: string (must match a level in the risk taxonomy matrix)
- requires_immediate_action: boolean (true if composite_risk is HIGH or CRITICAL, or if security-related with MEDIUM or above)
- remediation_priority: integer (1 = highest priority, based on composite_risk, security flags, and environment tier)
- justification_summary: string (2-3 sentences summarizing the risk assessment for audit trail)

## CONSTRAINTS
- Use ONLY the levels defined in [RISK_TAXONOMY]. Do not invent new levels.
- If a finding is security_related AND affects production, impact must be at least MAJOR unless strong evidence justifies otherwise.
- If manual_change_evidence is present and credible, likelihood should be adjusted downward but impact remains unchanged.
- If environment_tier is production and deployment_freeze_active is true, flag any HIGH or CRITICAL finding with requires_immediate_action = true.
- Do not hallucinate additional findings. Score only the findings provided in [DRIFT_FINDINGS].
- If insufficient information exists to score a dimension, use the most conservative level (highest likelihood, highest impact) and note the uncertainty in the rationale.

## EXAMPLES
Example input finding:
{
  "finding_id": "drift-001",
  "resource_type": "IAM_POLICY",
  "resource_id": "arn:aws:iam::123456789:policy/ReadOnlyAccess-Prod",
  "drift_description": "Policy gained s3:PutObject permission not present in Terraform definition. Expected: read-only. Observed: read-write.",
  "detection_timestamp": "2025-01-15T08:30:00Z",
  "affected_environments": ["production"],
  "blast_radius": "All production S3 buckets in account 123456789",
  "is_security_related": true,
  "is_compliance_related": true,
  "manual_change_evidence": null
}

Example output scoring:
{
  "finding_id": "drift-001",
  "likelihood": "ALMOST_CERTAIN",
  "likelihood_rationale": "The drift is confirmed and currently active in production. No evidence of planned change.",
  "impact": "MAJOR",
  "impact_rationale": "Unauthorized write access to all production S3 buckets violates least-privilege and could lead to data tampering or exfiltration.",
  "composite_risk": "CRITICAL",
  "requires_immediate_action": true,
  "remediation_priority": 1,
  "justification_summary": "Active IAM policy drift in production grants write access contrary to declared read-only intent. Security and compliance impact is immediate with broad blast radius. Requires urgent remediation and incident review."
}

## INSTRUCTIONS
1. Parse [DRIFT_FINDINGS] and validate each finding has all required fields.
2. For each finding, evaluate likelihood based on drift confirmation status, manual change evidence, and environment context.
3. Evaluate impact based on resource_type, blast_radius, security flags, compliance flags, and environment tier.
4. Map likelihood + impact to composite_risk using the matrix in [RISK_TAXONOMY].
5. Set requires_immediate_action and remediation_priority based on composite_risk, security flags, and environment context.
6. Write concise rationales and a justification summary suitable for audit review.
7. Return the complete scored_findings array as valid JSON.

Before wiring this prompt into production, replace [DRIFT_FINDINGS] with the actual JSON array of drift findings from your detection pipeline, [RISK_TAXONOMY] with your organization's documented risk levels and matrix, and [ENVIRONMENT_CONTEXT] with current environment state. Validate that the output JSON strictly conforms to the schema by running a structural validator after the model responds. For high-stakes compliance workflows, route CRITICAL findings to a human reviewer before the scored inventory is finalized. If the model returns a likelihood or impact level not present in your taxonomy, treat it as a validation failure and retry with an explicit reminder of the allowed levels in the retry prompt.

The Configuration Drift Risk Scoring Prompt is designed to be called as a scoring microservice within a larger drift management pipeline. The typical integration pattern is: a drift detection system (e.g., a Terraform plan diff, a Kubernetes reconciler, or an environment audit tool) produces a list of raw drift findings. Each finding is then sent to this prompt—either individually for low-volume, high-criticality workflows or in small batches of 5–10 findings for higher throughput—to assign a risk score. The prompt expects a structured [DRIFT_FINDING] object and an [ORGANIZATIONAL_RISK_TAXONOMY] definition that encodes your team's severity levels, impact categories, and likelihood criteria. The output is a JSON object containing likelihood_score, impact_score, composite_risk_score, and a risk_rationale string. This output should be stored alongside the raw finding in your drift inventory database for compliance reporting and prioritization.

To wire this into a production application, wrap the LLM call in a validation and retry layer. The output schema is strict: likelihood_score and impact_score must be integers within the ranges defined in your taxonomy, and composite_risk_score must equal the product or weighted sum (depending on your taxonomy) of the two. Implement a JSON schema validator that rejects malformed responses and triggers a single retry with the same input plus the validation error message appended as context. If the retry also fails, log the raw response and flag the finding for human review rather than silently accepting a bad score. For high-compliance environments, consider a second LLM call with a judge prompt that evaluates whether the risk_rationale is consistent with the assigned scores and the evidence in the finding; flag discrepancies for manual audit. Model choice matters: use a model with strong structured output capabilities (e.g., GPT-4o, Claude 3.5 Sonnet) and set temperature=0 to maximize scoring consistency across findings. Do not use this prompt with small or local models that struggle with multi-factor scoring rubrics unless you have calibrated their performance on your specific taxonomy.

The most common production failure mode is taxonomy drift: the [ORGANIZATIONAL_RISK_TAXONOMY] passed at runtime becomes stale relative to your team's actual risk policies. Mitigate this by storing the taxonomy as a versioned configuration artifact in your drift management system, not hardcoded in the prompt template. Log the taxonomy version alongside every scored finding so you can retroactively re-score findings if your risk framework changes. A second failure mode is context overload: drift findings often contain verbose resource configurations or long diff outputs. Truncate the [DRIFT_FINDING] input to the essential fields—resource type, property name, old value, new value, and a brief impact description—before passing it to the prompt. Avoid including full JSON blobs of cloud resource state unless the taxonomy explicitly requires that detail for impact assessment. Finally, never use this prompt to score drift findings that involve secrets or credentials; redact sensitive values upstream before they enter the prompt context, and flag any finding where redaction removes information needed for accurate scoring as requiring manual review.