Cyber Incident Response Strategy Guide for CISOs

1. Establishing the Foundation: CIR Governance

A strong governance foundation ensures that cyber incident response (CIR) is organized, accountable, and business-aligned. The CISO should formalize how incidents are handled by defining an Incident Response Team (IRT) structure with cross-functional participation. This includes appointing representatives from security/IT, legal/compliance, HR, public relations, and executive leadership, so that both technical and business perspectives are covered during a crisis. Clear roles and responsibilities must be documented for each stakeholder, with management support (through policies and charters) to empower decision-making authority when high-impact actions (like shutting down systems) are needed. Establishing formal governance (e.g. an IRT charter and escalation procedures) ensures incidents are handled consistently and in line with organizational risk tolerance.

Key Actions:

Define and document incident response roles/responsibilities: Outline who in the organization (IT, security, legal, HR, PR, etc.) will handle various incident tasks and decision points.
Form an Incident Response Team (IRT): Assemble a core team and extended team contacts across departments and senior management. Include alternates or external partners (MSSP, law enforcement contacts) as needed for support.
Establish governance processes: Create an IRT charter, approval workflows, and defined escalation paths so everyone knows how to activate the IR team and escalate incidents based on severity. Ensure leadership endorsement of the IR policy.
Integrate with business operations: Set up communication protocols linking technical responders with business leaders (for downtime decisions, public communications, etc.), so that business impacts are assessed alongside technical containment.

Deliverables:

Incident Response Policy and Plan: A formal document approved by leadership, detailing the incident handling process, authority, and scope.
IRT Charter and Org Chart: Defines the team’s mandate and lists team members (by name/role), including executive sponsors and alternates.
Communications Matrix: Contact lists and escalation tree for internal team, executives, legal counsel, PR, external breach coach/forensics, law enforcement, etc., with after-hours contacts. Also define how and when to communicate with customers, regulators, and employees during an incident.

2. Incident Lifecycle Process

CISOs should implement and operationalize a standard incident response lifecycle to handle incidents from start to finish in a consistent manner. A well-known model (adapted from NIST and SANS guidelines) includes six phases: Preparation; Detection and Analysis; Containment; Eradication; Recovery; and Lessons Learned. Each phase has distinct objectives and processes, and together they create a continuous improvement loop so the organization learns from each incident.

Incident Response Lifecycle Phases:

Preparation: Establish the tools, resources, and policies needed before incidents occur. This includes maintaining up-to-date asset inventories, implementing logging and monitoring standards, setting incident severity definitions, and conducting training (e.g. incident drills and tabletop exercises). In this phase, the CISO ensures that preventive controls are in place and that the team is ready to respond (e.g. an updated IR plan, access to forensic tools, and practiced procedures).
Detection & Analysis: Continuously monitor systems to detect anomalies or signs of a potential incident. Use security analytics like SIEM alerts, IDS/IPS, EDR endpoint alerts, network logs, etc., to identify indicators of compromise. When an alert triggers, the IRT analyzes it to determine if an incident has occurred, its nature and scope, and categorizes its severity. This often involves correlating data from multiple sources and evaluating if thresholds for an incident are met (e.g. distinguishing a minor malware infection from a major breach). Clear criteria for incident classification should be defined here.
Containment: Once an incident is confirmed, responders focus on containing the threat to limit damage. Short-term containment might involve isolating affected hosts or network segments, disabling compromised accounts, or blocking malicious IPs. The CISO should guide decisions on whether to shut down systems, depending on business impact. Containment strategies balance stopping the attacker’s progress with preserving evidence. Plans should outline different containment tactics (e.g. pulling a server offline vs. applying temporary firewall rules) for various incident types.
Eradication: After immediate containment, find and eliminate the root cause of the incident. This can include removing malware from all affected systems, patching vulnerabilities that were exploited, and deleting or disabling malicious artifacts or backdoors. It may also involve conducting forensic analysis to be confident that the threat is eradicated (e.g. scanning for malware on other systems). The CISO ensures the organization has the capability to thoroughly cleanse systems – sometimes bringing in specialized malware removal or cyber forensics experts for complex incidents.
Recovery: Restore and resume normal operations in a controlled manner. This phase includes restoring data from backups (if needed), rebuilding or imaging clean systems, and bringing systems back online carefully to avoid re-introduction of the threat. Testing of systems is done to verify they are secure and functional. The IRT monitors the environment closely during recovery to ensure the incident has truly been resolved and no residual attacker presence remains. For example, if Active Directory was compromised, recovery might involve a global password reset or rebuilding directory services, with extensive validation before declaring success.
Lessons Learned: Conduct a post-incident review after recovery to capture lessons and improve. The team should document a detailed incident report: what happened, how it was handled, what went well or poorly, and specific recommendations for future improvements. This could include updates to response plans, new preventive measures, or additional training for staff. The CISO should ensure a formal post-incident review (PIR) meeting is held for major incidents within a couple weeks of resolution, resulting in an actionable list of improvements. Lessons learned are fed back into the preparation phase – updating playbooks, policies, and security controls – thus completing the cycle of continuous improvement.

