Secrets Rotation Policy Compliance Prompt Template

This prompt is designed for security operations teams who need to audit secrets management practices against a defined rotation policy. It takes a structured inventory of secrets from vault integrations (HashiCorp Vault, AWS Secrets Manager, GCP Secret Manager, Azure Key Vault), applies a configurable rotation policy, and produces a compliance report identifying stale secrets, missing rotation automation, and policy violations. Use this when you need an automated first-pass compliance assessment before a manual audit or as part of a continuous compliance pipeline. This is not a secret detection scanner; it assumes you already have a secrets inventory and need to evaluate it against lifecycle rules.

The ideal user is a security engineer or DevSecOps practitioner who maintains a secrets inventory and needs to prove rotation compliance to auditors or enforce policy programmatically. You must provide the prompt with a structured JSON inventory containing secret identifiers, creation dates, last rotation timestamps, rotation method (automatic, manual, none), and associated service or application context. The rotation policy itself is configurable: you define maximum age thresholds by secret type (database credentials, API keys, TLS certificates, encryption keys) and any exemption rules. The prompt does not connect to vault APIs directly; you must extract and format the inventory upstream before invoking this compliance check.

Do not use this prompt for real-time secret detection in code repositories, log files, or configuration files. It is not a scanner and will not find secrets you haven't already catalogued. Do not use it as a replacement for vault-native rotation automation or policy enforcement; it is an assessment and reporting tool, not an enforcement mechanism. For high-stakes audits where regulatory findings carry legal or financial consequences, always pair the prompt's output with human review and evidence collection from the source vault systems. The prompt's value is in accelerating the compliance review cycle, not in replacing auditor judgment.

This prompt template is designed for security operations teams who need to audit secrets management practices against defined rotation policies. It accepts vault configuration data, policy documents, and an inventory of active secrets to produce a structured compliance report. The report identifies stale secrets, missing rotation automation, policy violations, and lifecycle coverage gaps across vault integrations. Use this template as the core instruction set for an AI coding agent or security review assistant operating within a repository context.

textCopy
You are a secrets rotation policy compliance auditor. Your task is to analyze the provided secrets inventory, vault configuration, and rotation policy documents to produce a structured compliance report.

## INPUTS
- Secrets Inventory: [SECRETS_INVENTORY]
- Vault Configuration: [VAULT_CONFIGURATION]
- Rotation Policy Document: [ROTATION_POLICY]
- Rotation Automation Config: [AUTOMATION_CONFIG]
- Previous Audit Report (optional): [PREVIOUS_AUDIT]

## OUTPUT SCHEMA
Return a JSON object with the following structure:
{
  "report_metadata": {
    "audit_timestamp": "ISO 8601 timestamp",
    "policy_version": "string",
    "vault_integrations_audited": ["list of vault names or paths"],
    "total_secrets_audited": "integer"
  },
  "compliance_summary": {
    "compliant_count": "integer",
    "non_compliant_count": "integer",
    "exempt_count": "integer",
    "overall_compliance_percentage": "float",
    "critical_findings_count": "integer"
  },
  "findings": [
    {
      "finding_id": "string, unique identifier",
      "severity": "CRITICAL | HIGH | MEDIUM | LOW",
      "category": "STALE_SECRET | MISSING_AUTOMATION | POLICY_VIOLATION | LIFECYCLE_GAP | CONFIGURATION_DRIFT",
      "secret_identifier": "string, path or key name",
      "secret_type": "string, e.g., API_KEY, DATABASE_CREDENTIAL, TLS_CERT, SSH_KEY",
      "vault_location": "string, vault path or integration name",
      "current_rotation_status": {
        "last_rotated": "ISO 8601 timestamp or null",
        "rotation_interval_days": "integer or null",
        "expected_interval_days": "integer from policy",
        "days_since_rotation": "integer or null",
        "automation_enabled": "boolean"
      },
      "policy_reference": "string, specific policy clause or section",
      "finding_description": "string, clear explanation of the violation or gap",
      "risk_rationale": "string, why this finding matters in security terms",
      "remediation_guidance": "string, actionable steps to resolve",
      "evidence": {
        "source": "string, config file, audit log, or vault record",
        "evidence_snippet": "string, relevant excerpt or null if not available"
      }
    }
  ],
  "lifecycle_coverage": {
    "secrets_with_defined_lifecycle": "integer",
    "secrets_without_lifecycle": "integer",
    "orphaned_secrets": ["list of secret identifiers with no owner or rotation policy"],
    "coverage_percentage": "float"
  },
  "automation_gaps": {
    "secrets_requiring_manual_rotation": "integer",
    "automation_coverage_percentage": "float",
    "vaults_without_automation_support": ["list of vault names"]
  },
  "recommendations": [
    {
      "priority": "integer, 1 being highest",
      "category": "string, e.g., AUTOMATION, POLICY_UPDATE, ACCESS_REVIEW, SECRET_CLEANUP",
      "recommendation": "string, actionable recommendation",
      "affected_secrets_count": "integer",
      "effort_estimate": "LOW | MEDIUM | HIGH"
    }
  ]
}

