Best AI Prompts for Cybersecurity Professionals in 2026 (25 Copy-Paste Prompts)

**Prompt 1: Threat Model Writeup** Use this when: you need to document a threat model for a system, application, or infrastructure component — and want a structured writeup that covers adversaries, attack vectors, and mitigations. Write a threat model document for the following system. System description: [describe the system — what it does, who uses it, what data it handles, how it connects to other systems]. Deployment environment: [cloud / on-prem / hybrid — include key infrastructure details]. Trust boundaries: [describe where trust changes — e.g., internet-facing vs internal, user-facing vs admin]. Data sensitivity: [what categories of data does this system handle — PII, credentials, financial, proprietary]. Current security controls: [what's already in place — authentication, encryption, network segmentation, logging]. The threat model should include: (1) System overview and architecture summary, (2) Trust boundary diagram description (in text), (3) Threat actors — external attackers, malicious insiders, third-party suppliers, (4) Attack surface — entry points and exposed interfaces, (5) Top 5-7 threats using STRIDE or ATT&CK categories with likelihood and impact ratings, (6) Current mitigations for each threat, (7) Residual risk and recommended additional controls. Format as a structured security document. Why it works: Threat models documented informally or in bullet points miss the trust boundary analysis and attacker perspective that make them actionable. A structured writeup that maps threats to controls and surfaces residual risk gives security teams a document they can actually defend in audits and architecture reviews.

**Prompt 2: Risk Scoring Rationale** Use this when: you need to document the rationale behind a risk score — for a vulnerability, a finding, a vendor assessment, or a risk register entry — in language that's clear to both technical and non-technical reviewers. Write a risk scoring rationale for the following finding. Finding description: [describe the vulnerability or risk — what it is, where it exists, what it affects]. Scoring system used: [CVSS / DREAD / custom — describe the scale]. Raw scores: [likelihood: X/10, impact: X/10, or CVSS base score: X.X]. Affected assets: [systems, data, users, or business processes at risk]. Threat actors likely to exploit this: [who would realistically exploit this — external attacker, insider, automated scanner]. Current controls: [what mitigations are already in place that affect the score]. Business context: [how critical is the affected system to operations — revenue-generating, customer-facing, regulated data]. The rationale should: (1) State the final risk score and severity classification, (2) Explain the likelihood score with specific justification, (3) Explain the impact score with specific justification including business impact, (4) Note how existing controls affected the score, (5) State what would need to change to reduce the score. Write in clear language that a CISO or board member could understand without a security background. Why it works: Risk scores without written rationale get challenged in every review. A documented rationale that separates likelihood from impact, notes existing controls, and includes business context builds the shared understanding that makes risk-based prioritization decisions stick.

**Prompt 3: Vulnerability Prioritization** Use this when: you have a list of vulnerabilities from a scan or assessment and need to prioritize remediation — with clear rationale for which vulnerabilities to address first and why. Create a vulnerability prioritization analysis for the following findings. Vulnerability list: [paste your list — CVE IDs, CVSS scores, affected systems, and brief descriptions]. Environment context: [describe your environment — internet-facing systems, internal-only systems, data sensitivity tiers, patching cadence]. Business priorities: [which systems are most critical to operations — highlight revenue-generating, customer-facing, or regulated systems]. Resource constraints: [patching window availability, team capacity, change management requirements]. Produce: (1) A prioritized remediation order with clear rationale for each decision, (2) Quick wins — vulnerabilities with high impact and low remediation effort, (3) High-urgency items — vulnerabilities with active exploits in the wild or in regulated systems, (4) Deferred items — vulnerabilities with compensating controls already in place, (5) A risk acceptance recommendation for any items that can't be remediated in the near term, (6) A one-paragraph executive summary explaining the prioritization logic to a non-technical audience. Why it works: Raw vulnerability scan output gives you a list sorted by CVSS score with no context about your environment. A prioritization analysis that factors in asset criticality, existing controls, and remediation effort produces a workable action plan — not just a sorted list of numbers.

**Prompt 4: Attack Surface Analysis** Use this when: you need to document an attack surface analysis for an application, network segment, or organizational asset — either for a security review, a risk assessment, or pre-engagement scoping. Write an attack surface analysis for the following asset. Asset description: [describe the application, system, or network segment]. Exposure: [what is internet-facing, what is internal-only, what is third-party accessible]. Authentication and access: [how users and systems authenticate — SSO, API keys, certificates, passwords]. Data flows: [how data enters, moves through, and exits the system]. External integrations: [third-party services, APIs, or systems this connects to]. The analysis should cover: (1) External attack surface — internet-exposed entry points and their risk profile, (2) Internal attack surface — lateral movement opportunities once an attacker has initial access, (3) Supply chain attack surface — third-party dependencies and integrations, (4) Human attack surface — social engineering exposure, privileged user accounts, shared credentials, (5) Top 5 attack paths — how an attacker would realistically chain exposures to achieve a meaningful objective, (6) Current defensive coverage — where logging, detection, and prevention controls exist, (7) Coverage gaps — attack paths with insufficient visibility or control. Format as a structured analysis document suitable for a security architecture review. Why it works: Attack surface documentation that only maps systems misses the human and supply chain dimensions that account for the majority of successful breaches. A comprehensive analysis that covers all four surface areas and maps realistic attack paths gives defenders a complete picture of what they're actually protecting.

**Prompt 5: Risk Register Entry** Use this when: you need to write a formal risk register entry for a security risk — for a GRC platform, an audit, or a board-level risk report. Write a risk register entry for the following security risk. Risk description: [describe the risk in plain language — what could happen, how it could happen]. Risk category: [cybersecurity / data privacy / operational / third-party / compliance]. Affected assets or processes: [what systems, data, or business functions are at risk]. Likelihood assessment: [rare / unlikely / possible / likely / almost certain — with rationale]. Impact assessment: [negligible / minor / moderate / significant / severe — with rationale including financial, operational, reputational, and regulatory dimensions]. Inherent risk score: [before controls]. Current controls: [what mitigations are already in place]. Residual risk score: [after controls]. Risk owner: [the role responsible for managing this risk]. Treatment plan: [accept / mitigate / transfer / avoid — and the specific actions planned]. Review date: [when this entry should be reassessed]. Format as a complete risk register entry using standard GRC language. Include a one-sentence risk statement suitable for a board risk summary. Why it works: Risk register entries written inconsistently across a team make the register unusable for prioritization or reporting. A standardized entry with explicit inherent vs residual risk, clear ownership, and a treatment status produces a risk register that actually informs decision-making.

**Prompt 6: Incident Report Writing** Use this when: an incident has been contained and you need to write the formal incident report — for internal stakeholders, regulators, or affected parties. Write a formal security incident report for the following event. Incident summary: [describe what happened — type of incident, affected systems, timeline of discovery to containment]. Detection: [how the incident was detected — alert, user report, external notification]. Timeline: [key events with timestamps — first indicator, detection, escalation, containment, eradication, recovery]. Affected scope: [systems, data, users, or business functions impacted]. Root cause: [what enabled the incident — vulnerability, misconfiguration, human error, etc.]. Attacker actions (if known): [what the attacker did during the incident]. Response actions taken: [what the security team did at each phase]. Business impact: [operational, financial, reputational, or regulatory impact]. The report should include: (1) Executive summary (3-4 sentences, non-technical), (2) Incident overview — type, severity, and affected scope, (3) Timeline of events, (4) Technical details — attack method, affected systems, indicators of compromise, (5) Response actions — what was done and when, (6) Root cause analysis, (7) Remediation status — what's been fixed and what's in progress, (8) Recommendations — specific actions to prevent recurrence. Format as a formal incident report document. Why it works: Incident reports written in the aftermath of a stressful response often miss key details, lack consistent structure, and fail to make the root cause analysis explicit. A structured report that separates the executive summary from technical details ensures the right audience gets the right level of information.

**Prompt 7: Post-Mortem / Lessons Learned Draft** Use this when: the incident is resolved and you need to facilitate or document a post-mortem that produces actionable improvements — not a blame session. Write a security incident post-mortem document for the following event. Incident: [brief description of the incident and severity]. What happened: [the sequence of events from the attacker's and defender's perspectives]. What went well: [aspects of the detection, response, or communication that worked effectively]. What didn't go well: [gaps in detection, response delays, communication failures, tooling limitations, process breakdowns]. Contributing factors: [the systemic or environmental factors that made the incident possible or worse — not individual blame]. The post-mortem should include: (1) Incident summary (2-3 sentences), (2) Timeline with key decision points highlighted, (3) What went well — specific observations with lessons, (4) What needs improvement — specific gaps, each with a root cause statement (use the '5 Whys' framing where possible), (5) Action items — specific, assignable remediation actions with owners and due dates, (6) Metrics — MTTD (mean time to detect), MTTR (mean time to respond), data exposure duration or other relevant measurements. Frame all findings as systemic observations, not individual failures. Tone: constructive, specific, forward-looking. Why it works: Post-mortems that focus on 'who made the mistake' instead of 'what made the mistake possible' produce defensiveness, not improvement. A blameless structure that maps to systemic factors produces action items that actually reduce the likelihood of recurrence.

**Prompt 8: Escalation Communication to Leadership** Use this when: an active incident requires executive or board notification — and you need to communicate clearly, accurately, and without causing unnecessary panic while ensuring appropriate urgency. Write an escalation communication for the following security incident. Audience: [CISO / CEO / executive team / board — specify who is receiving this]. Incident status: [active and ongoing / contained / under investigation]. What we know: [confirmed facts — what happened, what systems are affected, what data may be involved]. What we don't yet know: [open questions — extent of breach, data exfiltration, attacker dwell time]. Actions already taken: [what the security team has done so far]. What we need from leadership: [a decision, an approval, a notification to regulators, public relations guidance]. The communication should: (1) State the situation clearly in the first sentence — this is not the place for buried lede, (2) Separate confirmed facts from working hypotheses, (3) Communicate severity without speculation, (4) State what the security team is doing without requiring technical understanding, (5) Make a specific ask — what decision or action is needed from this audience right now, (6) Provide a next update timeframe. Length: under 300 words. Format: direct, no jargon. Tone: urgent but controlled. Why it works: Escalation communications that bury the key facts in technical detail force executives to ask clarifying questions under time pressure, which slows decisions. A direct, fact-separated communication that makes a specific ask produces faster, better-informed decisions from leadership.

**Prompt 9: Runbook Creation** Use this when: you need to create or update an incident response runbook for a specific threat type — so that on-call analysts have a clear, step-by-step process to follow during an active event. Create an incident response runbook for the following threat type. Threat type: [ransomware / phishing compromise / data exfiltration / DDoS / insider threat / supply chain compromise — specify]. Environment context: [relevant systems, tools, and infrastructure the runbook should reference]. Detection sources: [SIEM alerts, EDR alerts, user reports, threat intel feeds — what triggers this runbook]. The runbook should include: (1) Overview — what this runbook covers and when to use it, (2) Severity tiers — how to classify the incident severity and what triggers each tier, (3) Immediate actions (first 30 minutes) — step-by-step actions to take in priority order, with specific commands or tool references where applicable, (4) Containment steps — how to isolate affected systems while preserving evidence, (5) Investigation steps — what to look for, where to look, and how to document findings, (6) Eradication steps — how to remove the threat, (7) Recovery steps — how to restore systems and verify integrity, (8) Communication checkpoints — who to notify at each stage and what to tell them, (9) Evidence collection requirements — what logs, artifacts, and screenshots to preserve for forensics or legal purposes, (10) Escalation criteria — when to engage external IR support, law enforcement, or legal counsel. Format as a numbered procedure document that an analyst could follow under stress. Why it works: Runbooks written as narrative documents get abandoned during active incidents. A numbered, action-oriented runbook with explicit decision points and escalation criteria is what on-call analysts can actually follow at 2am during an active event.

**Prompt 10: Timeline Reconstruction** Use this when: you need to reconstruct the timeline of a security incident from scattered log data, alert timestamps, and analyst notes — for a formal report, a regulatory filing, or an internal post-mortem. Help me reconstruct a security incident timeline from the following data. Log and event data: [paste relevant log excerpts, alert timestamps, analyst notes, and any other timestamped data you have]. Known facts: [what you already know happened — start, end, key events]. Open gaps: [periods where you have no data — gaps in log coverage, unknown attacker activity]. For each event in the timeline: (1) Timestamp (in UTC, or note timezone), (2) Source — which system or log produced this data, (3) Event description — what happened, in plain language, (4) Significance — why this event matters to the incident narrative, (5) Confidence level — confirmed / probable / estimated. Format as a chronological timeline table followed by a narrative summary that ties the events into a coherent incident story. Flag any timeline gaps where attacker activity is unknown and note what log source could fill the gap. Why it works: Incident timelines assembled manually from scattered data sources often have gaps, inconsistencies, and ambiguities that weaken the post-mortem and complicate regulatory reporting. A structured reconstruction that separates confirmed from estimated events and explicitly flags gaps produces a defensible, complete narrative.

**Prompt 11: Phishing Awareness Email** Use this when: you need to create a phishing awareness communication — either a simulated phishing scenario for testing, a warning to staff about an active campaign, or a training email explaining how to spot phishing. Write a phishing awareness email for the following purpose. Purpose: [simulated phishing scenario / active phishing warning to staff / training email on how to spot phishing — specify]. Target audience: [all staff / specific department — e.g., finance, HR, executives]. If simulated phishing scenario: Pretend to be [describe the impersonation — IT helpdesk, a vendor, a C-suite executive, a HR system] and write a realistic phishing email designed to test [credential harvesting / malicious attachment / business email compromise / urgency manipulation]. Include the red flags that make it a training opportunity. If active warning or training email: Write a clear, concise email that: (1) States the threat in plain language, (2) Shows 3-5 specific red flags to look for, (3) Tells staff exactly what to do if they receive a suspicious email, (4) Provides a reporting mechanism. Tone for training emails: clear, non-alarmist, actionable. Length: under 300 words. Why it works: Generic phishing awareness emails get ignored. Role-specific simulations that mirror actual current threats — business email compromise for finance, vendor impersonation for procurement — produce measurably higher click-through in simulations, which means the training is actually testing real-world susceptibility.

**Prompt 12: Security Policy Plain-Language Summary** Use this when: you need to translate a formal security policy into clear, plain-language guidance that non-technical employees can understand and follow. Translate the following security policy into a plain-language employee guide. Policy: [paste the policy text or provide the key requirements]. Target audience: [all employees / a specific role or department — describe their technical level]. The plain-language summary should: (1) State what the policy requires in plain English — no jargon, (2) Explain why it matters in terms employees relate to — data breach consequences, personal liability, business impact, (3) Tell employees exactly what to do and not do — specific, actionable behaviors, (4) Give concrete examples of what compliance looks like day-to-day, (5) Address the most common 'what about...' questions you anticipate employees asking, (6) State who to contact with questions or to report a potential violation. Format as a one-page employee guide with clear sections. Reading level: accessible to a non-technical employee with no security background. Avoid: 'you must,' 'it is prohibited to,' and other compliance-speak. Use: 'here's what this means for you,' 'if you ever..., here's what to do.' Why it works: Security policies written for legal compliance produce employees who sign acknowledgment forms they've never read. Plain-language guides that explain the 'why' and give concrete examples produce employees who actually change their behavior.

**Prompt 13: Lunch-and-Learn Talking Points** Use this when: you've been asked to present a security topic at a team meeting, lunch-and-learn, or all-hands — and need talking points that engage a non-technical audience without putting them to sleep. Create lunch-and-learn talking points for the following security topic. Topic: [the security topic — e.g., 'How phishing attacks work and how to spot them,' 'Why password managers matter,' 'What to do if you think you've been hacked,' 'How ransomware spreads and what stops it']. Audience: [describe who will be in the room — department, technical level, likely attitude toward security topics]. Time available: [15 minutes / 30 minutes / 45 minutes]. The talking points should include: (1) An opening hook — a real-world story or statistic that grabs attention in the first 30 seconds (no dry agenda slides), (2) The core message — one thing you want every person in the room to remember and do differently after this session, (3) 3-4 main points — each with a concrete example or analogy that makes it relatable to non-technical employees, (4) One interactive element — a question to ask the audience, a quick show of hands, or a brief scenario to work through together, (5) A specific call to action — what you want employees to do today, not 'be more aware,' (6) Q&A anticipated questions — the 3 most likely questions this audience will ask and how to answer them. Format as presenter notes, not slides. Why it works: Security awareness sessions built on compliance slide decks don't change behavior. An engaging opening hook, concrete examples, and a specific actionable takeaway produce measurably higher retention and behavior change than the traditional policy walkthrough.