Key Tools & Technologies:
A mature incident response program leverages an array of security tools to aid in detection, analysis, and response:

Security Information and Event Management (SIEM): Aggregates and correlates logs from many sources (firewalls, servers, applications) to detect suspicious patterns in real time (e.g. Splunk, Microsoft Sentinel). A SIEM provides a central alerting console and can highlight anomalies across the enterprise.
Endpoint Detection & Response (EDR): Agent-based tools on endpoints that detect malicious behavior (process injection, ransomware file activity, etc.) and can facilitate remote investigation or containment on workstations and servers. EDR solutions (e.g. CrowdStrike, Carbon Black) allow security teams to quickly analyze and quarantine infected hosts.
Security Orchestration, Automation and Response (SOAR): Platforms that automate incident response workflows and orchestrate across tools. For example, a SOAR playbook might automatically create a ticket, isolate a machine, and enrich an alert with threat intelligence data when certain triggers are met. SOAR (e.g. Palo Alto Cortex XSOAR, IBM Resilient) helps to speed up response and handle routine incidents at scale via automation.
Forensic and Analysis Tools: In an incident investigation, specialized tools are used to collect and analyze evidence. Memory forensics tools (e.g. Volatility), disk imaging and analysis software (FTK, EnCase), network packet analyzers, and threat hunting tools like Velociraptor can be employed to deeply investigate incidents. These help identify the scope of compromise and root cause.
Incident Management/Ticketing System: Integrating IR with ticketing ensures that incidents are properly tracked and documented. Many organizations integrate their IR process with IT service management (ITSM) platforms or dedicated incident tracking systems. This provides an audit trail and ensures accountability for each stage of the response.

3. Building Organizational Readiness

A mature CIR program isn’t solely about tools or procedures – it’s about ensuring the people and wider organization are ready to respond. The CISO must cultivate a state of readiness through regular practice, training, and inclusion of all relevant business units. Incident response readiness should be built like a muscle that is exercised frequently to improve reflexes and coordination. This includes testing the incident response plan with simulations, educating staff at all levels on their role in a cyber crisis, and extending response plans to vendors and partners.

Key Readiness Activities:

Regular Exercises: Conduct routine drills to test the incident response plan. At minimum, run quarterly tabletop exercises (facilitated discussion-based simulations of attack scenarios) and periodic live tests. Industry experts recommend tabletop exercises as often as four times per year to keep response plans and team instincts fresh. Additionally, perform an annual (or more frequent) red team exercise or penetration test to simulate real attacker behavior. These exercises help identify gaps in both technical controls and teamwork, ensuring the incident response team stays sharp and confident.
Business Unit-Specific Plans: Develop and maintain incident response playbooks or sub-plans for key business functions such as Finance, HR, Legal, etc. Each department should understand how a cyber incident could affect them and have tailored procedures. (For example, a plan for handling a potential payroll breach in HR, or a customer data breach in Sales.) During an incident, these function-specific plans dovetail into the central IR plan so that business process owners are engaged and aware of their responsibilities. This also fosters cross-department communication during incidents.
Supply Chain and Third-Party Preparedness: Include third-party incident response processes for critical vendors and suppliers. The CISO should ensure that contracts with vendors include incident notification requirements and cooperative response clauses. Prepare a procedure for responding to incidents originating at a third-party (for instance, if a managed service provider or cloud provider is breached) – including who must be contacted and how the investigation will be coordinated. In our interconnected environment, readiness must extend beyond the walls of your own organization.
Security Awareness Training: Continuously train employees to be the “human sensor” and first line of defense. Conduct frequent cybersecurity awareness training focusing on phishing, social engineering, and proper incident reporting channels. Users should know how to spot and report suspicious emails or activity immediately, since prompt internal reporting can drastically reduce incident response times. Simulated phishing campaigns are an effective tool to measure and improve the organization’s alertness. Broad cyber hygiene education (e.g. not plugging in unknown USBs, using strong passwords) also reduces the likelihood of incidents in the first place.

