IR.L2-3.6.2 Incident reporting: requirements and evidence

What IR.L2-3.6.2 incident reporting requires for CMMC Level 2

If your organization handles CUI for a defense contract and must pass a CMMC Level 2 assessment, IR.L2-3.6.2 has to be MET outright. It is worth 5 points in the CMMC Scoring Methodology, and under 32 CFR 170.21 it cannot be carried on a plan of action and milestones. A missing or partial result here keeps you from reaching Conditional or Final Level 2 status, so this is a requirement to close before the assessor arrives, not one to schedule for later. The practice asks for three things to be true at once: incidents are tracked and documented, the people and authorities who must receive reports are identified, and both notifications actually happen. An assessor will test all three, and the evidence has to show that the process works in practice, not just that a policy exists.

Internally, the reporting chain needs named roles, such as who receives an alert, who decides it is a reportable incident, and who informs leadership, legal and the security officer. Externally, your contracts and the DFARS clause determine who else must hear about an event. For covered defense information, DFARS 252.204-7012(c) requires reporting cyber incidents to DoD at dibnet.dod.mil within 72 hours of discovery, using a DoD-approved medium assurance certificate. Confirm that someone in your company holds that certificate, that it is current, and that the people on call know how to use it. The 72-hour clock starts at discovery, so the internal chain must be fast enough to meet it. Ask your legal and contracts teams which other customers, primes or agencies require notice and on what timeline.

The usual failure is scattered records. Alerts sit in a SIEM, decisions are made in email threads, containment steps live in chat, and nobody can show a single account of what happened and who was told. Assessors look for incident records and reporting evidence that trace one event from detection to notification, and they may interview people who should have reported an incident. Start by choosing one system of record for each incident, then confirm that the 72-hour duty, the preservation of affected system images for at least 90 days under paragraph (e), and your internal escalation steps are written into the same procedure. Open-source case tools such as DFIR-IRIS or a helpdesk such as GLPI can hold these records, but the configuration and the written procedure must be yours, and you should confirm with your assessor which evidence they expect.

Which systems, teams and third parties does incident reporting cover?

IR.L2-3.6.2 applies wherever CUI is stored, processed or transmitted, and to every person or party that must detect, record or receive an incident report. The cards below walk through the assessment boundary, the people who report, the officials who receive reports, and the external parties that change the work.

The CUI environment in scope

Start with the systems that store, process or transmit CUI, then add anything that provides security protection for them. Incident records and the tools that hold them, such as a ticketing system or case manager that stores incident details about CUI systems, can fall inside the assessment boundary. Confirm this with your assessor's scoping view before you choose a tool, because it determines who must be able to access and protect the incident data.

Security operations and IT staff

The people who first see an anomaly, such as help desk staff, system administrators and security analysts, must know what counts as a reportable incident and where to log it. Assessors may interview anyone who has or should have reported an incident, so each role needs a documented route to the tracking system. Check that shift handoffs, after-hours contacts and staff who work outside the tracking tool are covered.

Designated officials and legal contacts

Name the internal officials who must receive incident reports, such as the security lead, the contracts or program security officer, and legal counsel. Record their roles, backups and contact paths in the incident response plan. Confirm that the reporting chain names specific people or functions, not just a mailbox, because assessors test whether reports actually reach these officials.

DoD reporting under DFARS 252.204-7012

Cyber incidents affecting covered defense information must be reported to DoD at dibnet.dod.mil within 72 hours of discovery, using a DoD-approved medium assurance certificate. Your tracking records must capture discovery time, so the 72-hour clock can be shown. Confirm that the certificate holder, the escalation path and the preservation of affected system images for at least 90 days are assigned to named roles.

Subcontractors and flowdown partners

Subcontractors that handle CUI or that discover incidents on their own systems must report to you in a timeframe that lets you meet your own DoD duty. Review flowdown clauses and written notification expectations with each subcontractor. Confirm which party reports to DoD for incidents in shared environments, because the prime contractor's record must still show the chain of events.

Managed service providers and cloud hosts

A managed service provider or cloud host that monitors your systems may detect incidents first. Their alerts, tickets and forensic data become part of your incident record, so the contract should state how they notify you and how quickly. Confirm whether the provider is inside your assessment boundary, and whether its evidence can be produced for an assessor.