**Prompt 14: Security Quiz Questions** Use this when: you need to create a security awareness quiz — for post-training assessment, a security awareness campaign, or a phishing simulation debrief. Create security awareness quiz questions for the following topic and audience. Topic: [phishing / password security / data handling / physical security / incident reporting / social engineering — specify]. Audience: [all employees / a specific department — describe their technical level]. Number of questions: [5 / 10 / 15]. Format: [multiple choice / true-false / scenario-based / mix]. For each question: (1) Write the question in plain, non-jargon language, (2) Provide 4 answer options for multiple choice (1 clearly correct, 2 plausible but wrong, 1 obviously wrong), (3) Mark the correct answer, (4) Write a brief explanation (2-3 sentences) of why the correct answer is right and why the common wrong answer is wrong — this is the learning moment, (5) Tag the difficulty: beginner / intermediate / advanced. Include at least [X] scenario-based questions that present a realistic situation and ask what the employee should do. Avoid trick questions — the goal is to reinforce correct behavior, not to catch people out. Why it works: Quiz questions without explanations for wrong answers are assessment tools, not learning tools. A well-designed quiz that explains why wrong answers are wrong — especially for the plausible-but-incorrect options — produces the behavioral correction that multiple-choice alone doesn't.

**Prompt 15: Onboarding Security Training Outline** Use this when: you need to design or update the security training component of your employee onboarding program — covering the key policies, behaviors, and reporting mechanisms every new employee needs to know. Create a security awareness training outline for new employee onboarding. Organization context: [describe your organization — industry, size, any specific regulatory environment — e.g., healthcare/HIPAA, financial/PCI, general corporate]. New employee profile: [describe the typical new hire — technical background, role type, first-day experience with IT systems]. Compliance requirements: [any mandatory training topics — HIPAA, PCI awareness, GDPR, SOC 2 employee requirements — specify what must be covered]. Format: [self-paced module / instructor-led session / video-based / hybrid — specify]. Time allocated: [30 minutes / 1 hour / spread across onboarding week]. The outline should include: (1) Learning objectives — 3-5 specific behaviors the employee should demonstrate after completing this training, (2) Module structure — sections with titles, estimated time, key content per section, and the learning objective each section serves, (3) Key topics — password and credential management, phishing recognition, data handling and classification, physical security, acceptable use, incident reporting, (4) Reinforcement mechanism — how to check understanding (quiz, scenario, attestation), (5) Post-training resources — where employees can go with questions or to report incidents, (6) Follow-up touchpoints — what happens at 30/60/90 days to reinforce the training. Format as a curriculum design document with clear structure. Why it works: Onboarding security training designed as a compliance checkbox produces employees who click through slides and forget everything. A training outline built around behavioral objectives and reinforcement touchpoints produces employees who actually internalize the security behaviors that reduce organizational risk.

