What Counts as a Reportable Phishing Incident? (IR.L2-3.6.2)

A cmmc reportable phishing incident is a phishing event that meets your organization’s documented incident criteria and therefore must be tracked, documented, and reported to the internal officials and external authorities named in your incident response process. A suspicious email that was deleted without being opened may be recorded as a security event, while an email that steals credentials, delivers malware, reaches Controlled Unclassified Information (CUI), or causes a user to act normally requires incident handling and notification. Under CMMC 2.0 Level 2 practice IR.L2-3.6.2, compliance means being able to show what happened, what responders did, who was notified, when they were notified, and why.

What does IR.L2-3.6.2 require?

NIST SP 800-171 Rev. 2 and CMMC 2.0 Level 2 practice IR.L2-3.6.2 state:

Track, document, and report incidents to designated officials and/or authorities both internal and external to the organization.

For a sole IT administrator, that sentence can sound broader than it is. It does not mean every junk email must become a formal breach report. It does mean you need a repeatable way to decide whether an event is an incident, retain a record of the decision and response, and notify the people or organizations your policy identifies.

• “Track” means assigning the incident an identifier and recording its status from intake through closure. A ticket in Jira Service Management, Freshservice, HaloITSM, or a controlled incident log can work if it shows ownership, dates, actions, and disposition.
• “Document” means preserving the facts and response record: the original phishing message, affected accounts or devices, indicators of compromise, containment actions, investigation results, recovery steps, and lessons learned.
• “Report” means notifying named recipients, not merely leaving a ticket in an IT queue. Internal recipients might include the company president, security lead, contracts manager, legal counsel, and the affected business-unit owner.
• “Designated officials” are people inside the organization identified in advance by role or name. “Management” is usually too vague for an assessor to accept without a defined notification path.
• “Authorities” are external entities that must be contacted when applicable, such as a contracting officer, prime contractor, cyber insurance carrier, law enforcement, a state regulator, or another authority required by contract, law, or incident type.

The important distinction is between an event and an incident. A blocked phishing email is an event. A user entering credentials into a fake Microsoft 365 page, approving a malicious MFA prompt, opening a malware attachment, or forwarding CUI to an unauthorized party may be an incident because it creates a credible risk to systems, accounts, or protected information.

What makes a cmmc reportable phishing incident in practice?

Your incident response policy should define the thresholds that turn phishing activity into a reportable incident. Those thresholds should fit your environment, contractual obligations, and the types of information you handle. An assessor is not looking for a universal list of phishing scenarios; they are looking for evidence that your organization applies its own documented criteria consistently.

For most small contractors, phishing should be treated as an incident when one or more of the following occurs:

• A user submits a password, MFA code, recovery code, banking detail, or other credential to a fraudulent site.
• A suspicious attachment, link, macro, executable, or QR code is opened or executed.
• An attacker successfully accesses an email account, cloud application, endpoint, VPN, or administrative account.
• The event involves CUI, personally identifiable information, payment information, export-controlled data, or sensitive contract information.
• The email causes unauthorized payment activity, invoice changes, wire-transfer instructions, payroll changes, or vendor impersonation.
• Malware, persistence mechanisms, suspicious inbox rules, data exfiltration, or lateral movement are discovered.
• The same campaign targets multiple users and creates a credible risk that one or more accounts were compromised.

A message that Microsoft Defender for Office 365 quarantines before delivery, with no user interaction and no evidence of compromise, may be tracked as a security event and closed under a documented “no incident” determination. Keep enough evidence to support that decision, such as the Defender alert, message headers, quarantine status, and analyst notes. The requirement is not to inflate routine spam into incidents; it is to show that someone evaluated it under an established process.

Who must follow this requirement, and when does reporting start?

IR.L2-3.6.2 applies to organizations seeking or maintaining CMMC Level 2 compliance for systems that process, store, or transmit CUI, along with the people responsible for those systems. In a small company, the same person may be the Microsoft 365 administrator, endpoint administrator, incident coordinator, and evidence custodian. That is acceptable if responsibilities and backup coverage are documented.

Reporting starts when the organization identifies or reasonably suspects an incident under its defined criteria. You do not need to wait for a complete forensic conclusion before notifying the internal decision-makers who need to authorize containment, customer communication, legal review, or business continuity actions. Your process should distinguish between an initial notification, which may contain known facts and uncertainties, and a final incident report, which documents root cause, scope, impact, and corrective actions.

Do not invent external reporting obligations. Instead, maintain a current list of applicable contracts, insurance conditions, state breach-notification requirements, prime contractor instructions, and other obligations. Your incident response plan should state who determines whether an external notification is required—often the company president with contracts and legal input—and who actually sends it.

What evidence would an assessor accept as compliant?