How an assessor tests incident tracking and reporting

This table maps the six SP 800-171A assessment objectives for IR.L2-3.6.2 to the test an assessor runs, the evidence they ask for and the findings that usually cause a NOT MET. Read each row as a question the assessor will put to your records, interviews and reporting mechanisms, because a requirement is MET only when every applicable objective is satisfied with final evidence.

Assessment objective	How the assessor tests it	Evidence requested	Common finding
Incidents are tracked	Selects a sample of recorded incidents and checks that each one has an entry from detection through closure	Incident register or ticket export with timestamps, status history and owner	Incidents handled in email or chat with no record, or a register that stops months before the assessment
Incidents are documented	Reads the records to confirm they describe scope, affected systems, actions taken and outcome	Completed incident reports, analysis notes and lessons-learned entries for sampled incidents	Records with a title and status but no analysis, or drafts left open with no final version
Authorities that must receive reports are identified	Compares the documented list of external authorities against the contract and regulatory obligations the organization is subject to	Written reporting matrix naming each authority, the trigger for reporting and the channel used	A reporting matrix that omits DoD, or that names a contact without the trigger or channel
Organizational officials who must receive reports are identified	Checks the plan and escalation paths for named internal roles, then asks the people in those roles what they would do	Incident response plan, escalation roster and on-call or contact records with current names	Roles named by title only, with no current holder, or a roster that predates staff changes
Internal officials are notified	Traces sampled incidents through the tracking system to confirm notifications were sent to the named officials, with dates	Notification records such as ticket notes, messages or acknowledgements tied to each sampled incident	Notifications made by phone with no record, or notices sent to a former employee's mailbox
External authorities are notified	Checks for reports filed under the reporting matrix, including the DFARS 252.204-7012 report where covered defense information was affected	Copies of submissions, report reference numbers and the 72-hour timing against discovery	No record of the external report, or discovery and reporting times that cannot be reconstructed
Interviews confirm the process works in practice	Interviews staff who have or should have reported an incident and asks how they would report one, then compares answers to the written process	Interview notes and the procedure staff were trained on	Staff unaware the reporting channel exists, or answers that differ from the written plan
Tracking and reporting mechanisms are tested	Asks the assessor's test of the tool itself: can a user submit an incident, does the record persist, and does the notification fire	Configuration screenshots, workflow settings, notification rules and a live walkthrough	Mechanism exists on paper but notifications are disabled or the ticket queue is shared without access control
Evidence is final, not draft	Rejects any document marked draft, unsigned or undated and asks for the approved version	Approved, dated and version-controlled plans, matrices and incident reports	Draft reporting matrix or a plan that was never approved, which can fail an objective even when the practice exists

How to implement incident tracking and reporting, step by step

This sequence turns IR.L2-3.6.2 into a working reporting system: defined incident categories, named recipients, a timed reporting chain, one system of record, a tested DFARS 252.204-7012 path, and evidence that the chain works.