## CONSTRAINTS
- Only report on secrets present in the provided inventory. Do not assume secrets exist.
- Classify severity based on: CRITICAL if the secret is stale beyond 2x the rotation interval or has no rotation defined for production credentials; HIGH if stale beyond 1.5x the interval; MEDIUM if approaching the rotation deadline; LOW if administrative or non-sensitive.
- If a secret has an approved exemption in the policy document, mark it as exempt and do not create a finding unless the exemption has expired.
- For each finding, cite the specific policy clause or configuration evidence. If evidence is unavailable, note it explicitly.
- Do not include actual secret values in any output. Use identifiers and paths only.
- If the previous audit report is provided, highlight regressions and newly resolved findings.

## EVALUATION CRITERIA
Before returning the output, verify:
1. Every non-compliant secret in the inventory has a corresponding finding.
2. Severity classifications align with the policy's defined intervals.
3. Lifecycle coverage calculation accounts for all secrets in the inventory.
4. Automation gaps are correctly identified where rotation automation config is missing or disabled.
5. No finding lacks a policy reference or explicit note that no policy clause applies.

## RISK LEVEL
[HIGH] This prompt deals with security-sensitive audit data. Outputs must be reviewed by a human security engineer before being used for compliance reporting or remediation actions. Findings may trigger automated rotation workflows; validate all secret identifiers and paths before executing any rotation.

To adapt this template for your environment, replace the square-bracket placeholders with real data before execution. The [SECRETS_INVENTORY] should contain a structured list of secrets from your vault or secrets manager, including identifiers, types, last rotation timestamps, and automation status. The [VAULT_CONFIGURATION] should include vault integration details, access policies, and rotation capabilities. The [ROTATION_POLICY] is your organization's documented rotation requirements, including interval definitions per secret type and exemption criteria. The [AUTOMATION_CONFIG] should describe which vaults have automated rotation enabled and their configuration state. If you have a previous audit report, include it in [PREVIOUS_AUDIT] to enable regression detection.

Before deploying this prompt into a production workflow, wire it into an application harness that validates the output JSON against the defined schema. Implement retry logic with schema validation feedback if the model produces malformed JSON. Log every audit run with the input inventory hash and output report for traceability. For high-risk environments, route CRITICAL and HIGH severity findings to a human review queue before any automated remediation is triggered. Test the prompt against a golden dataset of known compliant and non-compliant secrets to calibrate severity classification accuracy before relying on it for compliance reporting.

The Secrets Rotation Policy Compliance Prompt is designed to operate as a critical step within a broader security audit pipeline, not as a standalone chat interaction. Its primary function is to consume structured vault metadata and policy definitions, then produce a machine-readable compliance report. To integrate this effectively, you must treat the prompt as a deterministic function call: define a strict input schema (vault inventory, rotation policy rules, last-rotation timestamps), invoke the model, and validate the output against a known JSON schema before the results enter any compliance dashboard or ticketing system. Because the output directly informs security posture decisions, the harness must enforce evidence grounding—every finding of a stale secret must cite the specific policy clause and the vault record that triggered the violation.

The implementation should follow a validate → retry → escalate pattern. First, parse the model's JSON output and validate it against a schema that requires fields like finding_id, secret_identifier, policy_clause_reference, days_since_rotation, and remediation_priority. If validation fails or the model returns a malformed structure, initiate a single retry with a repair prompt that includes the validation error message and the original input context. If the retry also fails, log the full input/output pair and escalate to a human auditor queue rather than silently dropping the finding. For model choice, prefer a model with strong JSON mode and long-context handling (such as gpt-4o or claude-3-opus) because vault inventories can be large. Set temperature=0 to maximize deterministic reporting. If your vault metadata exceeds the context window, pre-process the input by filtering to only secrets approaching or past their rotation window, or use a RAG pattern to retrieve relevant policy sections for each secret class.

Logging and auditability are non-negotiable. Every invocation must record the prompt version, model identifier, input inventory hash, raw output, validation status, and final report payload. This trace ensures that a compliance officer can later reconstruct why a specific secret was flagged as non-compliant. Do not use the prompt to automatically trigger rotation—this is a detection and reporting tool. The output should feed into a human review queue where an operator confirms or dismisses each finding before any rotation job is initiated. Finally, build an eval harness that tests the prompt against a golden dataset of known stale and compliant secrets, measuring both rotation gap detection recall (did it catch all expired secrets?) and false positive precision (did it incorrectly flag secrets that are within policy?). Run this eval on every prompt update and whenever the underlying vault schema changes.