For IR.L2-3.6.2, an assessor generally wants to see both the documented process and proof that the process has been used or tested. The following examples are concrete, realistic evidence packages.

A credential-harvesting email is reported and contained

A 27-person engineering firm receives a fake Microsoft 365 document-sharing email. An engineer enters their password on the linked site, then reports the mistake through a monitored security mailbox. The sole IT admin opens incident INC-2026-014 in Freshservice, resets the password, revokes Entra ID sessions, reviews Entra sign-in logs, checks for malicious mailbox rules, and documents that no suspicious login succeeded.

The ticket includes the original message, URL, user statement, screenshots of the Entra ID sign-in review, timestamps for session revocation, and an email to the company president. The incident is closed as “credential exposure contained; no confirmed account access.” This is a reportable phishing incident because the user disclosed credentials, even though the response prevented a confirmed compromise.

A malicious attachment reaches a CUI workstation

A 42-person SBIR/STTR contractor uses Microsoft 365, Intune-managed Windows laptops, and a segmented file server containing project CUI. A finance employee opens an invoice attachment that launches a suspicious PowerShell process. Microsoft Defender for Endpoint isolates the laptop automatically, and the IT admin preserves the alert timeline and starts an incident record.

The administrator notifies the operations director and contracts manager, determines whether the workstation had access to the CUI file share, and engages the company’s managed detection and response provider for triage. The incident log records the containment decision, Defender device isolation time, forensic findings, affected contracts, notifications, and final recovery approval. If contractual terms require notification to a prime contractor or government contact, the record also identifies who sent that notification and when.

A blocked campaign is documented as an event, not escalated as an incident

Microsoft Defender for Office 365 quarantines 18 identical QR-code phishing messages before delivery. No users receive, open, or interact with the messages. The IT admin records the campaign in the monthly security event log, retains the Defender quarantine report, and notes that no incident ticket was opened because there was no user exposure or compromise indicator.

This can be compliant when the organization’s criteria clearly permit that disposition. The key is that the decision is traceable. If a later investigation shows one message bypassed quarantine and reached a user, the earlier log gives responders a starting point for reevaluating the event.

A vendor-payment phishing attempt requires business notification

An accounts-payable employee receives an email that appears to come from a subcontractor and requests updated ACH payment details. The employee does not change the payment information, but forwards the message to IT. The IT admin confirms that the subcontractor’s mailbox was spoofed and that the attacker had impersonated a real vendor relationship.

The event is logged, the sender domain is blocked, and finance leadership is notified because the attempt affects payment controls and vendor communications. Even without malware or stolen credentials, the documented notification demonstrates that the organization involved the internal official responsible for the business decision.

What should be in a phishing incident record?

A single central hub is easier to defend during an audit than scattered emails, chat messages, and personal notes. Your hub can be an incident-management platform or a protected ticket queue, but it should capture the response lifecycle: identification, containment, eradication, recovery, notification, and closure.

• Incident ID, title, severity, owner, detection date, and closure date.
• How the event was reported and who reported it.
• Phishing artifacts: sender, recipient, subject, URLs, attachment hashes, message headers, and screenshots where appropriate.
• Affected users, devices, applications, accounts, contracts, and information types, including whether CUI may have been involved.
• Containment and recovery actions, such as password resets, MFA re-registration, device isolation, mailbox-rule removal, blocking actions, and endpoint scans.
• Internal and external recipients notified, notification times, the person responsible for each communication, and confirmation where available.
• Final determination, impact assessment, root cause, follow-up actions, and management approval to close.

FAQ

Is every phishing email reportable under CMMC?

No. Every phishing report should be evaluated, but not every unsolicited or blocked message is necessarily an incident. Your documented criteria should distinguish routine spam and blocked events from phishing activity that creates a credible risk to accounts, systems, CUI, finances, or operations.

Do we have to report phishing incidents to CISA?

Not automatically under IR.L2-3.6.2. The practice requires reporting to designated internal officials and applicable external authorities. Whether CISA, law enforcement, a prime contractor, a customer, or another party must be notified depends on your contracts, applicable law, insurance requirements, and organizational policy.

What is the difference between a security event and a phishing incident?

A security event is any observable occurrence, such as a quarantined email or blocked URL. A phishing incident is an event that meets your escalation criteria because it has caused, or could reasonably cause, harm requiring containment, investigation, recovery, or formal notification.

Can a sole IT administrator be the incident coordinator for CMMC?

Yes, provided the role is formally assigned and your process identifies who receives escalations if you are unavailable. Document a backup contact—such as the president, operations manager, or managed security provider—and make sure both people know the notification procedure.

Next step: Before your external audit, create or update a one-page phishing incident decision matrix and test it against three real or simulated incidents in your ticketing system.