**Prompt 16: SOC 2 / ISO 27001 Control Description** Use this when: you need to write or update a formal control description for a SOC 2 or ISO 27001 audit — in language that satisfies auditors and accurately represents how the control works. Write a control description for the following security control. Control: [describe the control — what it is, how it works, who is responsible for operating it]. Framework: [SOC 2 (specify Trust Service Criteria — CC, A, C, PI, P) / ISO 27001 (specify Annex A control)]. Control type: [preventive / detective / corrective / compensating]. Implementation details: [the specific tools, processes, or configurations that implement this control — e.g., 'Access reviews are conducted quarterly using Okta's access certification workflow. The system owner and HR manager approve each review. Evidence is stored in [system].']. Testing frequency: [how often the control is tested or reviewed internally]. The control description should include: (1) Control name and identifier, (2) Control objective — what risk this control addresses, (3) Control description — a precise, complete description of how the control is implemented and operated, written in auditor-expected language, (4) Control owner — role responsible, (5) Testing procedure — how the control is tested to confirm it's operating effectively, (6) Evidence artifacts — what documentation or artifacts demonstrate the control is in place. Avoid vague language like 'controls are in place' or 'the system restricts access' — be specific about the mechanism, the frequency, and the owner. Why it works: Vague control descriptions produce auditor questions and additional evidence requests. Specific control descriptions that include the mechanism, frequency, owner, and evidence artifacts produce clean audits because there's no ambiguity for the auditor to probe.

**Prompt 17: Audit Response Draft** Use this when: you've received an auditor's finding, request for information, or management letter comment — and need to draft a formal written response that addresses the finding while accurately representing your organization's position. Draft an audit response for the following finding or request. Auditor finding or request: [paste the exact language of the finding or RFI]. Finding context: [describe the context — is this finding accurate? Is there a compensating control? Is there a remediation already in progress?]. Our position: [agree / partially agree / disagree — and the specific factual basis for your position]. Remediation plan (if applicable): [what specific actions you're taking, who owns them, and the timeline]. The response should: (1) Acknowledge the finding clearly — don't be defensive, (2) State whether you agree or disagree, with factual basis — not emotional language, (3) Describe any compensating controls that weren't observed during the audit, (4) Provide the remediation plan with specific actions, owners, and due dates, (5) Note any findings you dispute factually, with supporting evidence. Tone: professional, factual, constructive. Avoid: defensiveness, vague commitments ('we will work to improve'), or promises you can't keep. Format: formal written response document suitable for inclusion in the audit management letter. Why it works: Audit responses written reactively under time pressure often over-promise or under-explain, creating tracking problems and follow-on findings. A structured response that separates factual agreement from remediation commitments and includes specific owners and dates builds auditor confidence and reduces audit cycle time.

