Emergency Patch Response Runbook Template

When PaperCut disclosed zero-day exploitation on August 27, 2026, some organizations patched within hours. Others remained vulnerable weeks later. The difference wasn't budget or tooling; it was process.

Here's a ready-to-deploy runbook template for responding to emergency vendor patches. It's built around the PaperCut incident pattern but works for any critical vulnerability disclosure where your vendor ships emergency fixes and you need coordinated action across security, IT, and business units.

Purpose of This Runbook

This template structures your response when a vendor announces active exploitation of a zero-day vulnerability in software you use. It covers the first 72 hours: from initial disclosure through patch deployment and post-deployment validation.

The template assumes you're dealing with:

• A vendor-disclosed vulnerability with available patches
• Evidence of active exploitation
• Enterprise software with multiple deployment points
• The need to preserve forensic evidence before remediation

You'll adapt sections based on whether you're running affected versions, whether patches exist for your branch, and whether you find indicators of compromise.

Prerequisites

Before deploying this runbook:

Technical requirements:

• Current asset inventory showing all instances of the affected software, including version numbers and deployment locations
• Access to vendor security bulletins and patch repositories
• Backup infrastructure capable of capturing pre-patch system state
• Administrative access to all affected systems
• Forensic evidence collection tools

Organizational requirements:

• Pre-authorized communication channels to security, IT operations, and affected business units
• Defined escalation path to executive leadership for production system downtime decisions
• Legal and compliance contacts identified for potential breach notification obligations

Knowledge requirements:

• Understanding of your software's architecture
• Documented dependencies and downstream impacts of taking systems offline
• Recovery time objectives for affected systems

The Emergency Patch Response Runbook

Hour 0-4: Initial Assessment and Evidence Preservation

Trigger: Vendor disclosure of active exploitation or security team detection of compromise indicators.

Actions:

1. Inventory verification (Security Lead)

   • Query asset management system for all instances of [SOFTWARE NAME] versions [AFFECTED VERSIONS]
   • Document: version number, server hostname, IP address, business function, data classification
   • Flag internet-facing instances separately
   • Expected output: Spreadsheet with columns: [Instance ID | Version | Exposure | Business Owner | Patch Priority]

2. Forensic preservation (Incident Response)

   • Before remediation, capture system state for all potentially compromised instances
   • Collect: application logs from past 30 days, system event logs, network connection logs, running process lists
   • For internet-facing instances: full disk image and memory dump
   • Store evidence in a write-once location with chain-of-custody documentation
   • Document preservation timestamp and analyst name

3. IOC sweep (Detection Engineering)

   • Deploy vendor-provided indicators of compromise across all instances
   • For PaperCut pattern: Check for processes named pc-app.exe spawning cmd.exe, unexpected services named "Remote Access Service," AnyDesk installations in non-standard paths, outbound connections to file-sharing hosts
   • Document findings in incident tracker with severity classification
   • Any confirmed IOC triggers immediate isolation (see Hour 4-8)

4. Business impact assessment (Service Owner + Security)

   • For each affected instance, document: users impacted by downtime, revenue impact per hour, compliance obligations, acceptable maintenance window
   • Classify instances: [Critical - patch within 4 hours | High - patch within 24 hours | Standard - patch within 72 hours]
   • Get executive sign-off on downtime windows for production systems

Hour 4-8: Containment and Patch Deployment Planning

Actions:

5. Network segmentation (Network Security)

   • Restrict web access to Application Server to trusted IP addresses only
   • Implement firewall rules blocking outbound connections to known malicious infrastructure
   • For compromised instances: full network isolation pending rebuild decision

6. Patch applicability review (Security Engineering)

   • Verify which patch version applies to each software branch you're running
   • For PaperCut pattern: v25/v26 branches received patches immediately; v24 received patches in second round; v23 and older require upgrade path
   • Document upgrade path for unsupported versions
   • Identify test environment for patch validation before production deployment