Define incident categories and reportable CUI events
Start by writing down what the organization treats as an incident and which incidents are reportable. Cover events that affect systems that store, process or transmit CUI, including suspected compromise, malware, unauthorized access, data exposure and loss of availability. Involve the security lead, IT operations and legal or contracts staff, since the contract determines what counts as a cyber incident affecting covered defense information. The output is a short, approved incident classification standard that every responder can apply without asking for interpretation. Confirm that the definitions match the scope in the system security plan so the reporting duty covers the same systems the assessor reviews.
Name internal officials and external authorities
Identify who must receive incident reports inside the organization, such as the incident response lead, the information system security officer, the executive decision maker and the contracts or legal contact. Then identify the external authorities the contract and regulations require the organization to notify, including the DoD reporting channel under DFARS 252.204-7012 and any other agency or law enforcement contact the organization has agreed to. Assign a named primary and alternate for each role. The output is a written roster of recipients with contact methods and backups, reviewed by the people who hold those roles so the assessor can confirm that designated officials exist and know their duties.
Build the internal reporting chain with timing
Map how an alert moves from the person or tool that detects it to the responder, then to the recipients named in the previous step. For each hop, record who acts, the method used and the point at which escalation happens. Set internal timing targets for triage and escalation that the organization can meet, and state them as the organization's own internal targets rather than regulatory deadlines. Include how users report suspected incidents, since assessors may interview people who have or should have reported one. The output is a documented reporting chain, usually a diagram plus a one-page procedure, that ties into the incident response plan from IR.L2-3.6.1.
Set up one system of record for incident tickets
Choose a single place where every incident is opened, updated and closed. A ticketing or case platform works, provided it records the incident description, classification, affected assets, timestamps, actions taken, decisions, the people notified and the time each notification happened. Open-source options include DFIR-IRIS for case management with evidence logging and audit trails, and GLPI or Zammad for ticket workflows. Confirm each candidate's capabilities against its current documentation before selecting it. The output is a configured system with required fields, restricted edit rights, an audit trail turned on and a test record that shows the full lifecycle, which becomes the first evidence an assessor sees.
Define the DFARS 252.204-7012 reporting path
Document how the organization reports a cyber incident affecting covered defense information to DoD under DFARS 252.204-7012. The clause requires reporting through the DoD reporting site within 72 hours of discovery, using a DoD-approved medium assurance certificate, and it requires preserving images of affected systems for at least 90 days after the report. Confirm the certificate is obtained, installed, tracked for renewal and available to the people who would file the report, because a missing certificate can block a timely submission. Write the steps for preserving images and for handing evidence to the DoD, and assign who approves the report. The output is a reporting runbook that starts from the ticket in the system of record and ends with a filed report reference stored in that ticket.
Track the 72-hour clock inside the ticket
Make the discovery time visible in the incident record so the organization can show when it discovered an incident, when each internal notification occurred and when the external report was filed. Add mandatory fields for discovery time, notification times and report reference, and create a view or alert that flags open reportable incidents. Decide who reviews the view during an active incident and who covers when the primary is unavailable. The output is a ticket template and a dashboard or query that a reviewer can run, which proves that the organization tracks timing for each reportable event, not only that a procedure exists.
Test the chain with a tabletop exercise
Run a realistic but illustrative scenario, such as a compromised workstation with CUI in its file share, and follow it through the full chain. Confirm that the detector opens a ticket, the classification matches the standard, the right officials receive notice, the DoD reporting path can be started with the certificate and the evidence is preserved. Record gaps, such as an unreachable contact, a missing field or an expired certificate, and assign owners and due dates for fixes. Keep the exercise record, the findings and the corrected procedure. This output supports the separate testing requirement in IR.L2-3.6.3 and gives an assessor a dated record that the chain has been exercised, not just documented.

How the 72-hour DoD reporting duty connects to the incident record

The incident record is the proof that the 72-hour DoD reporting duty was met, so it has to be built for that purpose before an incident occurs. DFARS 252.204-7012(c) requires a contractor to report a cyber incident affecting covered defense information to DoD at dibnet.dod.mil within 72 hours of discovery, using a DoD-approved medium assurance certificate. The clock starts at discovery, not at the moment the team confirms a breach or finishes its analysis. An assessor or contracting officer will ask when the organization discovered the event, so the record must hold that timestamp in a form that can be checked against logs, alerts and the first analyst note. Confirm with your counsel and your DIBNet certificate holder who has authority to submit, and confirm that the certificate is current before you need it.

Your IR.L2-3.6.2 evidence and your DFARS obligation draw on the same records. The tracking and documentation that NIST SP 800-171A expects for 3.6.2, along with the defined recipients for internal officials and external authorities, should show who was notified, when, through which channel and what they received. For a covered incident, the record should also hold the DIBNet report reference, the preservation status of affected images, and the ticket or case ID that links them. Paragraph (e) of the clause requires preserving images of affected systems for at least 90 days after the report, so the same record should show where images are stored, who controls access and when the retention period began. Ask whether your ticketing or case tool can attach these items to one incident without manual copying, since a split record is hard to defend.