**Prompt 18: Evidence Collection Checklist** Use this when: you have an upcoming audit or compliance review and need to organize your evidence collection — ensuring you gather the right artifacts for each control before the auditor asks for them. Create an evidence collection checklist for the following audit. Audit type: [SOC 2 Type II / ISO 27001 / PCI DSS / HIPAA / FedRAMP / internal audit — specify]. Audit scope: [the systems, services, or business units in scope]. Audit period: [the dates your controls are being assessed against — e.g., January 1 to June 30, 2026]. Controls in scope: [list the control domains or specific controls being assessed — or specify 'all Trust Service Criteria' if SOC 2]. For each control domain: (1) List the specific evidence artifacts required — screenshots, reports, access logs, policy documents, procedure documentation, training records, vendor assessments, (2) Note the evidence format auditors typically accept, (3) Assign a collection owner (role, not name), (4) Note the evidence retention system (where it lives), (5) Flag evidence that requires scheduling in advance — access reviews, penetration test reports, board meeting minutes. Format as a master checklist organized by control domain, with a status column for tracking. Include a section for commonly forgotten evidence items that create last-minute scrambles. Why it works: Evidence collection without a pre-built checklist produces the two-week audit scramble where every day brings a new urgent evidence request. A complete checklist organized by control domain, with owners and lead times identified, converts audit preparation from a crisis into a scheduled workflow.

