Why it is written this way
Tap a block to see its paragraph
You are a pragmatic security engineer experienced in auditing deployments for small development teams. You understand what a team with limited time and resources can realistically implement.
The service we are preparing to deploy is a {{service type}}. Our stack is {{technology stack}}, and the data stored or processed by this service includes {{handled data}}.
Do not provide a generic, one-size-fits-all security checklist. Break your response into two distinct steps. First, identify 5 to 8 realistic attack vectors specific to this setup and briefly explain each in one sentence. Next, generate actionable pre-deployment checklist items directly tied to each attack vector.
Format the checklist as a Markdown table with the following columns: Checklist Item | Why It Matters | Verification Method (concrete steps, configs to inspect, or manual checks I can perform) | Risk Level (High/Medium/Low) | Estimated Time. Below the table, list up to 3 commonly recommended checks that were explicitly excluded because they are "Not Applicable to This Stack," along with brief justifications.
After drafting the list, critically self-review each item against the specified technology stack and handled data. Remove any irrelevant checks and output only the final, vetted list.
Do not make definitive legal or compliance claims; flag items requiring formal audits as "Requires Specialist Review." Do not invent unverified configuration flags or settings—indicate where to check the official documentation if uncertain.
- Role Who answers ×1
- Material What the AI needs to know ×1
- Work What to do, and how ×2
- Output What comes back, in what shape ×2
When you ask an AI for a generic security checklist, you typically get a textbook table of contents. Half of the items apply to features you do not even use, while the highest-risk areas of your specific architecture are overlooked. You finish reading with no clear answer to "So, what do I actually check?"
Read the full explanation · 3 paragraphs
Setting the Role as an engineer who reviews deployments for small teams keeps the scope practical. An enterprise auditor perspective results in extensive organizational policy and documentation requirements that a 3-person team cannot realistically execute. Checklists that cannot be completed end up being ignored entirely.
Splitting the task into identifying attack vectors first and building the checklist second is essential. Mapping attack vectors surfaces architecture-specific exposure points—such as custom auth implementations, file upload endpoints, or exposed admin panels—and anchors subsequent checks directly to them.
In the output Format, the "Verification Method" column turns passive guidelines into actionable tasks. Instead of vague advice like "Validate all inputs," giving concrete instructions on what file to inspect or which endpoint to test enables immediate execution. The final self-Review step acts as a filter against generic filler. (Note: A checklist generated via ChatGPT is only a baseline; projects handling PII or payments still require dedicated expert review.)
Unfamiliar terms? See Aha AI: role-prompting, output-format
Compared with a bad example
Give me a security checklist to review before deploying my web service.
This prompt returns a generic checklist found anywhere online. You will waste time verifying irrelevant features while critical attack surfaces—such as custom auth or exposed admin routes—go unchecked. Lacking concrete "how-to-verify" steps, the list cannot be delegated across the team, and deployment usually proceeds based on guesswork.
Variations
Auditing a live service in production
The priority order changes when auditing production systems. Starting with non-disruptive checks ensures immediate progress without delaying the audit.
Show prompt
I need to perform a security audit on a live, production {{service type}}. Our architecture is {{technology stack}}, and the service handles {{handled data}}. Categorize the checklist into items that can be safely verified without downtime versus those requiring scheduled maintenance. Add a one-line temporary mitigation strategy for each item in case a vulnerability is found.
Security checklist tailored for code reviews
Designed for use during code reviews rather than final release testing. Easily integrated directly into team PR review guidelines.
Show prompt
Create a code review checklist focusing on common security flaws in a {{technology stack}} codebase. Group items by file type or architectural layer, using concise "Flag if you see..." rules. Limit the list to 10 high-impact items, placing checks related to {{handled data}} at the top.
Model notes
This checklist is a self-audit starting point, not a formal security certification. If you handle personal data or payments, consult a dedicated security professional.
Last updated 2026-09-02 · Found a mistake? Let us know