The Department of War's 13 July 2026 suspension of CMMC Phase II does not remove DFARS 252.204-7012 obligations. Phase I self-assessments, SPRS postings, annual affirmations and the incident reporting duty all remain in place, so a contractor that treats the suspension as a pause on reporting discipline is taking on contract risk. Before the next tabletop or review, check that your reporting chain names current people and current contact details, that the discovery-time field is mandatory in your incident template, and that the 90-day preservation rule is written into your procedure. Confirm the current status of CMMC rules with your contracting officer and the official DoW CIO guidance, since the rules have changed during 2026.

Which evidence passes IR.L2-3.6.2

An assessor testing IR.L2-3.6.2 looks for proof that incidents are tracked, that the reporting chain is defined, and that notifications actually went out. The cards below cover the artifacts that carry that proof, and each one needs to be current and in final form at the moment of assessment, not just written once.

Incident records and tracking log

Every incident, including minor events that were closed without escalation, should have one record with the detection time, the description, the affected systems, the decisions taken and the closure date. Assessors often sample records to confirm the log is complete, so check that the ticket or case history cannot be quietly edited after closure. Gaps in the sequence of incident numbers are a common question during interviews.

Reporting chain and designated officials

Keep a current list of the internal officials who must receive incident reports and the external authorities that apply to your contracts, such as the DoD reporting channel for covered defense information. Record the named role, the backup, the contact route and the date the list was last confirmed. Assessors compare this list with what people say in interviews, so a list that names someone who left the company will be noticed.

Incident monitoring and reporting procedures

Write down how an event moves from detection to an official, including who triages it, the time limits you have set internally, and how the report is made. The procedure should match what staff actually do, because SP 800-171A treats interviews with people who have or should have reported an incident as a test of the procedure itself. Review it after each real incident and after each organizational change.

Incident response plan

The plan should state the reporting duties as well as the response steps, and it should name the owner who approves each revision. Version history with dates, approval records and the revision that was in force at the time of an incident all matter, because an assessor may ask which plan governed a particular event. Confirm that the plan links to the reporting chain card above rather than repeating a separate contact list.

Notification and submission records

For each report sent to an internal official or external authority, keep a copy of the notice, the time it was sent, the recipient, the sender and any acknowledgment. Where the DFARS 252.204-7012 clause applies, the 72-hour window runs from discovery, so the discovery time must be recorded alongside the submission time. Retain the affected system images for at least 90 days after the report, as the clause requires.

Evidence in final form

A requirement counts as MET only when the evidence is in final form, so drafts of the plan, unsigned procedures and unexported reports do not count. Store finished versions with dates, check them at least once between assessments, and replace any artifact that the organization no longer uses. Ask your assessor early which format they expect for the log and whether screenshots or exports are acceptable.

What meeting IR.L2-3.6.2 costs in money and effort

This table lists each cost component of IR.L2-3.6.2, who is paid for it, whether it is one-time or recurring, and what drives it up. Use it to structure a quote request and to see where self-hosted open-source tools reduce license spend, while noting that effort and a DoD medium assurance certificate remain costs either way.

Cost component	Who is paid or who bears it	One-time or recurring	What drives the cost
Case or ticketing licenses	Software vendor, or no license fee for open-source tools such as DFIR-IRIS, GLPI or Zammad	Recurring for commercial licenses, usually none for self-hosted open source	Number of users, reporting channels and whether hosting is in your own environment
Engineering time to configure workflows	Internal staff or an implementation partner under a written scope	One-time, with periodic updates when contacts or reporting paths change	Number of intake sources (SIEM, EDR, email), escalation rules and reporting templates
DoD medium assurance certificate	Certificate authority, paid by the contractor	Recurring, renewed on the certificate's validity period	Number of people authorized to submit reports to DoD through dibnet.dod.mil
Staff time for reporting drills and record upkeep	Internal staff time, not an external invoice	Recurring	Team size, staff turnover, and how many drills and tabletop exercises you run each year
72-hour reporting readiness	Internal legal, security and management staff	Recurring, activated per incident	How quickly discovery is recorded, how fast the report package is drafted, and who must approve it
Preservation of images for 90 days	Storage and infrastructure owner, internal or cloud provider	Recurring for the retention period after each reportable incident	Volume and size of affected system images, and storage tier
External review of records and procedures	Independent consultant or implementation partner, under a fixed scope	One-time for initial review, then recurring before each assessment	Number of systems in scope, existing documentation quality, and reporting chain complexity
Assessor fees if certification applies	Authorized or accredited C3PAO, paid by the contractor	One-time per assessment cycle	Scope size and whether Level 2 certification is required by a contract. Certification requirements are currently suspended, so confirm with the contracting officer