**Prompt 19: Gap Analysis Summary** Use this when: you've completed an internal assessment, a readiness review, or a vendor assessment against a framework — and need to document the gaps in a format that supports prioritization and remediation planning. Write a gap analysis summary for the following assessment. Framework or standard: [SOC 2 / ISO 27001 / NIST CSF / PCI DSS / CIS Controls — specify]. Assessment scope: [what was assessed — organization-wide / specific system / specific business unit]. Assessment findings (raw): [paste your assessment findings, control test results, or assessment notes]. Remediation context: [what resources or constraints affect the remediation — team size, budget, timeline to target audit date]. The gap analysis summary should include: (1) Executive summary — overall maturity level, number of gaps by severity, and the top 3 priority areas, (2) Gap inventory — each gap listed with: control reference, gap description, current state, target state, severity (critical / high / medium / low), and recommended remediation approach, (3) Prioritization rationale — why the high-priority items were ranked first (audit risk, exploit risk, regulatory requirement, quick win), (4) Remediation roadmap — a phased plan organized by priority tier with realistic timelines, (5) Resource requirements — what's needed to close the gaps (FTE effort, tooling, third-party support). Format as a working document that the security team can use to track remediation progress. Why it works: Gap assessments that produce a list of findings without prioritization rationale force security teams to re-prioritize the same findings in every planning meeting. A structured gap analysis with explicit severity ratings and a phased remediation plan converts assessment findings into an actionable program.

