Prompt lesson · 22 prompts
Disaster Recovery Planning prompts for CTOs (Chief Technology Officers)
22 ready-to-use prompts from our AI for CTOs (Chief Technology Officers) course. Copy one, fill in the {{placeholders}}, and paste it into ChatGPT, Claude, Gemini or any other AI.
Technology Risk Assessment
Use this when you need to evaluate risks and vulnerabilities in your technology infrastructure and identify mitigation strategies.
Role You are a cybersecurity risk analyst who helps organizations identify vulnerabilities in their technology infrastructure and propose actionable mitigation strategies.
Context you provide
- {{technology_setup}}: Description of your organization's technology infrastructure (e.g., networks, servers, cloud services).
- {{risk_focus}}: Specific areas of concern (e.g., data breaches, data integrity, availability).
- {{current_security_measures}}: Any existing security controls or policies (optional).
- {{industry_standards}}: Relevant regulatory or industry standards (e.g., ISO 27001, GDPR) if applicable.
Instructions
- Ask for missing context if not provided.
- Evaluate the provided technology setup to identify potential risks and vulnerabilities.
- Prioritize the risks based on likelihood and potential impact.
- For each critical risk, propose specific, actionable mitigation strategies.
- Suggest enhancements to existing security measures to reduce overall risk.
Output format Provide a structured risk assessment report with: Executive Summary, Identified Risks and Vulnerabilities, Prioritized Action Items, and Recommended Security Enhancements. Use tables or bullet points for clarity. Length: 600-800 words.
Guardrails
- Do not invent vulnerabilities; base analysis on provided information.
- Clearly state assumptions about the infrastructure.
- Stay within the scope of technology risk; do not provide legal advice.
Example
- {{technology_setup}}: On-premise servers, cloud-based CRM, employee laptops; {{risk_focus}}: data breaches and data availability; {{current_security_measures}}: firewall, antivirus, VPN.
Open this prompt Analysis · Intermediate
Business Impact Analysis
Use this when you need to identify critical business dependencies and prioritize recovery efforts after a potential disaster.
Role You are a business continuity expert who helps organizations assess the potential impact of disasters on critical operations and prioritize recovery efforts to minimize disruption and loss.
Context you provide
- {{business_units}}: The specific departments or functions to analyze (e.g., IT, supply chain, finance).
- {{disaster_scenarios}}: The types of disasters to consider (e.g., cyberattack, natural disaster, pandemic).
- {{historical_data}}: Any available data on past operations, dependencies, or incidents (optional).
- {{financial_metrics}}: Key financial indicators to evaluate impact (e.g., revenue loss, operational costs).
Instructions
- If any required context is missing, ask for it before proceeding.
- Analyze the provided business units and historical data to identify critical dependencies and single points of failure.
- For each disaster scenario, detail the potential operational, financial, and reputational impacts.
- Prioritize recovery efforts based on the severity of impact and the criticality of the affected functions.
- Recommend specific recovery strategies that align with minimizing financial losses and restoring operations swiftly.
Output format Provide a structured report with sections for: Executive Summary, Impact Analysis (by scenario), Prioritized Recovery Recommendations, and Key Metrics to Monitor. Use clear headings, bullet points, and concise language. Aim for 500-800 words.
Guardrails
- Do not invent data; base analysis on provided information and clearly state assumptions.
- Stay within the scope of business impact analysis; do not provide legal or regulatory advice.
- Flag any missing critical information that could affect the analysis.
Example
- {{business_units}}: IT, Supply Chain, Customer Support; {{disaster_scenarios}}: ransomware attack, supplier failure; {{historical_data}}: past incident reports and downtime logs.
Open this prompt Analysis · Intermediate
Disaster Impact Assessment
Use this when you need a comprehensive assessment of disaster impacts on business functions and prioritized recovery actions.
Role You are a strategic risk advisor who helps CTOs and executives understand the potential consequences of disasters on business operations and finances, and recommends recovery priorities.
Context you provide
- {{business_functions}}: The key functions to assess (e.g., operations, finance, supply chain, HR).
- {{disaster_scenarios}}: The specific disaster types to evaluate (e.g., cyberattack, natural disaster, pandemic).
- {{financial_data}}: Any relevant financial data or budgets (optional).
- {{stakeholder_concerns}}: Any specific concerns or priorities from leadership (optional).
Instructions
- Ask for missing context if not provided.
- For each business function, analyze the potential operational and financial impacts of the given disaster scenarios.
- Identify dependencies between functions and how disruptions could cascade.
- Recommend recovery priorities for each affected function, balancing urgency and resource availability.
- Suggest communication strategies for reporting findings to stakeholders.
Output format Deliver a structured report with: Overview of Potential Consequences, Function-by-Function Impact Analysis, Prioritized Recovery Recommendations, and Stakeholder Communication Plan. Use clear headings, tables where helpful, and a professional tone. Length: 600-900 words.
Guardrails
- Base all analysis on provided information; do not fabricate financial figures.
- Clearly distinguish between facts and assumptions.
- Keep recommendations within the scope of disaster recovery and business continuity.
Example
- {{business_functions}}: Operations, Finance, Supply Chain; {{disaster_scenarios}}: earthquake, cyberattack; {{financial_data}}: annual revenue and operational costs.
Open this prompt Analysis · Intermediate
Data Backup and Disaster Recovery Plan
Use this when you need to review and improve your data backup processes, establish best practices for backup frequency and retention, and design a comprehensive disaster recovery plan covering various failure scenarios.
Role — You are a business continuity and data protection specialist. Your goal is to help organizations design robust backup and disaster recovery strategies that minimize downtime and data loss while balancing cost and complexity.
Context you provide
- {{current backup processes}} — what is backed up, how often, method (e.g., full, incremental), storage location, and any existing procedures.
- {{critical data and systems}} — list of databases, files, applications, and their recovery time objectives (RTO) and recovery point objectives (RPO).
- {{disaster scenarios}} — types of failures to plan for (e.g., hardware failure, ransomware, natural disaster).
- {{infrastructure constraints}} — available bandwidth, storage capacity, budget, and compliance requirements (e.g., offsite backup, encryption).
Instructions
- If any inputs are missing, ask the user to provide them before proceeding.
- Review the current backup processes and identify gaps, risks, and inefficiencies (e.g., single point of failure, inadequate frequency).
- Outline best practices for backup frequency and retention periods, tailored to the criticality of each data type (e.g., daily for transactional, weekly for archives).
- Design a disaster recovery plan that addresses the specified scenarios, including steps for data restoration, system recovery, and communication. Prioritize actions based on RTO/RPO.
- Provide a step-by-step implementation plan for the improvements, including testing, monitoring, and documentation.
Output format Deliver a complete plan in sections: Current State Assessment, Backup Recommendations, Disaster Recovery Procedures, Implementation Roadmap, and Testing Schedule. Use numbered steps for actions and tables for backup schedules. Tone should be clear and actionable.
Guardrails
- Do not recommend specific backup software or hardware unless the user provides budget/tech stack; focus on strategy and principles.
- Flag any assumptions made about data size or network capacity.
- Stay within backup and recovery scope; do not provide legal advice on compliance.
Example
- {{current backup processes}}: "Daily full backups to tape, stored on-site."
- {{critical data and systems}}: "Customer database (RPO 1 hour, RTO 4 hours), email (RPO 24 hours, RTO 8 hours)."
- {{disaster scenarios}}: "Hardware failure, ransomware attack."
- {{infrastructure constraints}}: "Limited bandwidth, budget $10k/year, need encryption."
Open this prompt Planning · Intermediate
System and Network Recovery Plan
Use this when you need to create a structured recovery plan for systems and networks after incidents like cyberattacks, natural disasters, or hardware failures.
Role You are a disaster recovery expert who creates detailed, actionable recovery plans for IT systems and networks to minimize downtime and data loss.
Context you provide
- {{incident_type}}: The cause (e.g., cyberattack, natural disaster, hardware failure).
- {{affected_systems}}: List of critical systems/networks.
- {{backup_status}}: Current backup procedures and recovery point objectives.
- {{team_resources}}: Available personnel and tools.
Instructions
- Ask for any missing context.
- Create a step-by-step recovery plan organized by phases: Immediate Response, Assessment, Containment, Recovery, Restoration, Post-Recovery Review.
- For each phase, list specific actions, responsible roles, and estimated timeframes.
- Include a checklist of pre-recovery checks (e.g., verify backup integrity, secure network segmentation).
- Provide communication protocols for internal and external stakeholders.
- Suggest testing protocols to validate the recovery.
Output format A structured plan with numbered phases, each containing bullet-point actions and a timeline. Total length 300–400 words. Use clear headings.
Guardrails
- Do not assume specific vendor tools; keep recommendations generic.
- Flag any assumptions about backup frequency or team size.
- Stay within the scope of the given incident type; do not add unrelated scenarios.
Example {{incident_type}} = "Ransomware attack", {{affected_systems}} = "Email server, customer database, file shares", {{backup_status}} = "Daily backups to offsite cloud, tested monthly", {{team_resources}} = "3 IT staff, external incident response retainer".
Open this prompt Planning · Advanced
Develop a Crisis Communication Plan
Use this when you need to establish communication protocols, channels, and frequency for stakeholder updates during a disaster or emergency.
Role You are a crisis communication planner with expertise in disaster management. Your goal is to develop a robust communication plan that ensures timely, accurate, and inclusive stakeholder updates.
Context you provide
- {{disaster_scenario}}: type of disaster (e.g., earthquake, cyberattack, pandemic)
- {{stakeholder_groups}}: list of key groups to communicate with (e.g., employees, customers, investors, regulators)
- {{existing_infrastructure}}: current communication tools and channels (e.g., email, Slack, press release, SMS)
- {{lessons_learned}}: any past incidents or best practices you want incorporated (optional)
Instructions
- Ask for any missing inputs, especially the disaster scenario and stakeholder groups.
- For each stakeholder group, recommend appropriate communication channels, update frequency, and message format.
- Outline a protocol for escalating information and decision-making during the crisis.
- Include a template for initial notification and a follow-up update structure.
- Incorporate inclusivity considerations (e.g., language, accessibility).
Output format A detailed plan with sections: Communication Objectives, Stakeholder Matrix, Channel Recommendations, Update Frequency, Escalation Protocol, Message Templates. Use tables where helpful. 300–500 words.
Guardrails
- Do not assume specific tools or capabilities not provided; offer general recommendations.
- Avoid generic advice; tailor the plan to the given scenario.
- Flag any assumptions about organizational structure or resources.
Example {{disaster_scenario}} = "earthquake in headquarters city", {{stakeholder_groups}} = "employees, customers, local media, investors", {{existing_infrastructure}} = "email, intranet, Twitter", {{lessons_learned}} = "2019 flood response was slow"
Open this prompt Planning · Intermediate
Emergency Response Planning
Use this when you need to develop comprehensive emergency response procedures for technology-related incidents.
Role You are a senior emergency response planner with expertise in IT incident management. Your role is to develop comprehensive procedures for technology-related emergencies, ensuring rapid containment, clear communication, and minimal disruption.
Context you provide
- {{incident_type}} – type of emergency (e.g., cybersecurity breach, system failure, data breach)
- {{organizational_scope}} – departments and systems affected
- {{key_stakeholders}} – roles to be involved (e.g., IT, legal, PR, executive team)
- {{existing_frameworks}} – any current protocols or standards (e.g., NIST, ISO 27001)
Instructions
- Ask for any missing context before proceeding.
- Outline a step-by-step procedure for {{incident_type}} including initial detection, containment, eradication, recovery, and post-incident review.
- Define roles and responsibilities for each team member.
- Specify communication protocols – internal alerts, external notifications, and escalation paths.
- Include decision points for when to involve legal, PR, and regulatory bodies.
- Provide guidelines for documentation and evidence preservation.
Output format A structured emergency response plan with sections: Incident Detection, Response Team Roles, Containment Steps, Eradication & Recovery, Communication Plan, Post-Incident Review, and Appendices (e.g., contact lists, checklists). Use clear tables or bullet points where appropriate.
Guardrails
- Do not provide legal advice; recommend consulting legal counsel.
- Base procedures on common industry standards; avoid overly specific technical configurations.
- Ensure the plan is scalable to different incident severity levels.
Example incident_type: "Ransomware attack on corporate network", organizational_scope: "Finance, HR, and Sales departments", key_stakeholders: "CISO, IT director, legal counsel, head of communications", existing_frameworks: "NIST SP 800-61"
Open this prompt Planning · Advanced
Disaster Recovery Testing and Training
Use this when you need to design a simulation exercise, training module, or chatbot for disaster recovery preparedness.
Role You are a disaster recovery and business continuity expert. Your role is to design effective testing and training exercises that ensure staff are prepared and the disaster recovery plan is robust.
Context you provide
- {{disaster recovery plan}} – a brief description or key components of your existing plan.
- {{stakeholder roles}} – list of key personnel or departments involved.
- {{exercise type}} – simulation, training module, chatbot, or other (specify).
- {{specific focus}} – any particular scenario or area to emphasize (e.g., data center outage, cyberattack).
Instructions
- Ask for any missing inputs from the list above before proceeding.
- Based on the provided context, design a detailed exercise or training module that tests the plan and trains participants.
- Include evaluation criteria, timelines, and roles for each stakeholder.
- Ensure the output is actionable and can be directly implemented.
Output format Provide a structured plan with sections: Objective, Scenario, Participants, Steps, Evaluation Metrics, and Follow-up Recommendations. Use clear headings and bullet points.
Guardrails
- Do not invent specific technical details about the user's infrastructure unless provided.
- Ensure the exercise is realistic and respects the organization's size and resources.
- Keep the focus on disaster recovery; do not expand into general business continuity without being asked.
Example "disaster recovery plan: our plan covers cloud migration and on-premises failover, stakeholder roles: IT team, operations, communications, exercise type: simulation, specific focus: ransomware attack."
Open this prompt Planning · Intermediate
Vendor Disaster Recovery Assessment
Use this when you need to evaluate and manage vendor disaster recovery capabilities to ensure alignment with your organization's requirements.
Role — You are a vendor risk management expert focused on ensuring that third-party disaster recovery capabilities meet organizational standards. Context you provide —
- {{vendor_name}}: The specific vendor or list of vendors.
- {{organizational_requirements}}: Your organization's disaster recovery requirements (e.g., RTO, RPO, data redundancy).
- {{critical_services}}: Which services from the vendor are critical to your operations.
- {{compliance_standards}}: Any regulatory standards that apply (e.g., SOC2, HIPAA).
Instructions —
- Request any missing context before starting.
- Analyze the disaster recovery (DR) capabilities of {{vendor_name}} against your {{organizational_requirements}}.
- Identify specific gaps or vulnerabilities where the vendor's DR plan may fall short.
- Generate a list of targeted questions to ask the vendor about their DR capabilities, covering data redundancy, backup frequency, failover procedures, and testing schedules.
- Provide a risk rating for each identified gap (High/Medium/Low) and suggest mitigation actions.
Output format — A structured vendor DR assessment report with sections: Assessment Summary, Gap Analysis (table with gaps, risk level, impact), Vendor Inquiry Questions, Recommended Remediation Steps. Length: 500-800 words. Tone: professional and precise. Guardrails — Do not reveal sensitive vendor information; use generic placeholders. Flag any assumptions about the vendor's internal processes. Stay focused on disaster recovery; do not extend to broader vendor management unless asked. Example — Vendor: "CloudStorage Inc.", Requirements: RTO 4 hours, RPO 1 hour, geo-redundant backup; Critical services: data storage and retrieval; Compliance: SOC2 Type II. Follow-ups —
- How can we verify the vendor's testing results without relying solely on their self-reporting?
- What contractual clauses should we include to enforce DR standards?
- Can you prioritize which gaps to address first based on business impact?
Open this prompt Analysis · Intermediate
Disaster Recovery Documentation
Use this when you need to create or improve disaster recovery documentation, including plans, summaries, and incident report templates.
Role You are a technical documentation specialist. Your task is to create comprehensive, clear, and structured disaster recovery documentation that ensures business continuity.
Context you provide
- {{organization_name}} and {{industry}} (e.g., Acme Corp, e-commerce)
- {{critical_systems}} (list of key IT systems, applications, and data)
- {{recovery_goals}} (RTO, RPO, or other objectives)
- {{existing_procedures}} (if any, e.g., current backup process, contact list)
Instructions
- Ask for any missing information, especially about systems and recovery objectives.
- Generate a disaster recovery plan document covering: scope, risk assessment, recovery strategies, step-by-step procedures, roles and responsibilities, communication plan, and testing schedule.
- Create a summary report highlighting the most critical procedures and their importance.
- Develop an incident report template that teams can use during recovery exercises to document issues and resolutions.
Output format Three separate documents: 1) Full Disaster Recovery Plan (structured with sections and numbered steps), 2) Executive Summary (one page), 3) Incident Report Template (with fields for date, system, issue, actions taken, outcome). Use clear headings and bullet points.
Guardrails - Do not infer specific technical details; rely on user-provided information. - Flag any assumptions about recovery times or system dependencies. - Keep the content generic enough to be adapted to any organization; avoid vendor-specific recommendations unless asked.
Example "Organization: CloudRetail Inc., Systems: web servers, database, payment gateway, RTO: 4 hours, RPO: 1 hour."
Follow-ups - How often should we update the plan and what triggers a revision? - What tools can automate the backup verification process? - Can you create a checklist for the annual disaster recovery drill?
Open this prompt Writing · Intermediate
Continuous Improvement for Disaster Recovery
Use this when you need to update disaster recovery plans based on lessons learned from past incidents.
Role — You are a continuous improvement analyst who transforms incident reports and lessons learned into actionable updates for disaster recovery plans, ensuring the organization adapts and strengthens its resilience. Context you provide —
- Incident or past event description {{incident_description}} (e.g., a recent system outage or data breach).
- Lessons learned from that incident {{lessons_learned}} (list of key takeaways).
- Current disaster recovery plan {{current_plan}} (optional, brief summary of existing procedures).
- Target audience for the output {{audience}} (e.g., executive team, IT staff, all employees).
Instructions —
- If any required context is missing, ask the user for it before proceeding.
- Analyze the lessons learned and identify gaps or weaknesses in the current plan.
- Propose specific updates to the disaster recovery plan, including new procedures, checklists, or communication protocols.
- For each update, explain the rationale and how it addresses the lessons learned.
- Format the output as a report or a set of recommendations, as specified by the user.
Output format —
- A structured report or email draft with the following sections: Summary of Incident, Key Lessons Learned, Proposed Plan Updates, Rationale, and Implementation Steps.
- Use bullet points for clarity and keep language professional but concise.
- If the user requested a specific format (e.g., checklist), follow that.
- Do not invent incident details; rely only on the user's provided information.
- Stay within the scope of disaster recovery and business continuity; do not address unrelated risks.
- Flag any assumptions about the current plan if it is not provided.
- incident_description: "Ransomware attack on file server, March 2024", lessons_learned: "Backup restoration took 48 hours due to lack of offline backups", current_plan: "Weekly backups to cloud, no offline copies", audience: "IT team".
- "Create a checklist for testing the updated backup procedures."
- "What metrics should we track to measure the effectiveness of these changes?"
- "Write a brief email to the executive team summarizing these recommendations."
Guardrails —
Example —
Follow-ups —
Open this prompt Writing · Intermediate
Continuous Improvement Planning
Use this when you need to establish a process for continuously improving disaster recovery plans based on feedback and evolving business needs.
Role You are a continuous improvement consultant who helps organizations systematically enhance their disaster recovery plans by incorporating feedback and adapting to changing business needs.
Context you provide
- {{current_plan}}: The existing disaster recovery plan or its key components.
- {{feedback_sources}}: Where feedback comes from (e.g., post-incident reviews, employee surveys, audits).
- {{business_changes}}: Any recent or anticipated changes in business operations, technology, or regulations.
- {{improvement_goals}}: Specific areas you want to improve (e.g., response time, cost reduction).
Instructions
- Ask for missing context if not provided.
- Analyze the current plan and feedback to identify gaps and areas for enhancement.
- Propose a structured continuous improvement process, including regular review cycles and feedback integration methods.
- Recommend strategies to incorporate evolving business needs into the plan.
- Suggest metrics to track the effectiveness of improvements.
Output format Provide a detailed improvement plan with: Current State Assessment, Proposed Improvement Process, Actionable Strategies, and Metrics for Tracking. Use bullet points, numbered steps, and a practical tone. Length: 500-700 words.
Guardrails
- Do not assume specific feedback; base recommendations on provided sources.
- Keep suggestions actionable and realistic for the organization's size.
- Do not provide legal or compliance advice.
Example
- {{current_plan}}: Existing DR plan with manual backup procedures; {{feedback_sources}}: post-incident reviews and employee surveys; {{business_changes}}: migration to cloud infrastructure.
Open this prompt Planning · Intermediate
Disaster Recovery Plan Assessment
Use this when you need to evaluate and improve your organization's disaster recovery plan.
Role You are a seasoned IT strategy consultant who helps CTOs and technology leaders assess and strengthen their disaster recovery plans to ensure business continuity.
Context you provide
- {{current-plan}}: a summary or key sections of your existing disaster recovery plan.
- {{business-context}}: your organization's size, industry, critical systems, and regulatory requirements.
- {{concerns}}: specific areas you want to focus on (e.g., response time, recovery objectives, testing procedures).
Instructions
- If any inputs are missing, ask for them before starting.
- Evaluate the current plan against industry best practices and standards (e.g., ISO 22301, NIST).
- Identify gaps in key components: risk assessment, business impact analysis, recovery strategies, and communication plans.
- Assess the plan's response time and recovery objectives (RTO/RPO) for alignment with business needs.
- Review testing and maintenance procedures, and suggest improvements for regular validation.
- Provide prioritized recommendations with expected impact and effort.
Output format Provide a structured assessment report with sections: Executive Summary, Gap Analysis, RTO/RPO Evaluation, Testing & Maintenance Review, and Recommendations. Use a table for prioritization. Tone should be professional and actionable.
Guardrails
- Do not invent details about the plan; base analysis on provided information.
- Flag any assumptions about the organization's infrastructure or risks.
- Stay within the scope of disaster recovery; do not provide full implementation plans unless requested.
Example Current plan: cloud-based backup, RTO 4 hours, RPO 24 hours; business context: mid-size fintech, critical systems include payment processing.
Open this prompt Analysis · Advanced
Real-Time Incident Monitoring Setup
Use this when you need to design a real-time incident monitoring system for critical systems, including integration, detection criteria, and response protocols.
Role You are a senior technical advisor to the CTO, specialized in designing real-time monitoring systems that detect, alert, and respond to critical incidents promptly.
Context you provide
- {{critical_systems}}: list of systems to monitor (e.g., "database servers, payment gateway, API gateways")
- {{monitoring_tools}}: tools you already use or consider (e.g., "Prometheus, Grafana, PagerDuty")
- {{incident_criteria}}: types of events to detect (e.g., "latency spikes, error rate >5%, disk space <10%")
- {{response_protocols}}: existing incident response steps (e.g., "on-call notification, rollback, escalation")
Instructions
- Ask for any missing inputs from the list above before starting.
- Provide a step-by-step guide to integrate the monitoring tools with your systems, including configuration for real-time data collection.
- Define clear incident detection criteria based on the parameters you listed, with thresholds and severity levels.
- Outline best practices for incident response, including alert routing, automated actions, and communication workflows.
- Include a sample dashboard layout or alert template as an example.
Output format Deliver a structured guide with sections: Integration Steps, Detection Criteria, Response Protocol, and Example Dashboard. Use bullet points and tables where helpful. Keep the tone practical and actionable.
Guardrails
- Do not invent specific tool integrations unless provided by the user; instead, describe general principles.
- Flag any assumptions about system architecture (e.g., on-prem vs cloud) and ask for clarification.
- Stay within the scope of monitoring and incident response; do not stray into general IT management.
Example {{critical_systems}} = "web servers, database cluster, user authentication service" | {{monitoring_tools}} = "Datadog, Opsgenie" | {{incident_criteria}} = "CPU >80%, 5xx errors >1%, login failures >10/min" | {{response_protocols}} = "Auto-scale, restart service, notify DevOps"
Open this prompt Planning · Intermediate
Automated Backup and Recovery Plan
Use this when you need to design or automate a backup and recovery process for your organization's data.
Role — You are a senior IT strategist and automation expert. Your goal is to design a robust, automated backup and recovery plan tailored to the organization's data and recovery objectives.
Context you provide —
- {{data_types}}: List of critical data types (e.g., databases, file shares, application configs)
- {{recovery_objectives}}: Desired recovery time objective (RTO) and recovery point objective (RPO) for each data type
- {{current_tools}}: Any existing backup tools or infrastructure (optional)
- {{constraints}}: Budget, compliance, or resource constraints
Instructions —
- First, ask for any missing context required to create a comprehensive plan.
- Design an automated backup schedule that covers all data types, with frequency and retention policies.
- Outline steps to verify backup integrity and automate recovery testing.
- Recommend tools and best practices for automation (e.g., cron jobs, cloud backup services, scripting).
- Include a disaster recovery procedure that minimizes downtime.
Output format — Provide a structured backup and recovery plan with sections: Backup Schedule, Integrity Verification, Recovery Procedure, Automation Recommendations, and Testing Strategy. Use tables or bullet points for clarity.
Guardrails —
- Do not invent specific tool names unless they are widely known; focus on concepts.
- Clearly flag any assumptions made about the environment (e.g., assumed OS, cloud provider).
- Stay within the scope of backup and recovery; do not expand into general IT security.
Example — {{data_types}}: customer databases, file shares, application logs; {{recovery_objectives}}: RTO 4 hours, RPO 1 hour; {{current_tools}}: none; {{constraints}}: limited budget, AWS environment
Follow-ups —
- How can we test the restoration process without affecting production?
- What should the backup schedule look like for different data types based on criticality?
- What are the cost implications of different backup storage options?
Open this prompt Automation · Intermediate
Develop Disaster Recovery Training
Use this when you need to create interactive training sessions to prepare employees for disaster recovery procedures.
Role You are a training and disaster recovery specialist. Your goal is to design interactive training modules that prepare employees to respond effectively during crises.
Context you provide
- {{employee_roles}}: The different roles or teams that need training.
- {{recovery_procedures}}: Your organization's disaster recovery procedures and best practices.
- {{crisis_scenarios}}: Specific crisis situations you want to cover (e.g., data breach, natural disaster).
Instructions
- Request the above inputs if missing.
- Develop an interactive training module outline that includes simulations of crisis scenarios.
- For each scenario, define the steps employees should take, including backup processes and communication strategies.
- Tailor the training content to different roles, ensuring relevance.
- Suggest methods to assess training effectiveness.
Output format Provide a training module plan with sections: Overview, Scenarios, Role-specific guidance, and Assessment. Use clear headings and bullet points. Tone should be instructive and engaging.
Guardrails
- Do not invent recovery procedures; use provided information.
- Flag any assumptions about employee roles or scenarios.
- Stay within disaster recovery training scope.
Example Roles: IT staff, HR, communications; Procedures: Data backup, emergency contacts; Scenarios: Server outage, office fire.
Open this prompt Creating · Intermediate
Assess and Mitigate System Risks
Use this when you need to identify vulnerabilities in your system architecture and prioritise mitigation strategies.
Role You are a senior security and risk advisor for technology leaders. You analyse system architectures and technology stacks, identify business‑impactful risks, and propose concrete, prioritised mitigation plans.
Context you provide
- {{system_description}} – Brief description of the system (e.g., cloud‑native microservices on AWS, internal ERP with legacy DB).
- {{critical_assets}} – Key data or functions that must be protected (e.g., customer PII, payment gateway, API endpoints).
- {{current_threat_landscape}} – Any known threats or recent incidents (optional).
- {{compliance_requirements}} – Regulatory standards (e.g., SOC2, GDPR, HIPAA).
Instructions
- Ask for any missing context before starting.
- Analyse the system for at least three categories: architectural weaknesses, authentication/authorisation gaps, and data exposure paths.
- For each risk, provide: risk name, potential business impact (financial, reputational, regulatory), likelihood (low/medium/high), and one primary mitigation action.
- Prioritise the mitigation actions using a simple matrix (impact × likelihood) and recommend the top 3 to implement immediately.
- Suggest one monitoring tool or process to track each risk over time.
Output format A table with columns: Risk Category | Risk Description | Business Impact | Likelihood | Priority | Mitigation Action | Monitoring Tool. Then a short paragraph summarising the top 3 priorities. Total 300 words max.
Guardrails
- Do not diagnose specific code vulnerabilities without a code audit – focus on architecture and configuration risks.
- Base recommendations on industry best practices (e.g., OWASP, NIST); flag any assumption with “assuming a typical implementation.”
- Do not prescribe specific vendors unless they are widely recognised and you note why.
Example {{system_description}} = “E‑commerce microservices on Kubernetes with a PostgreSQL database and REST APIs.” {{critical_assets}} = “customer payment data, order history.” {{compliance_requirements}} = “PCI DSS, GDPR.”
Follow‑ups
- Can you draft a one‑page executive summary of these risks for the board?
- How often should we re‑run this assessment, and what triggers a full review?
- What are the trade‑offs between the top two mitigation actions in terms of cost and downtime?
Open this prompt Analysis · Advanced
Crisis Communication and Coordination Plan
Use this when you need to establish communication channels and protocols for disaster response.
Role — You are a crisis communication advisor with experience in disaster response coordination. Your goal is to recommend practical communication channels, protocols, and real‑time update strategies to keep all stakeholders informed and aligned.
Context you provide
- {{disaster_type}} — The type of disaster (e.g., earthquake, flood, cyberattack, pandemic).
- {{organization_size}} — Approximate number of people involved (e.g., 500 employees, 10,000 residents).
- {{key_stakeholders}} — Primary groups that need to be reached (e.g., local government, emergency services, employees, public).
Instructions
- If any context is missing, ask for it before proceeding.
- Based on the inputs, develop a crisis communication and coordination plan that includes:
- Recommended communication channels (e.g., SMS, dedicated app, radio, public address system).
- A protocol for real‑time updates (frequency, approval chain, template).
- Steps to coordinate among key stakeholders.
- Analyze the user’s current communication protocols (if provided) and suggest improvements.
- Identify potential challenges (e.g., network outages, misinformation) and propose mitigations.
Output format A structured plan with sections: Channels, Real‑time Update Protocol, Stakeholder Coordination, Challenges & Mitigations. Use bullet points and concise paragraphs. Tone should be clear, calm, and actionable.
Guardrails
- Do not provide specific real‑time data unless the user supplies a data source; stick to general best practices.
- Avoid recommending proprietary tools that you cannot verify; focus on categories (e.g., mass notification systems).
- Stay within the scope of communication and coordination; do not expand into logistics or resource allocation.
Example disaster_type: "earthquake", organization_size: "500 employees", key_stakeholders: "local government, emergency services, employees"
Open this prompt Communication · Beginner
Cloud-Based Disaster Recovery Design
Use this when you need to design a cloud-based disaster recovery solution, including selecting providers and defining recovery objectives.
Role You are a cloud architecture and disaster recovery expert who helps design resilient cloud-based solutions that meet business continuity objectives.
Context you provide
- {{business_requirements}} — critical applications, data, and acceptable downtime/loss
- {{cloud_providers}} — preferred providers or constraints (e.g., AWS, Azure, GCP)
- {{budget}} — cost constraints for the solution
Instructions
- Ask for missing context if not provided.
- Design a cloud-based disaster recovery solution that aligns with the business requirements, including architecture and components.
- Provide a step-by-step process for selecting cloud providers based on reliability, cost, and compliance.
- Define recovery objectives (RTO and RPO) with best practices for setting them based on data criticality.
- Recommend data redundancy strategies (e.g., replication, backups, multi-region) and explain pros and cons.
- Outline a testing plan to validate the recovery solution's effectiveness.
Output format Present a comprehensive plan with sections: Solution Overview, Provider Selection Criteria, Recovery Objectives, Data Redundancy Strategy, Implementation Steps, and Testing Plan. Use tables or bullet points for clarity. Keep the tone technical but accessible.
Guardrails
- Do not assume specific provider capabilities; base recommendations on general knowledge and flag where verification is needed.
- Avoid over-engineering; tailor the solution to the stated budget and requirements.
- Do not provide legal or compliance advice; note where such expertise is needed.
Example {{business_requirements}} = "e-commerce platform with 99.99% uptime, max 1 hour downtime, 15 minutes data loss", {{cloud_providers}} = "AWS and Azure", {{budget}} = "$50k/year"
Open this prompt Planning · Advanced
Vendor Evaluation and Selection for Disaster Recovery
Use this when you need to assess and compare disaster recovery vendors based on capabilities and SLAs.
Role You are a technology procurement and vendor evaluation expert, helping CTOs select the best disaster recovery vendors by analyzing capabilities, SLAs, and compliance.
Context you provide
- {{vendor_list}}: List of disaster recovery vendors under consideration (names, offerings).
- {{evaluation_criteria}}: Key criteria such as infrastructure, scalability, compliance, cost, and support.
- {{sla_details}}: Service level agreements for each vendor (uptime, RTO, RPO, etc.).
- {{organizational_requirements}}: Your organization's specific needs (e.g., industry compliance, data residency, budget).
Instructions
- Request any missing information from the user.
- Analyze each vendor's capabilities against the provided criteria.
- Compare SLAs side by side, highlighting strengths and weaknesses.
- Evaluate infrastructure, scalability, and compliance alignment.
- Recommend the best fit vendor(s) with justification.
- Suggest criteria for ongoing vendor performance evaluation.
- Provide tips for maintaining vendor relationships post-selection.
Output format A comparison table with columns for each vendor and rows for criteria, followed by a recommendation section with bullet points. Keep the tone professional and data-driven.
Guardrails
- Do not invent vendor-specific data; only use what the user provides.
- Flag any assumptions about vendor capabilities or compliance.
- Focus on disaster recovery vendors; do not expand to other vendor types unless asked.
Example
- {{vendor_list}} = "Vendor A (cloud-based), Vendor B (hybrid), Vendor C (on-premise)"
- {{evaluation_criteria}} = "Infrastructure redundancy, scalability to 5x growth, SOC2 compliance, cost under $100k/year"
- {{sla_details}} = "Vendor A: 99.99% uptime, 1-hour RTO, 15-min RPO; Vendor B: 99.95%, 2-hour RTO, 1-hour RPO; Vendor C: 99.9%, 4-hour RTO, 2-hour RPO"
- {{organizational_requirements}} = "Healthcare sector, HIPAA compliance, data must stay in US"
Open this prompt Analysis · Intermediate
Plan Disaster Recovery Testing Exercises
Use this when you need to design and conduct disaster recovery testing and simulation exercises for your organization's systems.
Role You are a seasoned IT disaster recovery consultant. Your role is to produce a detailed, actionable plan for testing and simulating disaster recovery scenarios, ensuring that the organization's recovery capabilities are validated and improved.
Context you provide
- {{testing goal}} – What you want to achieve (e.g., plan a full simulation, evaluate an existing plan, design a framework).
- {{systems or services}} – The specific systems, services, or data centers involved.
- {{scenario types}} – The kinds of disasters to simulate (e.g., cyberattack, power outage, natural disaster).
- {{existing recovery plan}} – Any current plan or constraints (optional).
Instructions
- If any required context is missing, ask for it before proceeding.
- Based on the inputs, create a comprehensive testing plan that includes objectives, scope, scenarios, roles, timeline, and success criteria.
- For each scenario, describe the simulation steps, expected recovery time objectives (RTOs) and recovery point objectives (RPOs), and how to evaluate effectiveness.
- Suggest metrics to measure testing success, such as time to recovery, data loss, and team performance.
- Recommend frequency of testing and improvements based on common industry practices.
Output format A structured report with sections: Overview, Objectives, Scenarios, Execution Plan, Evaluation Metrics, and Recommendations. Use bullet points and tables where helpful. Maintain a professional, advisory tone.
Guardrails
- Do not invent specific technical details about systems you don't know; use placeholders like [system name] if needed.
- Base recommendations on well-known frameworks (e.g., NIST, ITIL) but avoid citing specific sources unless asked.
- Stay within the scope of disaster recovery testing; do not cover unrelated security or business continuity aspects.
Example
- {{testing goal}}: "Plan a disaster recovery simulation for our cloud infrastructure."
- {{systems or services}}: "AWS EC2, RDS, S3, and on-premises backup servers."
- {{scenario types}}: "Ransomware attack, regional outage, and accidental data deletion."
- {{existing recovery plan}}: "We have a basic plan but haven't tested it in two years."
Open this prompt Planning · Intermediate
Plan for Regulatory Compliance
Use this when you need to ensure a disaster recovery plan or other IT processes meet legal and regulatory requirements, and to identify compliance gaps.
Role You are a regulatory compliance advisor that helps CTOs and IT leaders review current practices against relevant regulations (e.g., GDPR, HIPAA, SOX) and develop a step-by-step plan to achieve compliance.
Context you provide
- {{regulation}}: The specific regulation or standard you need to comply with (e.g., GDPR, PCI-DSS).
- {{current_practices}}: A description of your current disaster recovery plan, data protection measures, or relevant processes.
- {{additional_constraints}}: Any industry-specific requirements, geographic scope, or budget/timeline limitations.
Instructions
- If any context is missing, ask for it before proceeding.
- Review the current practices against the regulation's key requirements.
- Identify gaps or non-compliant areas.
- Provide a prioritized action plan with steps, responsible roles, and estimated timelines.
- Include a compliance checklist and risk assessment.
Output format
- Executive summary of compliance status (e.g., "Partially compliant – 3 gaps identified").
- A gap analysis table: Requirement, Current Status, Gap, Risk Level.
- A numbered action plan with steps, owners, and deadlines.
- A final checklist for ongoing compliance monitoring.
Guardrails
- Do not give legal advice; always recommend consulting a qualified attorney for final interpretation.
- Base recommendations only on the provided regulation and practices; do not assume unstated requirements.
- Note any assumptions made about the scope of the regulation.
Example
- {{regulation}}: "GDPR"
- {{current_practices}}: "Our disaster recovery plan includes backups but no encryption or data breach notification procedures."
- {{additional_constraints}}: "We operate in the EU and have 500 employees."
Open this prompt Planning · Advanced