Who owns incident reporting, who can help, and what the assessor checks

Your organization owns the requirement. Only your people can decide what counts as an incident, name the officials who receive reports, and file the actual reports with the authorities that apply to your contracts. Assessors test whether your staff follow the process, so a process that exists only in a consultant's document will not satisfy the requirement.

Designated officials: Name the internal roles that must receive incident reports, such as the security lead, the Affirming Official and legal counsel, and record the names in the incident response plan.
Reporting chain: Define who notifies whom, in what order and within what time, including how the 72-hour window in DFARS 252.204-7012(c) starts when an incident is discovered.
Incident records: Your staff open, update and close each record, and they keep it complete enough to show what happened and who was told.
External reporting: Your authorized staff submit reports to DIBNet at dibnet.dod.mil using a DoD-approved medium assurance certificate, which the organization must obtain and protect.

Confirm with your contracts and counsel which external authorities apply to your organization before you finalize the chain.

Which open-source tools can hold incident records

Which open-source tool keeps incident case records with an audit trail?

DFIR-IRIS is the open-source option most aligned with incident case records. It keeps each case as one record that holds assets, indicators of compromise, tasks and evidence, and it records changes in a full audit trail. It can triage alerts from SIEM, EDR and REST sources into cases, build a consolidated investigation timeline and generate reports from case data. Its license is LGPL-3.0-or-later. Confirm with your own team that its fields, approval steps and retention settings match the internal and external reporting roles defined in your incident response plan before you rely on it.

Does DFIR-IRIS prove chain of custody for incident evidence?

DFIR-IRIS logs evidence with SHA-256 verification and chain of custody tracking, which gives assessors a documented way to show that evidence has not been altered since collection. Those features support the evidence side of IR.L2-3.6.2 but do not replace your procedures. Your organization still defines who collects evidence, how it is stored and who may access it. Confirm the exact custody and hashing workflow in the current documentation and test it against a sample case before an assessment.

What does GLPI Assistance produce for incident tickets?

GLPI's Assistance module lets users create, follow and process tickets, problems and changes following ITIL practices. It provides planning views, statistics, recurrent ticket handling and a Kanban view, so teams can see incident volume and status over time. This gives you a dated ticket history that can show when an incident was logged, who handled it and how it moved through the queue. Its license is GPL-3.0-or-later. Confirm that its ticket categories and escalation paths can carry the reporting fields and designated official routing your procedure requires.

How does GLPI differ from a case tool for incident records?

GLPI is built around service management, so its strength is ticket workflow, asset context and ITIL-style process records. A dedicated case tool such as DFIR-IRIS is built around investigation, with evidence and indicators tied to a case. Many teams use a service desk for intake and status and a case tool for forensic detail. Whether one tool is enough depends on how deep your investigations go and who must see the records. Confirm which record types your assessor will expect to see and whether the two systems need to be linked.

Can Zammad handle incident reporting through a helpdesk ticket flow?

Zammad is a web-based helpdesk that brings customer communication from email, chat, telephone and social media into one ticket system. For incident reporting, it can serve as the intake point where staff, users or external parties report a suspected incident, and where each message stays attached to one ticket. This creates a communication record that shows who reported what and when. Its license is AGPL-3.0-only. Confirm how it routes tickets to designated officials, how it handles controlled information in messages and whether it keeps the records in the form your reporting chain needs.

Which tool should a CUI environment use for incident reporting records?

No single tool is named in the requirement, so the choice follows from your process. Consider these questions before you select a platform:

Does the tool keep a complete audit trail of changes to each record?
Can it route reports to internal officials and to the external reporting path, including the 72-hour DoD reporting duty in DFARS 252.204-7012?
Does it store records inside the CUI boundary and meet your access control and encryption requirements?
Can you export records and reports for an assessor interview or evidence review?

