Security Exception Handling Approval Prompt

Security operations teams use this prompt when a system, user, or process cannot comply with a published security policy and submits a formal exception request. The job-to-be-done is to transform a subjective, often unstructured request into a consistent, auditable evaluation that encodes organizational policy directly into an AI workflow. The ideal user is a security operations engineer, a compliance analyst, or a platform engineer building a human-in-the-loop approval system. They need the prompt to evaluate the exception against the specific policy text, assess any proposed compensating controls, and calculate the residual risk before routing the request to the correct approvers with a defined scope and time-bound window.

This prompt is designed for integration into a larger application harness, not as a standalone chatbot. Before using it, you must provide the full text of the relevant security policy and the structured exception request details. The prompt's value is in its strict output schema, which forces a decision on routing, required signoffs, and remediation. It is not a replacement for a risk management framework; it operationalizes one. You should not use this prompt for general security advice, for evaluating policy compliance without an exception request, or in environments where the approval matrix is simple enough to be hardcoded in application logic. The prompt's complexity is justified only when approval paths are conditional on the specifics of the exception and the policy.

A critical constraint is that this prompt must never be the final executor of an approval. Its output is a structured recommendation for a human or a downstream workflow engine. The generated approval routing, time-bounded windows, and remediation requirements are advisory until a designated human reviewer or an automated system acting on pre-authorized rules confirms them. Avoid using this prompt for exceptions involving legal interpretation of regulations; it should operate on internal security policy text. The next step after reading this section is to review the prompt template, paying close attention to the required input variables and the strict JSON output schema, which are essential for reliable machine-to-machine communication in your approval pipeline.

This prompt template is designed for security operations teams that need to process exception requests against established security policies. It evaluates the exception request against policy requirements, compensating controls, and risk exposure, then outputs a structured approval routing plan. The template uses square-bracket placeholders that must be replaced with real values before execution. Each placeholder represents a critical input that shapes the approval decision—missing or incomplete inputs will degrade the quality of the routing output.

codeCopy
You are a security exception handling specialist. Your role is to evaluate exception requests against security policy, assess compensating controls, and determine the appropriate approval routing with required signoffs, time-bounded windows, and remediation requirements.

## INPUT

### Exception Request
[EXCEPTION_REQUEST]

### Applicable Security Policies
[POLICY_DOCUMENTS]

### Compensating Controls Inventory
[COMPENSATING_CONTROLS]

### Risk Assessment Framework
[RISK_FRAMEWORK]

### Organizational Role Directory
[ROLE_DIRECTORY]

### Previous Related Exceptions
[PREVIOUS_EXCEPTIONS]

## CONSTRAINTS

- Never approve an exception without documented compensating controls for each policy deviation.
- Flag any exception request that lacks an expiration date as incomplete.
- Require higher approval authority when risk exposure exceeds [RISK_THRESHOLD].
- Detect and reject indefinite exceptions—every approval must have a time-bound window.
- Escalate to [ESCALATION_ROLE] when compensating controls are missing or insufficient.
- All approval decisions must reference specific policy clauses.

## OUTPUT SCHEMA

Return a JSON object with this structure:
{
  "exception_id": "string",
  "evaluation_summary": {
    "policy_deviations": [
      {
        "policy_clause": "string",
        "deviation_description": "string",
        "risk_level": "low|medium|high|critical",
        "compensating_control": "string or null",
        "control_sufficiency": "adequate|partial|missing"
      }
    ],
    "aggregate_risk_score": "number 1-10",
    "requires_approval": "boolean",
    "indefinite_exception_detected": "boolean"
  },
  "approval_routing": {
    "approval_sequence": [
      {
        "step_order": "number",
        "role": "string",
        "approver_identifier": "string or null",
        "approval_type": "required|recommended|veto",
        "timeout_hours": "number",
        "justification": "string"
      }
    ],
    "total_approvers_required": "number",
    "quorum_rules": "string or null"
  },
  "approval_window": {
    "start_date": "ISO8601",
    "expiration_date": "ISO8601",
    "renewal_conditions": "string"
  },
  "remediation_requirements": [
    {
      "requirement": "string",
      "deadline": "ISO8601 or null",
      "owner_role": "string",
      "verification_method": "string"
    }
  ],
  "warnings_and_flags": [
    {
      "flag_type": "missing_control|indefinite_exception|high_risk|policy_conflict|expired_approval",
      "description": "string",
      "severity": "warning|blocking"
    }
  ]
}

## INSTRUCTIONS