**Prompt 20: Policy Documentation** Use this when: you need to write, update, or restructure a security policy document — ensuring it covers the necessary requirements, is readable by the intended audience, and meets the standards expected by auditors. Write a security policy document for the following topic. Policy topic: [access control / acceptable use / data classification / incident response / password / remote work / third-party vendor — specify]. Regulatory context: [any specific frameworks or regulations this policy must satisfy — SOC 2, ISO 27001, HIPAA, PCI — note the specific requirements]. Organization context: [company size, industry, technical environment]. Policy owner: [role responsible for maintaining the policy]. Review cycle: [how often this policy is reviewed — annually / semi-annually]. The policy should include: (1) Purpose — why this policy exists and what risk it addresses, (2) Scope — who and what systems this policy applies to, (3) Policy statements — the specific requirements, in plain but authoritative language; organize by control area, (4) Roles and responsibilities — who is responsible for implementing and enforcing each requirement, (5) Exceptions process — how to request an exception and who approves it, (6) Enforcement — consequences for policy violations, (7) Definitions — key terms used in the policy, (8) Related policies and procedures — cross-references, (9) Document control — version history, owner, review date. Format as a formal policy document with clear section headers. Language: authoritative but plain — accessible to the employees it governs, defensible in an audit. Why it works: Security policies written to satisfy auditors often satisfy only auditors — employees find them unreadable and ignore them. A policy structure that balances audit defensibility with plain-language requirements produces policies that employees can follow and auditors can validate.

