IR-2(3): Breach

IR-2(3) requires you to train your workforce to recognize a breach, take correct first-response actions, and follow your organization’s breach reporting process. To operationalize it, define what “breach” means for your environment, map reporting paths and time-critical notifications, train by role, and keep durable evidence that training occurred and works in practice. ¹

Key takeaways:

• Train for breach-specific identification, containment-first actions, and reporting paths, not generic “security awareness.” ¹
• Evidence needs to prove completion, role coverage, and that staff know how to report a suspected breach. ¹
• The fastest audit wins come from a control card, a minimum evidence bundle, and recurring control health checks. ¹

IR-2(3): Breach sits inside the NIST incident response training control family and focuses your training program on a specific failure mode: people don’t recognize a breach quickly, and they don’t report it through the right channel. The result is delayed containment, confused notifications, and inconsistent incident records. This enhancement narrows the scope to breach identification and breach reporting, so your training must teach staff what “counts,” what to do first, and who to tell.

For a Compliance Officer, CCO, or GRC lead, the fastest path is to treat IR-2(3) as an operational requirement with a named owner, a defined cadence, role-based modules, and a repeatable evidence package. Auditors rarely argue with well-organized proof: a training syllabus mapped to breach scenarios, rosters showing completion, and artifacts that demonstrate staff know the reporting process.

If you use a GRC system like Daydream, this requirement is a good candidate for a “control card” workflow: objective, owner, trigger events, execution steps, and exceptions. That structure reduces ambiguity and makes evidence collection routine instead of a scramble.

Regulatory text

Requirement (IR-2(3): Breach): “Provide incident response training on how to identify and respond to a breach, including the organization’s process for reporting a breach.” ¹

Operator meaning: Your incident response training program must explicitly cover:

1. How to identify a breach (recognition and indicators),
2. How to respond to a breach (first actions and escalation expectations), and
3. How to report a breach internally using your defined process (who, how, and what information). ¹

This is training, not policy. A policy may describe reporting requirements, but IR-2(3) expects you to teach people how to execute them.

Plain-English interpretation (requirement-level)

You must be able to show that the people who could detect, handle, or escalate a breach have been trained to:

• Spot likely breach conditions relevant to your environment (lost credentials, exposed data stores, misdirected disclosures, unauthorized access, etc.).
• Take appropriate immediate actions for their role (preserve evidence, stop the bleeding, don’t destroy logs, don’t “self-remediate” in ways that erase artifacts).
• Report quickly using the official path (ticketing hotline, SOC channel, privacy mailbox, IR on-call), with the minimum information needed to start triage. ¹

Who it applies to

Entities: Federal information systems and contractors handling federal data commonly inherit or implement NIST SP 800-53 control expectations, including IR-2(3). ¹

Operational context (who needs training):

• All workforce members who may observe suspicious activity or handle sensitive data (employees and long-term contractors).
• Privileged users (IT admins, cloud admins) whose actions can worsen or contain a breach.
• Service owners and engineers who operate systems where a breach may occur (apps, data platforms, CI/CD).
• Customer-facing teams (support, account teams) who may receive breach allegations or evidence.
• Third parties with operational access (MSPs, incident response retainers, hosted service operators) should be covered through contractual training obligations or documented onboarding expectations, especially if they can detect or must report incidents to you.

What you actually need to do (step-by-step)

1) Define “breach” for training purposes

Training fails when “breach” is vague. Write a one-page “breach definition and examples” appendix aligned to your internal incident taxonomy and data types. Keep it practical:

• Examples of breach indicators relevant to your stack (cloud console access anomalies, unexpected data exports, DLP alerts, leaked secrets).
• Examples of non-breach security events to reduce noise.
• A simple decision cue: “If you suspect unauthorized access to sensitive data or systems, treat as a suspected breach and report.”
  This becomes the backbone of your training script and quiz questions. ¹

2) Document the breach reporting process in an operator-ready format

Convert your incident response plan into a “how to report a suspected breach” job aid:

• Single front door: one channel staff should use first (SOC queue, hotline, email alias, portal form).
• Escalation tree: when to page IR on-call, when to notify privacy/legal, when to notify leadership.
• Required fields: system, time, what was observed, screenshots/log pointers, data involved, actions already taken.
• Do-not-do list: don’t delete evidence, don’t reset accounts without capturing relevant logs, don’t contact suspected adversaries.
  IR-2(3) explicitly includes “the organization’s process for reporting a breach,” so this job aid is central evidence. ¹

3) Build role-based training modules (minimum viable set)

Create a core module plus role add-ons:

Core module (everyone):

• What a breach is (your definition).
• Common indicators and scenarios.
• First-response expectations (safety, containment-by-escalation, preserve evidence).
• Exact reporting steps (front door + what to include). ¹

Privileged/technical module:

• Logging and evidence preservation basics (what to collect, where logs live).
• Containment actions that are allowed without approval vs. actions that require IR lead authorization.
• How to engage third parties (cloud provider support, MSP) through approved paths.

Customer-facing module:

• How to intake a suspected breach report from a customer.
• How to avoid making commitments, timelines, or root-cause statements.
• Where to route artifacts and communications.

4) Assign ownership, cadence, and triggers (make it auditable)

Create a control owner (often IR lead + compliance partner). Document:

• Training frequency (on hire and recurring refresher).
• Trigger events for out-of-cycle training (major process change, new reporting channel, post-incident lessons learned).
  Audits frequently fail on “who owns this and how do you prove it runs.” Treat that as a design requirement. ¹

