Skip to main content
Promotional banner ad for the Penetration Testing Report Kit
Build a Dual-Reporting Incident Response PlanRegulatory & Privacy Compliance
5 min readFor Business Continuity Managers

Build a Dual-Reporting Incident Response Plan

The Cyber Incident Reporting for Critical Infrastructure Act (CIRCIA) final rule is under White House review. If you're managing incident response for a defense contractor or critical infrastructure entity, you'll soon operate under two distinct reporting regimes. The Department of Defense requires cyber incident reports within 72 hours. CIRCIA will add a parallel 72-hour requirement to CISA, with different scope, follow-up obligations, and retention periods.

This isn't theoretical. The rule is expected to impact nearly 300,000 organizations nationwide. A Government Accountability Office report found that about 70% of the 117 federal cybersecurity regulations carry overlapping reporting requirements, and harmonization efforts have made limited progress. CISA's proposal allows organizations to satisfy CIRCIA with a similar report filed to another federal agency, but only if CISA strikes a formal agreement with that agency. No such agreement exists with the Pentagon, and none appears imminent.

You need a response plan that handles both regimes without doubling your team's workload or missing a deadline.

What You Need Before Starting

Before building the dual-reporting workflow, verify your current state:

Regulatory scope confirmation
Determine whether your organization falls under both CIRCIA (as a critical infrastructure entity in one of 16 designated sectors) and DFARS 252.204-7012 or similar DoD cyber incident reporting requirements. If you hold DoD contracts involving controlled unclassified information, you're already subject to the 72-hour Pentagon reporting requirement.

Existing incident classification framework
Review your current incident severity matrix. The Pentagon's reporting threshold focuses on incidents involving controlled unclassified information. CIRCIA defines "substantial" cyber incidents more broadly, including those that lead to significant loss of confidentiality, integrity, or availability of a system or network. These definitions don't align perfectly, so you'll need to map both.

Breach Coach and legal review capacity
Ensure your organization has access to breach counsel who can review incident facts under attorney-client privilege before you submit government reports. This matters because CIRCIA requires two years of incident data retention compared with 90 days under DFARS, extending your exposure window.

Technical logging and evidence collection tools
Centralized logging is essential to capture the data elements both regimes require: incident start time, affected systems, data types involved, threat actor indicators, and response actions taken. If you're relying on decentralized logs or manual collection, you won't meet either 72-hour deadline.

Step-by-Step Implementation

Step 1: Build a dual-threshold decision tree
Create a flowchart your incident response team can reference during initial triage. The first branch: Does this incident involve controlled unclassified information on a DoD contract system? If yes, the DoD reporting clock starts immediately. The second branch: Does this incident meet CIRCIA's "substantial" threshold (system compromise, data exfiltration, operational disruption, or extortion demand)? If yes, the CISA reporting clock starts.

Some incidents will trigger both. Some will trigger only one. Document the logic so your on-call responder doesn't need to interpret policy during an active event.

Step 2: Draft parallel reporting templates
Build two incident report templates that share a common core but diverge where the requirements differ. Both need incident timeline, affected systems, and initial containment actions. The DoD report focuses on CUI exposure and contract-specific impact. The CIRCIA report requires broader operational context, including whether the incident caused substantial harm to your organization's ability to operate.

If CIRCIA requires follow-up reports as new details emerge (the current proposal suggests this), build a tracking system that flags which incidents need ongoing updates to CISA versus one-time DoD reports.

Step 3: Assign reporting ownership with clear escalation paths
Designate a primary incident reporter for DoD obligations and a separate owner for CIRCIA submissions, even if it's the same person wearing two hats. The reporting mechanisms will differ, the recipient agencies have different operational cultures, and you don't want a single point of failure.

Document the escalation path: If the primary reporter is unavailable, who has authority to submit? If legal review isn't complete by hour 60 of a 72-hour window, who makes the call to file with preliminary information?

Step 4: Integrate reporting into your incident response runbook
Your existing IR playbook should already include notification steps. Add two new checklist items at the initial triage stage: (1) Assess DoD reporting threshold, (2) Assess CIRCIA reporting threshold. Add a third item at the 48-hour mark: Confirm draft reports are prepared and under legal review, with 24 hours remaining for submission.

If you're using an IR platform like Resilient, ServiceNow Security Operations, or Cortex XSOAR, configure automated reminders at the 48-hour and 60-hour marks for any incident flagged as reportable.

Step 5: Establish a legal review protocol that doesn't block the clock
Your Breach Coach needs to review report content before submission, but you can't let legal review consume your entire 72-hour window. Set a policy: Draft reports must be ready for legal review no later than 48 hours after incident detection. Legal review must be complete within 12 hours of receiving the draft. If legal review identifies issues that require additional investigation, you still file the report on time with a notation that supplemental information will follow.

Validation: How to Verify It Works

Run a tabletop exercise with a scenario that triggers both reporting requirements. Use a realistic case: An attacker exfiltrates controlled unclassified information from a DoD contract system and deploys ransomware that disrupts your operations. Start the clock and execute your dual-reporting workflow.

Measure these outcomes:

  • Did the team correctly identify both reporting obligations within the first two hours?
  • Were both draft reports ready for legal review by hour 48?
  • Could the assigned reporters access the correct submission portals and had the necessary credentials?
  • Did the reports contain all required data elements for each regime?

If any step failed, document the gap and revise your runbook before the next exercise.

Maintenance and Ongoing Tasks

Quarterly reporting drill
Every quarter, run a condensed tabletop that tests your dual-reporting workflow. Rotate the scenario type (ransomware, data theft, denial-of-service) to ensure your decision tree handles different incident classes.

Monitor for regulatory updates
CISA may issue clarifying guidance after the final rule is published, particularly around the "substantial" incident threshold and the follow-up reporting cadence. Assign someone to monitor CISA's CIRCIA implementation page and DoD's cybersecurity policy updates. When guidance changes, update your templates and decision tree within 30 days.

Annual review of reporting contacts and credentials
Verify that your designated reporters still have valid credentials for both the DoD Cyber Crime Center (DC3) portal and whatever CIRCIA submission mechanism CISA establishes. If your Breach Coach changes, update your escalation contacts.

Track reporting metrics
Maintain a log of all incidents assessed against both thresholds, even if they didn't require reporting. Track how many incidents triggered DoD reporting only, CIRCIA reporting only, or both. This data will help you refine your decision tree and justify resource allocation when leadership asks why you need dedicated compliance staff.

The dual-reporting burden isn't going away. Build the workflow now, before you're managing it under the pressure of an active incident.

Application Security Isn’t Optional Anymore.

You Might Also Like