7. Deployment sequence planning (Change Management + Security)

   • Order: Test environment → non-production instances → isolated production instance → production rollout
   • For multi-component systems: Document which components require patching
   • Schedule maintenance windows with business owners
   • Prepare rollback plan if patch causes operational issues

Hour 8-24: Patch Execution

Actions:

8. Test environment validation (QA + Security)

   • Deploy patch to test instance matching production configuration
   • Verify: application functionality, integration points, performance baselines
   • Run vulnerability scanner to confirm patch effectiveness
   • Document any issues before production deployment

9. Production patching (IT Operations)

   • Deploy patches following approved sequence
   • For each instance:
     • Verify pre-patch backup completion
     • Apply patch per vendor instructions
     • Restart services as required
     • Verify application availability
     • Document patch version and deployment timestamp
   • Monitor for unexpected behavior or performance degradation

10. Compromised system remediation (Incident Response)

    • For any system with confirmed IOCs:
      • Secure current backup
      • Wipe and rebuild system from known-good image
      • Restore clean backup taken before suspicious activity
      • Apply all current patches before reconnecting to network
    • Activate incident response procedures per your organization's playbook
    • Preserve all forensic evidence for potential law enforcement or insurance claims

Hour 24-72: Validation and Monitoring

Actions:

11. Patch verification (Security Operations)

    • Run authenticated vulnerability scans against all patched instances
    • Verify patch version matches vendor's latest release
    • For PaperCut pattern: If vendor releases second hardening patch, deploy even if first patch was applied
    • Document any instances that failed patching or remain vulnerable

12. Enhanced monitoring (SOC)

    • Deploy behavioral detections for post-exploitation patterns
    • For PaperCut pattern: Alert on pc-app.exe process launching shell commands, new service installations in ProgramData paths, unexpected remote access tool deployments
    • Increase log retention period for affected systems to 90 days
    • Schedule daily IOC sweeps for next 30 days

13. Stakeholder communication (Security Leadership)

    • Brief executive leadership on: total instances patched, any confirmed compromises, residual risk from unpatched systems, ongoing monitoring plan
    • Notify affected business units of completed maintenance
    • For confirmed compromises: Assess breach notification obligations with legal counsel
    • Document lessons learned and process gaps for runbook improvement

Customizing This Runbook

For your software stack: Replace [SOFTWARE NAME] and [AFFECTED VERSIONS] with your specific applications. Maintain separate runbooks for categories: enterprise applications, infrastructure software, security tools.

For your organization size:

• Small teams (under 100 instances): Collapse Hours 0-4 and 4-8 into a single response phase
• Large enterprises: Add approval gates before each phase, expand stakeholder communication section
• Multi-cloud: Add cloud provider-specific isolation and patching procedures

For your risk tolerance: Adjust the classification thresholds in step 4. Higher-risk environments might make all internet-facing instances "Critical" regardless of business function.

For vendor-specific patterns: The PaperCut incident revealed that 47% of installations tracked were running unsupported versions with no available patch. Add a section addressing your upgrade policy for end-of-life software.

For compliance requirements: If you're subject to breach notification laws, add explicit decision points: "If forensic analysis confirms data access, initiate notification assessment within 24 hours per [REGULATION]."

Validation Steps

After deploying this runbook in an actual incident:

Technical validation:

• All affected instances show patched version in asset inventory
• Vulnerability scans return no findings for disclosed CVEs
• No IOC detections in past 7 days
• Enhanced monitoring rules deployed and generating alerts on test cases

Process validation:

• Executive briefing completed with documented decisions
• All forensic evidence preserved with chain of custody
• Change management records show approved maintenance windows
• Incident timeline documented with timestamps and responsible parties

Continuous improvement:

• Conduct post-incident review within 5 business days
• Measure: time from disclosure to first patch, time to complete patching, percentage of instances requiring rebuild
• Update runbook based on gaps identified during execution
• Schedule tabletop exercise within 90 days using different vulnerability scenario

The attackers who exploited PaperCut had AI tools to identify vulnerabilities and write exploits. Your advantage isn't speed of discovery; it's speed of coordinated response. This runbook compresses the decision-making that slows most organizations from days to hours.