Security Non-Functional Requirements Extraction Prompt

Architects and security engineers use this prompt to move from narrative architecture descriptions and compliance documents to a structured, testable list of security non-functional requirements (NFRs). The core job-to-be-done is extracting measurable acceptance criteria—such as 'session tokens must be invalidated server-side within 60 seconds of logout'—and linking each requirement to a specific control from a standard like NIST SP 800-53, OWASP ASVS, or an internal threat model. This prompt is designed for the design review phase, after threat modeling has identified risks and before implementation planning begins. The ideal user has a design document, a compliance standard, and a threat model in hand, and needs to produce a prioritized NFR register that QA and platform engineering can test against.

This prompt requires structured input to produce reliable output. You must supply a [DESIGN_DOCUMENT] containing the system's architecture, data flows, and trust boundaries, a [COMPLIANCE_STANDARD] or control framework to map against, and a [THREAT_MODEL] that identifies specific threats and their severities. The prompt uses these to generate a table of NFRs, each with a unique ID, a measurable criterion, a priority derived from threat severity, and a traceable control reference. Do not use this prompt when you lack a threat model or design document—without them, the model will invent plausible but untethered requirements that fail audit. Do not use it for real-time operational security decisions or incident response; it is a design-time tool, not a runtime guardrail. For high-risk regulated environments, always require a human security architect to review and approve the output before it enters a requirements management system.

The output is a structured NFR list, not a final security policy. Treat it as a draft that accelerates the requirements engineering process. After generation, validate that every NFR is testable—if you cannot write a test case for an acceptance criterion, the requirement is too vague. Wire the output into your requirements traceability matrix and link each NFR back to the originating threat and control. Common failure modes include the model generating requirements for threats not present in your model, omitting data residency constraints, or producing criteria that are not measurable. The next step is to run the output through the evaluation harness described in the testing section of this playbook, checking for coverage gaps, duplicate requirements, and untestable criteria before handing off to the implementation team.

The prompt below instructs the model to extract, prioritize, and structure security non-functional requirements from your provided inputs. It enforces a strict output schema, requires measurable acceptance criteria for every NFR, and demands traceability from each requirement back to a specific control, threat, or compliance reference. Copy the template, replace the square-bracket placeholders with your actual documents, and run it against a capable model.

textCopy
You are a security architect extracting testable non-functional requirements (NFRs) from design documents, compliance standards, and threat models.

## INPUTS
- Design Documents: [DESIGN_DOCUMENTS]
- Compliance References: [COMPLIANCE_REFERENCES]
- Threat Model Output: [THREAT_MODEL_OUTPUT]
- Risk Appetite: [RISK_APPETITE]

## TASK
1. Extract every security-related NFR implied or stated in the inputs.
2. For each NFR, derive one or more measurable acceptance criteria that would allow a reviewer to verify whether the requirement is met.
3. Map each NFR to the specific control, threat, or compliance clause that justifies it. If no direct source exists, mark the traceability as "Derived from architectural best practice" and explain the reasoning.
4. Assign a priority (Critical, High, Medium, Low) based on the risk appetite and the severity of the threat or compliance gap the NFR addresses.
5. Identify any conflicting NFRs and note the conflict with a recommended resolution.

## OUTPUT SCHEMA
Return a valid JSON object with this exact structure:
{
  "project": "string",
  "risk_appetite": "string",
  "extraction_timestamp": "string (ISO 8601)",
  "non_functional_requirements": [
    {
      "nfr_id": "string (e.g., SEC-NFR-001)",
      "category": "string (e.g., Authentication, Authorization, Data Protection, Audit, Resilience, Network Segmentation)",
      "requirement": "string (the NFR statement)",
      "priority": "Critical | High | Medium | Low",
      "acceptance_criteria": ["string (measurable criterion)"],
      "traceability": [
        {
          "source_type": "design_document | compliance_reference | threat_model | derived",
          "source_id": "string (document section, control ID, threat ID, or 'derived')",
          "rationale": "string (why this source justifies the NFR)"
        }
      ],
      "conflicts": [
        {
          "conflicting_nfr_id": "string",
          "description": "string",
          "recommended_resolution": "string"
        }
      ]
    }
  ],
  "unresolved_gaps": ["string (areas where the inputs lacked sufficient detail to define NFRs)"]
}