5) Deliver training and test comprehension

Don’t rely on attendance alone. Include:

• A short knowledge check focused on reporting steps and breach recognition.
• Scenario prompts by role (“You see X alert” / “Customer emails Y” / “You discover a public S3 bucket”).
  This gives you defensible evidence that staff can execute the reporting process. ¹

6) Run control health checks and close gaps

At a regular cadence, validate:

• Completion rates by role and by system criticality.
• Training content matches the current reporting channels and on-call rotations.
• Evidence is complete and stored where auditors can access it quickly. ¹

Where Daydream fits naturally: Daydream can store the IR-2(3) control card, map training content to the requirement, and attach the minimum evidence bundle per training cycle so you can answer audits and customer diligence without rebuilding a narrative.

Required evidence and artifacts to retain

Minimum evidence bundle you should be able to produce on request:

• IR-2(3) control card: objective, owner, scope, cadence, triggers, exceptions, execution steps.
• Training materials: slides, LMS module export, scripts, scenario library, job aid (“how to report a suspected breach”).
• Training completion records: rosters, LMS completion reports, onboarding checklists for relevant roles.
• Knowledge checks: quiz questions and aggregated results, plus remediation steps for failures.
• Change history: versioning for reporting process and training updates after material changes or lessons learned.
• Exception handling: documented process for exemptions (leave of absence, contractors offboarded) and make-up completion.

Common exam/audit questions and hangups

Auditors and assessors tend to probe these points:

• “Show me where your training teaches the breach reporting process, step-by-step.” ¹
• “Who is required to take this training, and how do you ensure contractors take it?”
• “How do you handle missed training and prove follow-up?”
• “How do you know staff can recognize a breach vs. any generic security event?”
• “Show evidence the training content is current with your on-call process and reporting channels.”

Hangup pattern: teams present a generic security awareness module with phishing content and call it incident response training. IR-2(3) expects breach identification and breach reporting instruction. ¹

Frequent implementation mistakes (and how to avoid them)

1. Mistake: Training describes incidents but not reporting mechanics.
   Fix: Put the reporting job aid in the module and test it with scenario questions. ¹

2. Mistake: No role differentiation.
   Fix: Add short role add-ons for privileged users and customer-facing staff, even if the core module is shared.

3. Mistake: Evidence is scattered across email, Slack, and a learning portal.
   Fix: Define a single evidence repository and evidence checklist per cycle. Daydream works well as the “system of record” for control evidence.

4. Mistake: Training is stale after process changes.
   Fix: Add “trigger events” (reporting channel change, IR tool change, org restructure) that force an out-of-cycle update. ¹

Enforcement context and risk implications

No public enforcement cases are provided in the supplied source catalog for IR-2(3). Practically, the risk is operational: delayed breach recognition, inconsistent escalation, and poor evidence preservation. Those failures compound downstream obligations (customer notice, contractual reporting, regulator engagement) because you cannot reconstruct timelines and scope cleanly.

Practical 30/60/90-day execution plan

First 30 days (stand up the control)

• Name the control owner(s) and finalize scope (who must take training).
• Draft the breach definition appendix and the one-page reporting job aid.
• Build the control card and the minimum evidence bundle checklist.
• Identify the delivery mechanism (LMS, live training) and the system of record for evidence (for example, Daydream + LMS export attachments).

Days 31–60 (deliver and prove operation)

• Publish core training and role add-ons.
• Run the first training cycle for high-risk groups (privileged users, SOC/IT, service owners, support).
• Collect completion evidence and knowledge-check outputs.
• Remediate misses: chase non-completions and document make-up sessions.

Days 61–90 (harden for audits)

• Run a tabletop-style micro-drill focused on “reporting a suspected breach” and document results as training reinforcement.
• Validate the reporting job aid is current with on-call and tooling.
• Perform a control health check: evidence completeness, role coverage, exceptions log, and content versioning.
• Prepare an “audit packet” export: control card + latest materials + completion report + knowledge check summary.

Frequently Asked Questions

Does IR-2(3) require annual training?

IR-2(3) requires you to provide incident response training on identifying and responding to a breach, including breach reporting, but it does not specify a fixed frequency in the excerpt provided. Set a cadence that matches your risk and onboarding model, then document it and retain evidence. ¹

Can I satisfy IR-2(3) with general security awareness training?

Usually no, because IR-2(3) explicitly calls for training on identifying and responding to a breach and your breach reporting process. If your awareness training includes breach recognition and reporting steps with evidence, you can map it, but most awareness modules stop at phishing and password hygiene. ¹

What counts as “process for reporting a breach” in training?

Staff need a clear front door for reporting, escalation expectations, and the minimum information to provide so triage can start. A one-page job aid embedded in the training and tested with scenario questions is the cleanest way to prove this. ¹

Do third parties need to take this training?

If third parties have operational access or are likely to detect or cause suspected breaches, you need a documented mechanism to ensure they know how to report suspected breaches to you. This can be contractual training requirements, onboarding attestations, or including them in your LMS audience.

What evidence do auditors ask for most often?

Training content that explicitly covers breach reporting steps, plus completion records that show the right populations took it. Auditors also ask who owns the training and how you keep it current when reporting channels change. ¹

How do I handle engineering teams that want to “fix first” before reporting?

Put “preserve evidence and report first” into the role-based module and spell out which containment actions are allowed without approval. Then reinforce it with a short scenario drill and document the expected behavior.

Footnotes

1. NIST SP 800-53 Rev. 5 OSCAL JSON