A phishing risk policy template for employees should require personnel to recognize suspicious messages, avoid unsafe actions, report suspected phishing promptly, and complete recurring security awareness activities. For CMMC 2.0 Level 2 and NIST SP 800-171 Rev. 2 practice AT.L2-3.2.1, the policy must also make managers, system administrators, and users aware of the security risks tied to their activities and the policies, standards, and procedures that protect organizational systems.
Why does policy come before phishing tooling?
Email filtering, multi-factor authentication, and phishing-report buttons reduce exposure, but they do not establish employee responsibilities or create evidence that the organization has communicated them. A written policy answers the questions a compliance officer must be able to prove during an assessment: who is covered, what employees must do, what happens when a message is suspicious, which procedures apply, how awareness is communicated, and who retains the records.
AT.L2-3.2.1 is an awareness requirement, not merely an email-security configuration requirement. The organization must identify security risks associated with organizational activities involving CUI and make relevant personnel aware of the related security policies, standards, and procedures. A well-written phishing policy connects the human action—opening email, approving a request, accessing a cloud file, or entering credentials—to the applicable reporting and incident-response process.
For example, a 430-person component manufacturer using Microsoft 365, Epicor Kinetic ERP, SharePoint Online, and a supplier portal may receive messages impersonating a procurement manager requesting changes to bank-account details. The technical controls may quarantine some messages, but the policy should tell accounts-payable staff to verify changes through an independently obtained phone number, report the message through Microsoft’s Report Message add-in, and avoid replying to the suspected email.
What should a phishing risk policy template for employees include?
The following policy body is designed for customization. Replace every bracketed field before approval, and align referenced procedures with the documents your organization actually maintains.
Policy title, purpose, and scope
Policy: [ORGANIZATION NAME] Phishing Risk Awareness and Reporting Policy
Purpose: [ORGANIZATION NAME] establishes this policy to reduce the risk that phishing, business email compromise, malicious links, malicious attachments, credential theft, or fraudulent requests will compromise organizational systems, Federal Contract Information, Controlled Unclassified Information, or other sensitive business information.
Scope: This policy applies to all [EMPLOYEES, TEMPORARY WORKERS, CONTRACTORS, INTERNS, CONSULTANTS, AND SYSTEM ADMINISTRATORS] who use [ORGANIZATION NAME] systems, accounts, email addresses, mobile devices, cloud services, or business information. Managers are responsible for communicating this policy to personnel under their supervision.
Rationale: Scope should include every system user, not only full-time employees. Assessors commonly look for awareness coverage that includes administrators and contractors with access to organizational systems.
What phishing risks must personnel recognize?
Policy statement: Personnel must remain alert to phishing risks associated with their work activities. Examples include messages that impersonate executives, customers, suppliers, IT support personnel, government agencies, financial institutions, or collaboration platforms; unexpected password-reset requests; invoice and payment-change requests; shared-file notifications; QR codes; malicious attachments; links to credential-harvesting websites; and requests to bypass established approval procedures.
Personnel must treat the following as indicators requiring verification or reporting: mismatched sender addresses, urgent or unusual requests, changes to payment instructions, unexpected multi-factor authentication prompts, requests for credentials or one-time codes, messages sent outside normal business channels, and attachments or links not expected as part of assigned work.
Rationale: This clause identifies risks connected to ordinary work. It supports the first key objective of AT.L2-3.2.1 by connecting awareness content to activities that can expose CUI or organizational systems.
What actions are employees required to take?
Required actions:
- Personnel must not enter [ORGANIZATION NAME] credentials, multi-factor authentication codes, or recovery codes into a website reached through an unverified email, text message, QR code, or chat message.
- Personnel must not open unexpected attachments, enable macros, install software, approve unexpected multi-factor prompts, or provide sensitive information in response to an unverified request.
- Personnel receiving a request to change payment, banking, shipping, payroll, supplier, or account-access information must follow [PROCEDURE NAME AND DOCUMENT ID] and complete out-of-band verification.
- Personnel must report suspected phishing immediately using [REPORTING METHOD, SUCH AS MICROSOFT REPORT MESSAGE ADD-IN], by forwarding the message as an attachment to [SECURITY EMAIL ADDRESS], or by calling [SERVICE DESK NUMBER].
- Personnel who clicked a suspicious link, opened an attachment, entered credentials, approved an unexpected prompt, or sent information in error must report the event immediately and must not delete relevant messages or browser history unless directed by [SECURITY TEAM OR INCIDENT RESPONSE LEAD].
Rationale: “Immediately” should be retained unless your incident-response procedure defines a more precise timeframe. A policy that says only “be cautious” is difficult to enforce and does not reliably direct users to a reportable action.
What awareness activities are required under this policy?
Awareness and communication: [ORGANIZATION NAME] will provide phishing and general security awareness information to covered personnel at onboarding and at least [ANNUALLY]. Awareness communications will include phishing examples, reporting instructions, applicable security policies, and reminders about safeguarding [CUI, FCI, CUSTOMER DATA, OR OTHER SENSITIVE INFORMATION].
[ORGANIZATION NAME] may use simulated phishing messages, email advisories, posters, team discussions, learning modules, and security announcements to reinforce expected behavior. Simulated phishing results will be used to identify awareness needs and provide corrective education. Repeated unsafe behavior may be addressed under [HR POLICY NAME] and [INFORMATION SECURITY POLICY NAME].
Rationale: NIST SP 800-171 Rev. 2 permits multiple awareness techniques. This language gives the organization flexibility without confusing general awareness under AT.L2-3.2.1 with role-based training under AT.L2-3.2.2.
Which policies and procedures must users know?
Applicable documents: Personnel must comply with this policy and the following documents, as applicable: [ACCEPTABLE USE POLICY], [ACCESS CONTROL POLICY], [INCIDENT RESPONSE PLAN], [DATA CLASSIFICATION AND HANDLING STANDARD], [MOBILE DEVICE POLICY], [REMOTE ACCESS PROCEDURE], [VENDOR PAYMENT CHANGE PROCEDURE], and [CUI HANDLING PROCEDURE]. Current versions are available at [POLICY REPOSITORY LOCATION].
Rationale: Naming the related documents demonstrates that users are being made aware of applicable policies, standards, and procedures rather than receiving generic anti-phishing advice.
Who has management and administrative responsibilities?
Managers: Managers must ensure new personnel complete required awareness activities within [TIMEFRAME], communicate relevant advisories to their teams, and escalate suspected phishing trends or repeated policy violations to [SECURITY CONTACT].
System administrators: System administrators must report suspected phishing, maintain awareness of threats affecting privileged accounts, and follow [PRIVILEGED ACCESS PROCEDURE], [INCIDENT RESPONSE PLAN], and [LOGGING STANDARD] when investigating or responding to suspicious activity.
Information Security: [INFORMATION SECURITY FUNCTION] will maintain awareness content, coordinate phishing simulations where used, issue advisories, track completion, retain records, and review reported phishing events for lessons learned.
Which attachments and exhibits should support the policy?
The policy should not attempt to contain every operational step. Attachments provide the repeatable details employees and auditors need, while allowing the policy itself to remain stable.
| Attachment or exhibit | Owner | Operational content and realistic setting | Evidence retained |
|---|---|---|---|
| Phishing Reporting Quick Guide | Security Operations | Microsoft 365 Report Message add-in configured to submit messages to Microsoft Defender for Office 365 and security@[DOMAIN].com | Published guide version and employee communications |
| Phishing Simulation Standard | Security Awareness Manager | KnowBe4 campaigns run quarterly; landing pages collect no passwords; users who click receive immediate training | Campaign reports, completion records, exception approvals |
| Payment-Change Verification Procedure | Finance Controller | Supplier banking changes require callback verification using a number from the approved vendor master record | Verification log and approved change record |
| Incident Response Playbook | Incident Response Lead | Credential-phishing reports trigger Entra ID session revocation, password reset, MFA review, and mailbox-rule inspection | Ticket, investigation notes, containment actions |
In the aircraft-parts example, the payment-change exhibit is especially important because engineering drawings and purchase orders may move between procurement staff, approved suppliers, and program managers. A convincing supplier impersonation email can become both a financial-loss event and a pathway to CUI exposure if it redirects users to a fraudulent document-sharing site.
How should approval and review cadence be documented?
The compliance officer should route the policy for approval through the same governance process used for other security policies. At minimum, obtain approval from [EXECUTIVE RESPONSIBLE FOR SECURITY], [HR LEADER], [IT LEADER], and [LEGAL OR COMPLIANCE OWNER] where those functions exist. Record the policy owner, effective date, version number, approver names, and repository location in the document-control record.
Review the phishing employee policy at least annually and after a material phishing incident, significant email-platform change, merger, major workforce change, or revision to contract requirements. A practical cadence is a formal annual review in [MONTH], quarterly validation that reporting instructions still work, and an after-action review following any confirmed credential-compromise event.
For AT.L2-3.2.1 evidence, retain the approved policy, revision history, distribution notice, onboarding and annual awareness completion records, simulation summaries, advisories, and examples showing that employees can access the referenced procedures. Retention should follow [RECORDS RETENTION SCHEDULE], but [THREE YEARS] is a common minimum operational period for maintaining a defensible assessment trail.
What common edits are needed by industry?
| Environment | Policy edit to consider | Reason |
|---|---|---|
| Manufacturing | Add procedures for supplier invoices, shipping changes, quality-document sharing, and shared production-floor terminals. | Attackers often impersonate suppliers or exploit accounts used across shifts. |
| Healthcare | Reference patient-data handling, clinical urgency verification, and approved messaging channels. | Users may receive phishing messages that exploit urgent care or records-access requests. |
| Financial services | Expand callback requirements for wire transfers, account changes, and executive payment requests. | Business email compromise frequently targets payment workflows. |
| Professional services | Address client-file sharing, e-signature notices, and external collaboration invitations. | Client-facing staff routinely receive legitimate-looking links from outside domains. |
Before issuing this phishing awareness policy template, have the policy owner validate every bracketed field against actual reporting channels, training practices, and incident-response procedures, then collect formal approval and publish the final version in the controlled policy repository.