To gauge and improve readiness, the CISO should track key metrics across detection and response activities:

Mean Time to Detect (MTTD): How long on average it takes to discover an incident after it has started. A lower MTTD means the organization’s monitoring and alerting is effective.
Mean Time to Contain/Remediate (MTTR): The average time to isolate the threat and fully resolve an incident. This reflects the efficiency of the response process once an incident is detected.
Internal vs. External Detection Ratio: What percentage of incidents are detected by the organization’s own controls (internal) versus reported by outside entities (external) such as customers, partners or law enforcement. A higher internally-detected rate indicates better visibility; the goal is to catch incidents before outsiders notice. (Many organizations strive to flip the ratio so that the majority of incidents are internally detected rather than by a third party.)
Training and Simulation Metrics: For example, the completion rate of security training across staff, and the success rate of employees in phishing email tests (e.g., what portion clicked a fake phishing link). These numbers help quantify the human risk factor and the effectiveness of security awareness efforts. Improvement over time (e.g. phishing click rates going down) is a positive sign.
Post-Incident Review findings: Track the number of actionable lessons learned identified in post-incident analyses and how many of those have been implemented. This indicates whether the organization is truly learning and improving from incidents (a marker of growing maturity).

By analyzing these metrics, a CISO can identify bottlenecks – for instance, if time to detect is too high, it may prompt investment in better detection tools or 24/7 monitoring; if most incidents are found by external parties, it’s a red flag that logging/alerting is insufficient. The CISO should present these metrics to executive management to demonstrate incident response effectiveness and justify further resource needs.

4. Integrating CIR with Enterprise Risk and Compliance

An effective incident response program should be woven into the organization’s broader enterprise risk management (ERM) and compliance framework, rather than operating in isolation. This integration ensures that incident handling is aligned with the company’s risk appetite, legal obligations, and governance processes. In practice, this means the CISO and risk management teams work hand-in-hand to evaluate and address incidents as part of overall business risk. Notably, NIST’s latest guidance explicitly maps incident response activities to the core functions of the NIST Cybersecurity Framework (CSF) (Detect, Respond, Recover), underscoring that incident response is a pillar of holistic risk management.

Risk Alignment: Define incident severity levels and escalation triggers in terms of business impact and risk tolerance. For example, an incident affecting a critical system or sensitive data would be classified as “High” impact and invoke higher-level management notification, possibly even a crisis management team. These categorizations should mirror the organization’s risk register and impact criteria. By aligning incident severity with risk thresholds, the response can be scaled appropriately to the potential harm. (For instance, the risk committee may set a tolerance that any incident potentially impacting customer personal data is treated as a top severity event.) NIST emphasizes that incident response should be integrated into the organization’s risk management activities, meaning lessons from incidents inform risk assessments and security improvements going forward. Likewise, larger enterprises often have formal risk committees or steering groups – the CISO should regularly report incident trends and lessons to these bodies, ensuring that cyber risks are understood in business terms and factored into enterprise risk decisions.

Compliance and Legal Obligations: Incident response processes must account for various breach notification laws and regulatory requirements. Different jurisdictions and industries have specific rules on what constitutes a notifiable incident and the timeframe for reporting. For example, under the EU GDPR, a data breach involving personal data must be reported to authorities within 72 hours of discovery. In the US, healthcare breaches (HIPAA) involving PHI require notification to affected individuals (and HHS) within 60 days, and potentially media notification if over 500 records are involved. Financial sector regulations (like GLBA or PCI-DSS) similarly mandate incident response and breach reporting. The CISO should ensure the CIR plan includes clear guidelines for when legal counsel must be engaged and when notifications are required (and to whom). This might involve pre-drafted breach notice templates and an approval workflow that includes Legal and PR teams for messaging. Failing to meet notification obligations can result in hefty fines and damage (for instance, GDPR non-compliance can lead to fines up to 4% of global revenue), so the IR team must treat compliance as a critical part of incident handling.