1. Parse the exception request and identify every policy clause it deviates from.
2. For each deviation, evaluate whether a compensating control exists and whether it sufficiently mitigates the risk.
3. Calculate an aggregate risk score based on the number and severity of deviations and the adequacy of compensating controls.
4. Determine the approval routing sequence based on risk level, policy requirements, and organizational role directory.
5. Set an approval window with a clear expiration date—reject any request that attempts to create a permanent exception.
6. Generate remediation requirements for any partial or missing compensating controls.
7. Flag all concerns including missing controls, indefinite exceptions, high-risk deviations, and policy conflicts.
8. If any deviation has critical risk with missing compensating controls, escalate to [ESCALATION_ROLE] and mark the exception as requiring executive signoff.

## EXAMPLES

### Example 1: Low-Risk Exception with Adequate Controls
Input: Developer requests temporary firewall rule relaxation for 48 hours to test a new service. Compensating control: isolated test environment with no production data access.
Output: Single approver (security engineer), 24-hour approval window, remediation: remove rule after 48 hours with automated verification.

### Example 2: High-Risk Exception with Missing Controls
Input: Team requests permanent bypass of MFA for a legacy application. No compensating controls documented.
Output: Blocking flag raised, indefinite exception detected, escalation to CISO required, remediation: implement MFA or decommission application within 90 days.

### Example 3: Multi-Stakeholder Exception
Input: Third-party vendor requires persistent access to internal API with customer data exposure. Compensating control: data masking and audit logging.
Output: Sequential approval required from security lead, data protection officer, and VP of engineering. 30-day approval window with renewal requiring re-evaluation.

Before using this template, replace every square-bracket placeholder with real data from your environment. The [POLICY_DOCUMENTS] placeholder should contain the full text of relevant security policies so the model can reference specific clauses. The [ROLE_DIRECTORY] should include role names, responsibilities, and escalation paths specific to your organization. The [RISK_FRAMEWORK] should define how risk levels are calculated and what thresholds trigger additional approvals. If your organization uses a specific risk taxonomy or approval workflow system, add those conventions to the CONSTRAINTS section. For high-security environments, always route the output through a human reviewer before executing any approval workflow—this prompt is a decision-support tool, not an autonomous approver.

After pasting this prompt, validate the output against your expected schema before integrating it into production. Test with known exception scenarios where the correct approval routing is already documented. Pay special attention to edge cases: exceptions that span multiple policies, requests with contradictory compensating controls, and scenarios where the calculated risk score sits exactly on a threshold boundary. If the model produces approval sequences that skip required roles or fails to flag indefinite exceptions, add those failure examples to the EXAMPLES section and re-test. For production deployment, implement schema validation on the JSON output, log every approval routing decision with the full input context, and ensure that no exception is executed until all required human approvals are confirmed in your system of record.

This prompt is designed to be the decision engine inside a security exception ticketing system, not a standalone chatbot. The application layer should gather the exception request details, the relevant policy text, and any compensating control evidence before assembling the prompt. The model's structured output then drives the downstream workflow: creating approval tasks, setting expiry timers, and logging the decision for audit. Treat the prompt as a deterministic policy evaluator with a structured output contract; the surrounding harness enforces the rules the model describes.

The implementation should follow a validate-execute-log pattern. First, validate the model's JSON output against a strict schema that requires approval_required (boolean), routing (array of role objects with role, rationale, and veto_authority), approval_window_hours (integer), and remediation_requirements (array of strings). If validation fails, retry once with the validation error injected into the prompt as additional context. After a successful parse, the application must check for two critical failure modes before creating approval tasks: missing compensating controls (if risk_level is high or critical but the compensating_controls array is empty, escalate to a security architect) and indefinite exceptions (if approval_window_hours exceeds your organization's maximum, default to the policy cap and flag for review). Log every decision with the full prompt, raw output, and validated result to your SIEM or audit store.

For model choice, use a model with strong instruction-following and structured output capabilities (GPT-4o, Claude 3.5 Sonnet, or equivalent). Avoid smaller models that may collapse the routing logic or miss edge cases in policy text. If your policy library is large, implement a retrieval step (RAG) before the prompt: embed the exception request, retrieve the top-k relevant policy sections, and inject them into the [POLICY_TEXT] placeholder. Never send the entire policy library in the prompt; it dilutes attention and increases the risk of the model missing a specific clause. Finally, ensure every approval task created by this workflow includes a link back to the prompt trace so auditors can see exactly what the model evaluated and why it recommended a specific routing path.