**Prompt 21: CISSP/CEH Interview Preparation** Use this when: you have a CISSP, CEH, CISM, or other security certification exam or professional interview coming up and want to systematically prepare across the domains tested. Help me prepare for the [CISSP / CEH / CISM / Security+ / OSCP — specify] [exam / professional interview]. My current background: [describe your security experience — years in the field, domains of expertise, tools you use, current role]. Target exam/interview date: [when you're aiming to test or interview]. My strongest domains: [list the areas where you feel confident]. My weakest domains: [list the areas where you feel less prepared]. For the weakest domains, provide: (1) A concise review of the core concepts tested in that domain, (2) 5 practice questions at the difficulty level of the actual exam, with explained answers, (3) The key terms and frameworks you must know cold, (4) Common misconceptions or trick question patterns to watch for. For interview preparation: (1) The 5 most common behavioral and situational questions for this level/role, (2) A structured framework for answering scenario-based questions, (3) Technical questions you should be ready to answer from your experience. Create a 2-week study plan that addresses my weak areas without sacrificing time on my strong domains. Why it works: Security certification preparation done without structured domain review produces exam anxiety in your weakest areas and false confidence in your strongest. A targeted prep plan that addresses specific domain gaps and provides practice questions with explained answers produces both the knowledge and the confidence to perform.

**Prompt 22: Cybersecurity Resume Writing** Use this when: you're updating your resume for a security role — analyst, engineer, pen tester, CISO, or any security specialty — and want to translate your experience into impact-forward bullets that signal seniority and technical depth. Rewrite the following cybersecurity resume content for impact. Target role: [describe the role — level, company type, specialization — e.g., 'Senior Security Analyst at a financial services company' / 'Penetration Tester at a Big 4 firm']. My current bullets (rough): [paste your existing resume content — job descriptions, responsibilities, accomplishments]. For each bullet: (1) Lead with a quantifiable outcome where possible — incidents detected, systems hardened, vulnerabilities remediated, audit findings closed, time-to-detect improved, (2) Show technical specificity — name the tools, frameworks, or technologies used, (3) Demonstrate scope — team size, budget managed, systems protected, or business functions supported, (4) Use active verbs — 'architected,' 'deployed,' 'reduced,' 'led,' 'identified' — not 'responsible for' or 'assisted with,' (5) For bullets without metrics — ask me the specific questions to surface them: what was the before/after, the incident count, the audit outcome, the detection improvement. After each rewrite, explain the change and why it's stronger for the target role. Include a technical skills section recommendation based on the role requirements. Why it works: Security resumes often describe responsibilities ('managed SIEM alerts') instead of impact ('reduced mean time to detect from 4 hours to 45 minutes by tuning SIEM alert logic for 200+ custom rules'). Hiring managers for senior security roles scan for evidence of ownership and measurable outcomes — not job descriptions.

**Prompt 23: Salary Negotiation for Security Roles** Use this when: you have a job offer for a security role and want to negotiate compensation — base salary, equity, signing bonus, certifications, or remote work flexibility — in a way that's grounded in your specific leverage. Write a compensation negotiation script for the following situation. Offer received: [describe the offer — base, bonus, equity or RSUs, level, title, company, and any specific benefits]. My background and leverage: [describe your specific experience, certifications, and what makes your ask reasonable — competing offer, in-demand skill set, niche expertise, clearance, years of experience in a specific domain]. Market data I have: [any compensation benchmarks you've found — LinkedIn Salary, Glassdoor, Levels.fyi, SANS Salary Survey, or recruiter conversations]. My target: [what you're trying to achieve — specific numbers or ranges]. The script should include: (1) How to respond when the offer is made — what to say to buy time without accepting or declining, (2) The counter-offer email or script — how to frame the ask using your specific leverage and market data, (3) How to handle 'That's the top of our band' — two responses: one if you want the job at any achievable comp, one if you won't accept at band top, (4) Non-salary levers — signing bonus, certification reimbursement (CISSP, OSCP, CEH), home lab budget, conference allowance, remote flexibility, additional vacation, (5) How to close the negotiation positively once you're satisfied. Write in natural, direct language — not scripted or robotic. Why it works: Security professionals with in-demand skills — cloud security, offensive security, OT/ICS, cleared professionals — have more negotiating leverage than most realize. A prepared script that uses specific leverage (certifications, clearance, competing offer) instead of generic 'I deserve more' framing produces materially better compensation outcomes.

**Prompt 24: IT to Security Career Transition** Use this when: you're currently in an IT, sysadmin, network engineering, or helpdesk role and want to transition into cybersecurity — and need a specific, realistic action plan for making the move. Help me plan a transition into cybersecurity from my current IT background. My current role and experience: [describe your current role — title, years of experience, skills, tools you use daily — e.g., 'Network administrator with 4 years managing Cisco infrastructure and Active Directory for a 500-person company']. Security knowledge today: [what security knowledge you already have — formal or self-taught]. Target role: [describe the security role you're aiming for — analyst, SOC analyst, penetration tester, security engineer, GRC analyst]. Timeline goal: [when you want to make the move — 6 months / 12 months / 2 years]. Create a transition plan that includes: (1) Narrative reframe — how to position your IT background as security experience, not a gap; the specific transferable skills to highlight in your resume and interviews, (2) Certification roadmap — which certifications to pursue in what order, given your background and target role (e.g., CompTIA Security+ → CySA+ → SSCP → domain-specific), (3) Hands-on skill building — specific home lab projects, CTF platforms, or practice environments to build the technical skills hiring managers look for, (4) Portfolio strategy — what artifacts to create to demonstrate security competence: writeups, CTF solutions, home lab documentation, a security blog, (5) Job application strategy — which entry-level or transitional roles to target first, (6) 30/60/90 day action plan with specific weekly actions. Be honest about what takes time and what can be accelerated. Why it works: IT professionals transitioning to security often underestimate how much their existing experience transfers — and overestimate how much new knowledge they need to acquire. A structured transition plan that leads with the narrative reframe and builds toward certification and portfolio produces faster, higher-quality transitions.