Incident Documentation and Risk Posture Updates: Every incident (especially high-severity ones) should result in documentation that feeds into the organization’s risk register and audit reports. The CISO should work with the GRC (Governance, Risk, Compliance) staff to log incidents, root causes, and remediation actions. This provides an audit trail demonstrating due diligence for regulators and can support future compliance audits. Additionally, incidents often reveal previously unidentified risks or control weaknesses – these should be evaluated and the enterprise risk register updated accordingly. For example, if an incident exposed a gap in third-party vendor security, that risk should be formally noted and tracked to ensure mitigation (such as enhancing vendor assessments or contract requirements). Many organizations integrate incident response metrics into their compliance dashboards or Balanced Scorecard, ensuring executives have visibility into how security events are being managed and what the trends are.

Integration Points: The CISO should ensure that incident response is connected with other business continuity and governance processes:

Business Continuity/Disaster Recovery (BC/DR): Synchronize incident response plans with BC/DR plans. A severe cyber incident (like ransomware taking down systems) has business continuity implications. The IR plan should coordinate with DR procedures (e.g., when to failover systems, when to invoke manual workarounds) so that responding to the incident also considers keeping the business running.
Executive and Board Reporting: Significant incidents should trigger updates to the executive team and possibly the board of directors. Many boards now require to be informed of cyber incidents above a certain threshold. The CISO should have an established channel to communicate incident status and business impact to top leadership in a timely manner (often following a predefined escalation matrix as noted in governance). This keeps cyber risk on the agenda at the highest level.
Legal Hold & Investigations: For incidents that could lead to legal action (for example, data breaches that might result in lawsuits or regulatory inquiries), the incident response process should involve the legal team to initiate “legal hold” on relevant data and guide the collection of evidence in a way that is admissible. Coordination with eDiscovery processes and outside counsel might be necessary.
Policy and Control Adjustments: After incidents, the CISO should work with policy owners to update security policies or technical controls. For instance, if an incident occurred because of a misconfigured server, the hardening standards or audit processes may need revision. If a new type of phishing attack is observed, the email filtering rules and user training content might be updated. Essentially, incident response becomes a feedback loop into the organization’s overall security posture management.

Additionally, aligning with well-known frameworks can provide a structured approach to these integrations: the NIST CSF provides categories for Respond (RS) and Recover (RC) functions that map to having communications plans, analysis, mitigation, and improvements – the CISO can use these subcategories as a checklist to ensure all areas are covered. Meanwhile, the CIS Critical Security Controls, specifically Control 17 (Incident Response Management), outlines best practices such as developing an IR plan, assigning roles, training the team, and defining communications and reporting processes. Adhering to such frameworks not only improves incident response effectiveness but also demonstrates to auditors and regulators that the organization follows industry standards.

5. Scaling CIR for Organizational Maturity

Incident response capabilities should scale and evolve as an organization grows in size and cyber maturity. A “one-size-fits-all” approach will not work – a small company’s CIR needs and resources differ vastly from a large enterprise’s. Below we highlight what CIR activities and structures are reasonable for small, medium, and large organizations, and what to expect at each level of maturity:

Small Organizations (< 500 users): Often lack dedicated full-time security staff, so they typically outsource incident monitoring and response to a third-party such as a Managed Security Service Provider (MSSP) or Managed Detection & Response (MDR) provider. The CISO (if one exists, or an IT manager wearing the security hat) should ensure basic incident response playbooks are in place – for example, what to do if ransomware hits a PC or if a phishing email results in a suspected breach – even if the initial response will be handled by an external partner. Emphasis is on a few common threats that disproportionately affect small businesses (phishing, business email compromise, and ransomware are top concerns). Simple incident logging is important: maintain an incident register to record incidents and how they were handled, which helps in learning and also in communicating with cyber insurance or regulators if needed. Small orgs should leverage external expertise for serious incidents (e.g., having a retainer with a digital forensics firm for major breaches) rather than trying to build everything in-house, given limited budgets.
Medium Organizations (≈ 500–5,000 users): Typically have some in-house security capability, often a small Security Operations Center (SOC) or a security team that handles incident response during business hours (with on-call arrangements for off-hours). These organizations should establish formal incident SLAs (Service Level Agreements) – for instance, a high-severity incident will be responded to (acknowledged and initial containment steps) within 1 hour, medium within 4 hours, etc. The CISO can justify dedicated headcount for incident response or augment with external MDR services for 24/7 coverage. Medium organizations can develop more custom detection rules tuned to their environment (for example, SIEM use cases for their specific applications) and build automated scripts for common containment actions (e.g., a script to disable a compromised account across AD, VPN, and cloud apps quickly). Playbooks become more detailed: a medium org might have playbooks for a dozen scenarios (phishing, malware outbreak, lost laptop, web application attack, etc.), whereas a small org might only have a few general ones. The incident response function at this level should also start to incorporate threat intelligence feeds to stay ahead of threats and possibly engage in lightweight threat hunting (searching proactively through logs for indicators of attacks that evaded detection). Coordination with IT operations is key – for example, ensuring patching is accelerated post-incident and that the incident response team can readily call on IT admins for changes during response.
Large Organizations (> 5,000 users): Large enterprises often operate a dedicated 24/7 SOC with tiered incident response teams (Level 1 analysts monitoring, Level 2/3 handling incidents, forensic specialists, etc.). The CIR program here is fully institutionalized. Expect extensive use of SOAR automation – playbooks that automatically enrich alerts, isolate endpoints, or block malicious domains in seconds – to handle the high volume of daily alerts efficiently. Large organizations also invest in proactive capabilities: a threat hunting team continuously looks for hidden threats, an insider risk program monitors for internal misuse, and regular purple team exercises (collaboration between red team attackers and blue team defenders) are conducted to validate and improve detection and response capabilities. At this scale, the incident response process is highly refined and metrics-driven – Mean Time to Contain might be measured in minutes for straightforward malware incidents. The CISO of a large org will ensure redundancy and depth in the IR team (so multiple incidents can be handled in parallel) and likely have specialized roles like threat intel analysts, malware reverse engineers, and incident commanders for crisis situations. Additionally, large enterprises often run crisis management simulations that include executive leadership, since a cyber incident can have broad business implications (for example, addressing public relations and shareholder communications in the event of a major data breach). The maturity at this level also involves integrating incident response with enterprise-wide risk management on a continuous basis – feeding insights to strategic risk committees and adapting security controls enterprise-wide based on lessons from incidents.

It’s important to note that as organizations progress from small to large, they should level up their incident response maturity rather than just increasing scale. This often follows a capability maturity model where initially responses are ad-hoc, then gradually become more defined, documented, and optimized at the highest level. The Appendix below provides a Maturity Model that describes this evolution. By understanding where the organization stands, a CISO can prioritize the improvements that will have the most impact on making incident response more effective.

Appendix A: CIR Program Maturity Model

The following maturity model outlines levels of capability in a Cyber Incident Response program, from reactive to optimized. It can serve as a roadmap for a CISO to assess their organization’s current state and plan improvements. Each level builds on the previous, adding formality, integration, and automation.