DFIR-IRIS, GLPI and Zammad each cover part of this list. Confirm the answers with the vendor documentation and in a test environment.

Who owns the incident records once an open-source tool is in place?

Your organization owns the incident records, the reporting decisions and the people who make them. An implementation partner such as DeployOpen can plan, install, configure, harden, back up and document a self-hosted platform inside your own infrastructure, and it can prepare the evidence your assessor will review. DeployOpen does not issue audit reports or certifications, and an independent assessor makes the determination. Scope, deliverables and timelines for this work are agreed in writing before it begins, and a quote follows from that written scope.

Where incident reporting usually fails the assessment

Most incident reporting failures are not failures to report at all. They are gaps in the records, contacts and decision paths that let an assessor confirm that tracking and reporting actually happen. Each card below names one gap, why it matters for IR.L2-3.6.2 Incident reporting, and the fix that closes it.

No named external reporting contact

Many organizations can name an internal incident lead but cannot name the person who files reports with DoD or other external authorities. IR.L2-3.6.2 expects you to identify both the authorities and the officials who must receive reports. Maintain a named primary and alternate for each external channel, including who holds the DoD-approved medium assurance certificate needed for DIBNet reporting, and confirm that contact details are current.

Reports sent but not recorded

A report that leaves by email and never enters the incident record is hard to prove during an assessment. Assessors look for incident records that show what was reported, to whom, and when. Require that every outgoing notification is logged in the same case as the incident, with a copy of the submitted report and the submission confirmation attached.

No discovery timestamps

Without a recorded time of discovery, you cannot show when the reporting clock started. DFARS 252.204-7012(c) sets a 72-hour window measured from discovery of a cyber incident affecting covered defense information. Record the time of first detection, the time the incident was confirmed, and the time it was classified as reportable, each in UTC, so the timeline can be reconstructed.

Records split across email and chat

When the incident narrative lives in mailboxes, chat threads and personal notes, the assessor cannot see a single account of decisions and notifications. Interviews with people who should have reported an incident often expose this quickly. Move coordination into one ticketing or case system, and treat chat and email as sources that get pasted into the record, not as the record itself.

Drafts presented as final

Reporting templates, runbooks and incident write-ups that remain in draft form at assessment time weaken the evidence. A requirement is met only when the evidence is in final form, so an unapproved reporting procedure or an unsigned incident summary may not count. Put version control and approval dates on the reporting procedure, and close each incident record with a reviewed final version before the assessment.

CUI incidents not linked to the DFARS path

Many teams run a general incident process but do not connect it to the separate DoD reporting duty for incidents involving covered defense information. The result is that a CUI-affecting event may be handled as routine and reported late. Add a decision step to the incident workflow that asks whether covered defense information was affected, routes qualifying events to the DFARS reporting path, and preserves images of affected systems for at least 90 days after the report.

Common questions about IR.L2-3.6.2 incident reporting

How much does it cost to meet IR.L2-3.6.2 incident reporting?

The cost is mostly labor and tooling, and no supplied source gives a price for it, so ask for a written scope before budgeting. The organization pays for its own incident response plan, reporting chain, staff time to run reports, and any ticketing or case tools it adopts. An implementation partner is paid for the work it scopes, such as configuring the ticketing workflow, writing reporting procedures and preparing evidence. Open-source tools like GLPI or DFIR-IRIS can lower license spend, but they still need setup and upkeep. Costs rise with the number of systems in scope, the number of reporting authorities, and how many people must be trained. Costs fall when the organization already keeps tickets and incident records.

How long does it take to set up incident reporting for CMMC?

Setup time depends on what already exists, so no fixed duration applies. The main drivers are whether a written incident response plan and named reporting contacts exist, how many systems and users fall within the CUI boundary, whether incident records are kept in one place, and how quickly the organization can agree on who must be notified. An organization with a working helpdesk and a documented escalation path usually has less to build than one starting from email threads. Ask any partner to break the schedule into discovery, configuration, procedure writing, and evidence collection, and to name which steps depend on your staff's availability.

Can our own team meet IR.L2-3.6.2 without outside help?

