Security Control Test Traceability Prompt

This prompt is designed for security testers, AppSec engineers, and compliance leads who need to map a defined set of security controls to an existing test suite. The primary job-to-be-done is producing a structured security coverage matrix that identifies which controls lack test coverage, highlights high-risk gaps, and provides a threat coverage score. Use it when you have a list of controls from a framework like OWASP ASVS, NIST SP 800-53, or an internal security standard, and a catalog of test cases. The prompt assumes your inputs are already defined and that the core task is mapping and gap analysis, not generating new test cases from scratch or assessing code-level vulnerabilities without a test catalog.

The ideal user brings two structured inputs: a control list with unique identifiers and descriptions, and a test catalog with test case IDs, steps, and expected results. The prompt works best when controls are granular enough to map to specific test cases—broad, high-level controls will produce vague coverage assessments. Before invoking the prompt, ensure your test catalog includes enough metadata (such as test type, risk level, or linked requirements) to support meaningful alignment decisions. If your test cases lack unique identifiers or traceability metadata, run a test catalog normalization step first.

Do not use this prompt to generate new test cases from scratch, to perform dynamic code analysis, or to assess vulnerabilities directly. It is not a replacement for a penetration test or a SAST/DAST tool. The prompt also should not be used when controls are defined only as vague policy statements without testable criteria—the mapping quality degrades sharply when neither side of the equation is concrete. For regulated environments, always pair the output with human review and evidence grounding before using it in an audit context. If you need to generate test cases from controls, use a test case generation prompt instead and then return to this prompt for traceability mapping.

This prompt template is the core of the Security Control Test Traceability playbook. It instructs the model to act as a security-focused QA architect, mapping a provided list of security controls (from frameworks like OWASP ASVS, NIST SP 800-53, or a custom control catalog) against an inventory of existing test cases. The output is a structured security coverage matrix that flags untested controls, weak coverage areas, and high-risk gaps. The prompt is designed to be copied directly, with square-bracket placeholders replaced by your specific data before sending it to the model.

textCopy
You are a security-focused QA architect. Your task is to produce a security control test traceability matrix.

## INPUTS
- Security Controls: [CONTROLS_LIST]
- Test Case Inventory: [TEST_CASES_LIST]
- Risk Classifications: [RISK_CLASSIFICATIONS]

## CONSTRAINTS
- Map each security control to zero or more existing test cases based on functional alignment.
- For controls with zero mapped test cases, flag them as a COVERAGE GAP.
- For controls with partial coverage, flag them as INSUFFICIENT COVERAGE and explain what is missing.
- Classify each gap by risk level: [CRITICAL, HIGH, MEDIUM, LOW].
- Do not invent test cases that do not exist in the provided inventory.
- If a control is not applicable to the system under test, mark it as NOT APPLICABLE with a brief justification.

## OUTPUT SCHEMA
Return a JSON object with the following structure:
{
  "traceability_matrix": [
    {
      "control_id": "string",
      "control_description": "string",
      "mapped_test_ids": ["string"],
      "coverage_status": "FULL_COVERAGE | INSUFFICIENT_COVERAGE | COVERAGE_GAP | NOT_APPLICABLE",
      "gap_description": "string | null",
      "risk_level": "CRITICAL | HIGH | MEDIUM | LOW | NONE",
      "recommended_action": "string"
    }
  ],
  "summary": {
    "total_controls": "number",
    "full_coverage_count": "number",
    "insufficient_coverage_count": "number",
    "gap_count": "number",
    "not_applicable_count": "number",
    "critical_gaps": "number",
    "high_gaps": "number"
  }
}

## EVALUATION CRITERIA
A valid output must satisfy:
- Every control from the input appears exactly once in the traceability_matrix.
- Mapped test IDs must exist in the provided test case inventory.
- Coverage status must be consistent with the mapped test IDs (empty array = COVERAGE_GAP).
- Risk level must align with the provided risk classifications.
- The summary counts must be arithmetically consistent with the matrix rows.

To adapt this template, replace [CONTROLS_LIST] with your structured security control data—typically a JSON array of objects with id, title, and description fields. Replace [TEST_CASES_LIST] with your test case inventory in a similar structured format, including id, name, and objective fields. The [RISK_CLASSIFICATIONS] placeholder should contain your organization's risk taxonomy, such as definitions for what constitutes a CRITICAL versus HIGH finding in your context. For regulated environments, add a [COMPLIANCE_FRAMEWORK] placeholder to the INPUTS section and reference it in the CONSTRAINTS to ensure the model aligns gap severity with audit expectations. Always validate the output JSON against the schema before ingesting it into a test management system or compliance report.

This prompt is designed to be called from a test management or security compliance pipeline, not as a one-off chat interaction. The typical integration point is a QA automation harness or a CI/CD gate that collects security control definitions (from a GRC tool, a YAML file, or a threat model) and existing test case metadata (from a test management system or code annotations) and passes them into the prompt. Because the output is a structured coverage matrix with gap severity ratings, the application layer must validate the returned schema before accepting it into any audit trail or ticketing system.

Wire the prompt into your application with a pre-validation step that checks input completeness: every control must have an ID, description, and risk level; every test case must have an ID, steps, and linked controls (if any). After the model returns the coverage matrix, run a schema validator that confirms the JSON structure matches the expected [OUTPUT_SCHEMA]—required fields include control_id, test_ids, coverage_status (covered/partial/gap), gap_severity, and remediation_recommendation. Reject and retry any response missing these fields or containing unmapped control IDs. For high-risk security workflows, route all gap_severity: critical findings to a human review queue before they become tickets. Log every prompt invocation with the input hash, model version, output schema validation result, and reviewer decision for auditability.

Choose a model with strong structured-output reliability and security domain knowledge. GPT-4o and Claude 3.5 Sonnet both perform well on control-to-test mapping when given explicit threat context. Set temperature to 0 or near-zero to reduce variance in coverage classifications. If your control library is large (50+ controls), split the prompt into batches by control family (e.g., access control, cryptography, data protection) and merge results in the application layer. For teams using retrieval-augmented generation, index your existing test case library and threat models so the prompt can include [CONTEXT] with relevant test snippets—this improves mapping accuracy and reduces hallucinated test references. Avoid using this prompt for real-time incident response; it is a planning and audit tool, not a detection system.