Create an implementation plan for this authorized cybersecurity project. Project objective and risk to reduce: [PROJECT OBJECTIVE] Organization, systems, data, and users in scope: [ENVIRONMENT AND SCOPE] Current controls, known gaps, and relevant incidents or audit findings: [CURRENT STATE] Team, decision makers, budget, and deadline: [RESOURCES AND TIMELINE] Compliance or framework requirements: [REQUIREMENTS] First, define the threat scenario, assets at risk, likely attack paths, business impact, and project boundary. State what is explicitly out of scope. Do not provide instructions for accessing systems, bypassing controls, exploiting vulnerabilities, credential theft, persistence, or evasion.
Produce a practical project charter and delivery plan with:
1. A risk statement, success criteria, assumptions, dependencies, and non-goals.
2. A control design that maps each proposed safeguard to the stated threat and to [REQUIREMENTS] where applicable. Cover people, process, and technology, not just a tool purchase.
3. A work breakdown table with task, accountable owner, contributors, dependency, estimated duration, deliverable, and acceptance evidence.
4. Milestones for discovery, design approval, pilot, remediation, rollout, validation, and handoff. Include rollback criteria and a communications plan for affected users.
5. A validation plan using authorized configuration review, logging checks, tabletop exercises, or approved testing. Define what evidence proves the control works and what triggers escalation.
6. A risk register with likelihood, impact, mitigation, and residual-risk owner.
Prioritize the smallest sequence that reduces the most material risk without interrupting critical operations. Do not invent system inventory, compliance obligations, test results, owners, dates, or control coverage. Before answering, check that every task has an accountable owner and acceptance criterion, and that every proposed test stays within the authorized scope. Ask up to 3 clarifying questions only if a required input is missing.Fill in
| Placeholder | What to enter | Example |
|---|---|---|
| [PROJECT OBJECTIVE] | Describe the approved security outcome and the risk or incident pattern it must address. | Roll out phishing-resistant MFA for privileged access to reduce account-takeover risk after two employee mailbox compromises. |
| [ENVIRONMENT AND SCOPE] | List the authorized systems, data types, users, integrations, and boundaries for the project. | Azure AD tenant, Microsoft 365, AWS IAM roles used by 35 engineers, and 12 IT administrators; production servers and customer environments are out of scope. |
| [CURRENT STATE] | Describe existing controls, gaps, findings, incidents, and known technical constraints. | Authenticator-app MFA is optional for some admins; conditional access exists but has no break-glass test; audit found shared administrator accounts in two legacy systems. |
| [RESOURCES AND TIMELINE] | List available team roles, approvers, budget range, rollout constraints, and target deadline. | Security manager owns the project; IT admin and identity engineer available part time; $18,000 hardware-key budget; complete before December 15; no outage during month-end close. |
| [REQUIREMENTS] | List applicable policies, contractual obligations, and frameworks such as NIST CSF, ISO 27001, HIPAA, or PCI DSS. | NIST CSF 2.0, SOC 2 access-control commitments, and internal privileged-access policy. |
How to use
- Scope the systems and identities explicitly, including exclusions, before asking for a timeline or tool recommendation.
- Paste the actual audit finding or incident lesson so the plan targets a known risk rather than a generic control checklist.
- Confirm accountable owners and change windows with the people named in the plan before assigning dates.
- Follow up with: “Convert the work breakdown into a weekly status report template with blockers, decisions needed, evidence collected, and next-week commitments.”
Variations
Security roadmap
Use this for a prioritized multi-quarter security improvement plan.
Create a 12-month defensive cybersecurity roadmap for [ORGANIZATION CONTEXT] based on [RISK AND CONTROL FINDINGS]. Available people and budget are [RESOURCES]. Required frameworks are [REQUIREMENTS]. Group initiatives by risk reduction, dependency, effort, and business disruption. For each quarter, name an accountable owner, measurable control outcome, required decision, and evidence of completion. Do not infer a compliance gap from a framework name alone or invent tool pricing. Keep all recommendations to authorized defensive controls and flag items requiring a formal risk assessment.
Incident tabletop
Use this to prepare an authorized response exercise.
Design an authorized tabletop exercise for [INCIDENT SCENARIO] affecting [SYSTEMS AND DATA]. Participants and their roles are [PARTICIPANTS], and relevant response policies are [POLICIES]. Create a timed facilitator guide with injects, decision points, communications choices, evidence to request, and evaluation criteria. Test coordination, escalation, containment decisions, legal or privacy review, and recovery governance without providing exploit steps. Include an after-action template with owner, corrective action, due date, and validation evidence. Do not invent breach facts or regulatory deadlines.
Vendor assessment
Use this before approving a security-sensitive vendor.
Create a vendor security assessment plan for [VENDOR AND SERVICE] that will handle [DATA AND INTEGRATIONS]. Our risk tolerance and required controls are [REQUIREMENTS], and available vendor evidence is [VENDOR MATERIALS]. Produce a question set covering identity, encryption, logging, incident notification, sub-processors, availability, data retention, and exit. Distinguish claims needing contract review, technical verification, or assurance reports. Output a risk-rating matrix and approval conditions. Do not claim the vendor is compliant or secure without supporting evidence.
Tips
- Start with the risky business scenario, such as privileged-account takeover or exposed customer data, because controls without a threat link are hard to prioritize.
- Assign one accountable owner per task; a team name can be listed as contributors but cannot resolve a missed acceptance criterion.
- A pilot needs a success measure and rollback condition before rollout, especially for identity, endpoint, network, and data-protection changes.
- Collect evidence as the project runs, such as approved configurations, user enrollment records, test results, and exception approvals, rather than reconstructing it during an audit.
FAQ
Can AI create a cybersecurity project plan safely?
Yes, for authorized defensive planning, documentation, and validation. It should not be used to generate instructions for unauthorized access or evading security controls.
What makes a security project complete?
Completion requires more than deploying a tool: the control should be configured, tested in scope, documented, owned operationally, and supported by evidence.
Should every framework control become a project?
No. First determine applicability and risk. A framework can guide assessment, but the project backlog should reflect your systems, data, commitments, and material threats.