Yes, an organization can meet IR.L2-3.6.2 with its own staff, provided it can show the evidence an assessor would test. The requirement needs incident records, documented reporting procedures, identified internal officials and external authorities, and proof that reports reach them. Teams that lack experience with DFARS reporting, evidence handling, or ticket configuration often bring in a partner to prepare systems and documents. Whichever route you choose, the organization owns its controls. Independent assessors, not consultants, judge whether the requirement is met.

Can IR.L2-3.6.2 be placed on a POA&M?

No. IR.L2-3.6.2 is a 5-point requirement under the CMMC Scoring Methodology, and 32 CFR 170.21(a)(2) does not allow requirements worth more than 1 point on a plan of action and milestones. It must be MET to reach Conditional or Final Level 2 status. Plan the incident records, reporting chain, and notification procedures before the assessment, because a gap here cannot be deferred. Confirm current status with your contracting officer or sponsor, since the DoW suspended CMMC Phase II in July 2026.

How does IR.L2-3.6.2 relate to the 72-hour DFARS reporting duty?

IR.L2-3.6.2 covers your internal tracking and reporting chain, while DFARS 252.204-7012(c) sets a separate external duty. Under that clause, a contractor must report cyber incidents affecting covered defense information to DoD at dibnet.dod.mil within 72 hours of discovery, using a DoD-approved medium assurance certificate. Paragraph (e) requires preserving images of affected systems for at least 90 days after the report. A single incident record should therefore capture discovery time, the people notified, the DoD report reference, and the preserved images. Your internal reporting procedure should make the 72-hour clock visible to the people who can start it.

What should we ask a partner for in a fixed-scope quote?

Ask for a written scope that names every deliverable and who owns each one. Useful items include:

A list of systems, tools, and data in scope, including the CUI boundary
Configuration of the ticketing or case tool, such as GLPI or DFIR-IRIS, with the record fields that support 3.6.2
A reporting chain document naming internal officials and external authorities, with contact roles
Procedures for the 72-hour DoD report, the medium assurance certificate, and image preservation
Training sessions and who attends them
Evidence package contents and format, and what the partner will not prepare
Acceptance criteria, timeline milestones, and the change process if scope shifts

Confirm that the partner prepares evidence but does not issue assessment results.

Which open-source tools can keep IR.L2-3.6.2 incident records?

GLPI and Zammad can hold incident tickets, and DFIR-IRIS can manage investigation cases. GLPI's Assistance module supports tickets and problems following ITIL practices, with statistics and a Kanban view. Zammad brings email, chat, and telephone contacts into one ticket system. DFIR-IRIS keeps each case as one record with assets, indicators, tasks, evidence, and a full audit trail. Choose the tool that matches how your team already works. Each still needs configuration, access control, backup, and documented procedures before it produces assessor-ready evidence. Confirm the license and feature details against each project's documentation before you rely on them.

How DeployOpen implements incident reporting for CMMC

DeployOpen plans, implements and documents the self-hosted open-source systems that hold incident records, reporting chains and evidence for IR.L2-3.6.2 Incident reporting, inside your own infrastructure. The organization owns its reporting obligations and decisions, and only an independent assessor can judge whether the requirement is MET.

How we scope

Written scope lists which incident records, ticket queues and case systems are in the boundary for IR.L2-3.6.2.
Scope names the designated internal officials and external authorities that the reporting chain must reach.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before any work starts.

How we build

We deploy self-hosted ticketing and case tools, such as GLPI and DFIR-IRIS, within your cloud accounts or data centers.
We configure incident categories, required fields and escalation paths that record when each report was made and to whom.
We test that tracked incidents produce the audit trail, timeline and report output an assessor would ask to see.

How we hand over

You receive documentation of the tracking workflow, reporting chain, roles and the evidence each step produces.
Handover covers the DFARS 252.204-7012 reporting steps, including the 72-hour window and the 90-day image preservation duty, so your team can run them.
Assessment-ready evidence is delivered for your assessor to review, and DeployOpen does not issue any report or certificate.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
We can review incident records and reporting procedures on a schedule agreed in your written scope.
Retainer work is scoped in writing, so changes to systems or reporting contacts are documented as they happen.