## CONSTRAINTS
- Every NFR must have at least one measurable acceptance criterion. Do not use vague terms like "secure" or "robust" without a specific measurement.
- Every NFR must have at least one traceability entry.
- If the inputs contain no information about a security domain (e.g., no mention of audit logging), add an entry to `unresolved_gaps` rather than inventing requirements.
- Do not include functional requirements, user stories, or implementation details. Focus strictly on non-functional security properties.
- If the risk appetite is "Low" or "Conservative", raise the priority of data protection and audit NFRs by one level.

After copying the template, replace each placeholder with the actual content from your architecture review. For [DESIGN_DOCUMENTS], paste the relevant sections of your system design, API specs, and data flow diagrams. For [COMPLIANCE_REFERENCES], include the specific control IDs and text from SOC 2, ISO 27001, PCI DSS, HIPAA, or your internal policy documents. For [THREAT_MODEL_OUTPUT], paste the structured output from your STRIDE or attack-tree analysis. The [RISK_APPETITE] placeholder should be set to one of "Aggressive", "Moderate", "Conservative", or "Low" to calibrate the priority assignment logic. If you lack a formal threat model, you can substitute a summary of known threats and attack surfaces, but the traceability quality will degrade. Run the prompt, validate the JSON output against the schema, and feed any unresolved_gaps back into your architecture review process before finalizing the NFR list.

The Security Non-Functional Requirements Extraction prompt is designed to be embedded in a structured pipeline, not used as a one-off chat interaction. The typical harness accepts a design document, compliance standard reference, or threat model as input, invokes the LLM with the prompt template, validates the structured output, and routes the result to a review queue or downstream requirements management system. Because the output directly influences security architecture decisions, the harness must enforce schema compliance, traceability, and human approval before any extracted NFR is accepted as a committed requirement.

Wire the prompt into an application by first constructing the input context from source documents. If the design document is long, pre-process it with a chunking strategy that preserves section boundaries and sends only the security-relevant sections—authentication flows, authorization models, data protection, network boundaries, and secrets handling. Attach the relevant compliance standard excerpts as [COMPLIANCE_CONTEXT] and any existing threat model findings as [THREAT_MODEL_CONTEXT]. The prompt returns a JSON array of NFR objects, each containing an id, requirement, category, priority, measurable_criteria, and traceable_controls. Validate this output immediately: check that every NFR has a non-empty measurable_criteria field, that priority values are from the allowed enum (Critical, High, Medium, Low), and that traceable_controls maps to at least one control from the provided compliance standard or threat model. Reject and retry any response that fails schema validation, using a repair prompt that includes the validation error details and the original context. After three failed retries, escalate to a human reviewer with the partial output and error log.

Model choice matters here. Use a model with strong reasoning capabilities and a large context window—GPT-4o, Claude 3.5 Sonnet, or Gemini 1.5 Pro are appropriate for production use. Set temperature to 0.1 or lower to maximize consistency across runs. Log every extraction attempt: the input document hash, prompt version, model identifier, raw response, validation result, and final accepted NFR set. This audit trail is essential for governance reviews and for debugging when extracted requirements don't match reviewer expectations. After validation passes, route the NFR list to a human security architect for approval. The approval UI should display each NFR alongside its source evidence—highlight the sentence or paragraph in the design document that motivated the requirement—so the reviewer can confirm traceability without re-reading the entire document. Only after human sign-off should the NFRs be written to the requirements backlog or architecture decision log. Avoid the temptation to auto-commit extracted NFRs without review; a hallucinated security requirement that enters the backlog wastes engineering time and erodes trust in the AI-assisted workflow.