Maturity Level	Description	Key Capabilities at this Level
Level 1: Reactive	Cyber incident response is largely ad-hoc or “firefighting.” There is no formal process or dedicated team – responses are improvised when incidents occur. Documentation is minimal or non-existent.	– Incidents handled informally (no written plan). – Reliance on individual heroics and improvised actions. – Communication is unstructured (e.g., ad-hoc email or calls to address issues).
Level 2: Defined	A basic incident response plan exists and some team members have training. Processes are defined on paper but still largely manual. The organization is developing consistency in how incidents are handled.	– Formal Incident Response Plan documented and approved. – Team roles identified (perhaps as part-time duties). – Basic incident classification (criteria for low, medium, high incidents). – Containment and remediation steps defined for common incident types (though execution may be manual).
Level 3: Managed	Incident response is executed with repeatability and measured for performance. Playbooks are in use for various scenarios. The organization collects metrics and conducts post-incident reviews to refine processes.	– Dedicated incident response team or defined on-call personnel. – Playbooks for frequent incident types (phishing, malware, etc.) are established and followed. – Key incident metrics (MTTD, MTTR, etc.) are tracked consistently. – Formal post-incident review process in place to identify lessons and update plans. – Tools like SIEM and SOAR are actively used to assist in detection and response.
Level 4: Integrated	Incident response is well-integrated into business operations and risk management. The response process is enterprise-wide, with coordination across departments. The program is proactive, incorporating threat intelligence and hunting.	– Incident response is part of the organizational culture; senior management and business units are actively involved. – Incident response procedures align with enterprise risk management – e.g., incident severity ties to risk impact, reporting goes to risk committees. – Extensive training and awareness across the organization; regular cross-functional incident exercises including executives. – Proactive capabilities like threat hunting and use of external threat intel to pre-empt incidents. – Compliance considerations (regulatory reporting, privacy implications) are built into IR procedures at every step.
Level 5: Optimized	The CIR program focuses on continuous improvement and innovation. Response is highly automated and orchestrated. The organization sets industry best practices. Security and incident response are a competitive advantage.	– Continuous improvement loop is in place: lessons learned systematically drive improvements, and the program adapts quickly to the evolving threat landscape. – Extensive automation: incidents are detected and even partially remediated by AI/ML and automated playbooks in real time. – Advanced analytics and simulations predict and preempt incidents (moving towards an “anticipate and prevent” posture rather than purely reactive). – Full engagement from leadership; cybersecurity resilience is ingrained in strategic planning and enterprise risk at the highest levels. – The organization frequently validates its state with red/purple team ops and benchmarking, and contributes to industry incident response knowledge sharing (thought leadership).

Appendix B: Sample Incident Response Templates

For reference, here are key templates and documentation that a CISO should develop as part of a comprehensive incident response program. Having these prepared and updated will greatly speed up response and ensure nothing critical is overlooked under pressure:

Incident Response Plan Template: An outline of the master IR plan document, typically including Purpose and Scope, Roles and Responsibilities, Incident Categorization (severity levels), Incident Handling Procedures (aligned to each phase of the lifecycle), Communication Plan, and contacts. This serves as the playbook for the overall response process. It often also defines criteria for incident declaration and escalation. (Many organizations use industry templates such as the SANS or NIST 800-61 example IR plan; see Appendix A of NIST 800-61 or templates from organizations like NASA or state governments for reference.)
Incident Notification/Communication Template: Predefined forms or text for notifying stakeholders of an incident. For example, an email template to inform executive leadership of a serious incident, or customer breach notification letter templates that comply with legal requirements. Having these on hand ensures communications during incidents are prompt, consistent, and reviewed by Legal/PR in advance.
Incident Tracking Log: A form or system template for recording incident details in real time. This might be a spreadsheet or ticketing system entry that tracks key information: date/time discovered, reporter, description of events, systems/users impacted, containment actions taken, eradication actions, recovery steps, and lessons learned. A structured log is invaluable for post-incident analysis and for satisfying audit requirements.
Technical Incident Playbook Templates: Step-by-step guides for responding to specific incident scenarios. For instance, a “Ransomware Playbook” that lists immediate steps (disconnect system from network, engage incident lead, preserve evidence), containment steps (e.g., isolate affected network segment, reset passwords), eradication (wipe and rebuild machines), recovery (restore from backup, etc.), and post-incident tasks. Similar playbooks should exist for common scenarios like phishing compromise, lost/stolen device, denial-of-service attack, malware outbreak, insider data theft, etc. These templates ensure that responders don’t miss critical steps and can respond in a repeatable way.
Post-Incident Review Report Template: After action report form to document the incident and response in detail. It prompts the team to record timeline of events, root cause analysis, what controls failed or worked, and recommended improvements. This template ensures consistency in how PIRs are conducted and reported. It often includes sections for executive summary, technical details, and an improvement plan.
Incident Response Team Contact Directory: A maintained list (could be part of the IR plan or a separate quick-reference document) with all IRT members and key external contacts. This includes 24x7 contact info for each team member, department heads, emergency vendors (for IR consulting, forensics, etc.), law enforcement contacts, cyber insurance hotline, and so forth. In an incident, having this at your fingertips (even as a hard copy) saves precious time. Many organizations include this as a one-page appendix in the IR plan for easy access

These templates should be stored in an accessible location (with backups offline in case of ransomware). The CISO is responsible for keeping them up to date – e.g., if personnel change or if lessons learned suggest adding a step to a playbook, the template should be revised. Regular testing of the incident response plan via exercises will also highlight if template documents are missing information or need refinement.