**Prompt 25: Security Portfolio & Blog Strategy** Use this when: you want to build a visible professional presence in the security community — through a technical blog, CTF writeups, conference talks, or open-source contributions — to accelerate career advancement and build credibility. Help me build a cybersecurity professional portfolio and blog strategy. My background: [describe your experience — specialization, years in security, notable projects or work]. My goals: [describe what you want to achieve — job advancement, speaking opportunities, building a reputation in a specific domain, attracting recruiter attention, consulting opportunities]. Target audience for the portfolio/blog: [hiring managers / security professionals / CISOs / the broader community — specify]. My specialization: [the security domain you want to be known for — cloud security, red team / offense, GRC, threat intelligence, detection engineering, application security, etc.]. The strategy should include: (1) Content pillars — 3-4 topic areas to write about consistently, based on your expertise and what the audience values, (2) Content formats — which formats to prioritize: CTF writeups, vulnerability research, tool builds, career advice, threat intel analysis, compliance deep-dives, (3) Platform strategy — where to publish: personal blog / GitHub / Medium / LinkedIn / DEF CON / BSides / security-specific communities, (4) Content calendar — a 90-day content plan with specific post ideas and rough outlines, (5) SEO and discoverability — how to make your content findable by the people you want to reach, (6) Community engagement — how to get your work in front of the right people without being spammy. Format as a working strategy document with a clear 90-day execution plan. Why it works: Security professionals who publish consistently — even once or twice a month — build professional visibility that outpaces their equally-skilled peers who don't. A single well-written CTF writeup or technical blog post can produce recruiter outreach, conference invitations, and consulting leads that years of quiet competence never will.