# What Is an Anti-Phishing Program? Components and Operating Model

> Build an anti-phishing program with clear owners, layered controls, safe reporting, incident handoffs, useful metrics, and a review cadence.

An anti-phishing program is an operating system for reducing phishing risk across people, process, and technology. It assigns owners, combines preventive and detective controls, teaches people how to report suspicious messages, routes reports into triage and incident response, and measures whether the system improves. It is not a single software package, a yearly awareness module, or a stream of simulations judged only by click rate.

## Quick takeaways

- Give one accountable owner authority to coordinate security, IT, help desk, communications, legal, and business leaders.
- Combine mail, identity, browser, endpoint, and sender-domain controls with awareness and authorized exercises.
- Make suspicious-message reporting easy, safe, and connected to a documented triage and escalation path.
- Measure reporting speed, confirmed incidents, control coverage, and response outcomes alongside simulation results.
- Review the program on a fixed cadence and after material incidents, technology changes, and convincing new attack patterns.

## What belongs in an anti-phishing program?

The program starts with governance. Name the accountable owner, the business units and communication channels in scope, the decisions that require approval, and the teams that receive a suspected incident. A short charter is more useful than a long policy that leaves ownership unclear.

The [U.S. Department of Justice anti-phishing program description](https://www.justice.gov/jmd/page/file/1368721/dl?inline=) groups the work into a formal operating model, testing objectives and frequency, standard procedures, campaigns, dashboards, and reporting. That is a useful skeleton, but an organization still has to adapt it to its risk, workforce, technology, and legal obligations.

Control coverage should be layered. Current [CISA, NSA, FBI, and MS-ISAC phishing guidance](https://www.cisa.gov/sites/default/files/2025-03/Phishing%20Guidance%20-%20Stopping%20the%20Attack%20Cycle%20at%20Phase%20One%20508.pdf) combines training with technical precautions. In practice, the control map may include mail filtering, account protection, safe link and attachment handling, endpoint defenses, domain authentication, browser protections, and an out-of-band process for sensitive requests.

Training and simulations are one component. Use the separate [phishing simulation guide](/learning/why-run-regular-phishing-simulations) for campaign design and authorization. Use the [anti-phishing software comparison](/learning/anti-phishing-software) when the unresolved task is selecting a product. Neither page replaces the program owner, reporting route, incident handoff, or review loop.

![A closed anti-phishing operating loop connecting governance, prevention, reporting, response, and verified improvement.](/images/editorial/anti-phishing-program/anti-phishing-program-operating-loop.svg "1100x620")

*Source: Original Palisade operating-model diagram based on the [DOJ Anti-Phishing Program Support description](https://www.justice.gov/jmd/page/file/1368721/dl?inline=) and [NIST SP 800-61 Revision 3](https://csrc.nist.gov/pubs/sp/800/61/r3/final). [Open the full-size diagram](/images/editorial/anti-phishing-program/anti-phishing-program-operating-loop.svg).*

## How should ownership and handoffs be assigned?

Give each control and decision one named owner even when several teams perform the work. The mail team may operate filtering, identity may protect accounts, the help desk may receive reports, and incident response may contain confirmed attacks. The program owner is responsible for making those parts work as one system and for escalating risk when a control owner cannot close a gap.

Define handoffs with evidence and time expectations. [NIST SP 800-61 Revision 3](https://csrc.nist.gov/pubs/sp/800/61/r3/final) connects detection, response, recovery, and improvement with cybersecurity risk management. A user report should enter a monitored queue with the original message attached. Triage should record its classification and either close it with a reason or pass it to an incident owner with the relevant headers, links, attachments, recipients, and suspected exposure. The incident owner should return root cause, affected scope, and corrective actions to the program, not simply mark the ticket resolved.

Include the business owners of high-risk processes. Finance, payroll, procurement, customer support, and account recovery teams can impose independent verification or dual approval when an email requests a sensitive change. Technical controls cannot decide whether a new bank account or urgent data request is legitimate.

Test the handoffs with authorized scenarios that exercise reporting, triage, escalation, containment, and recovery. A simulation that records only clicks does not show whether the operating model works after someone asks for help.

## How should the program operate?

The reporting path should be easy to find and safe to use. CISA recommends clear reporting policy, regular training, realistic testing, trusted verification channels, and a culture where people can report mistakes quickly without fear of blame in its [cybersecurity essentials guidance](https://www.cisa.gov/resources-tools/resources/four-cybersecurity-essentials-sltts). A report button that feeds an unmonitored queue is not a functioning control.

Define what happens after a report arrives. The triage team needs criteria for closing harmless messages, escalating suspected credential theft or malware, searching for related messages, protecting affected accounts, preserving evidence, and notifying incident response. [NIST SP 800-61 Revision 3](https://csrc.nist.gov/pubs/sp/800/61/r3/final) treats incident response as part of wider cybersecurity risk management, which supports connecting phishing reports to preparation, detection, response, recovery, and improvement.

This matrix is a starting point, not a universal policy:

```yaml
anti_phishing_program:
  governance:
    owner: "security program lead"
    cadence: "quarterly and after material incidents"
    evidence: "charter, risk register, decision log"
    escalation: "executive risk owner"
  preventive_controls:
    owner: "email, identity, endpoint, and DNS teams"
    cadence: "continuous monitoring; scheduled control review"
    evidence: "effective configuration, exceptions, test results"
    escalation: "control owner and change authority"
  awareness_and_exercises:
    owner: "security awareness lead"
    cadence: "risk-based and formally authorized"
    evidence: "audience, scenario difficulty, click and report results"
    escalation: "program owner, HR, legal, or privacy as required"
  reporting_and_triage:
    owner: "help desk or security operations"
    cadence: "continuous"
    evidence: "queue age, classification, disposition, related-message search"
    escalation: "incident response"
  improvement:
    owner: "program owner and control owners"
    cadence: "monthly trend review; quarterly program review"
    evidence: "root causes, actions, owners, due dates, retest results"
    escalation: "risk committee"
```

Keep the workflow proportional. A small organization may combine roles, but it should still know who owns the decision, where reports go, what triggers escalation, and how changes are verified.

## What should happen in the first 90 days?

Start by documenting the current state. Identify the owner, reporting channels, mail and identity platforms, existing policies, known exceptions, simulation practices, and incident-response contacts. Record where the evidence is missing rather than assuming a control works.

Next, close the most dangerous workflow gaps. Make reporting easy, confirm the queue is monitored, publish a triage procedure, and test the handoff with a harmless authorized scenario. Review high-risk payment, credential, and account-recovery requests with the business teams that perform them.

Then build the control and measurement baseline. Confirm which mail, identity, browser, endpoint, and domain controls are enabled and who owns them. Define the few outcome measures the team will review. Schedule a formal review with named action owners and dates.

The [phishing definition and prevention guide](/learning/what-is-phishing) provides the threat vocabulary for this inventory. This article owns the operating model rather than repeating every attack type or defensive setting.

## How should the program be measured?

Do not use click rate as the whole score. A difficult, relevant simulation and an obvious repeated lure are not equivalent. [NIST TN 2276](https://csrc.nist.gov/pubs/tn/2276/final) explains how the Phish Scale can add human detection-difficulty context to click-rate and report-rate results.

Use a balanced set of measures:

- **Reporting behavior:** report rate, median time to first report, and the share of confirmed incidents first surfaced by a person.
- **Triage performance:** queue age, time to classification, escalation time, and disposition quality.
- **Control coverage:** protected users and domains, effective policy coverage, exceptions, and overdue remediation.
- **Incident outcomes:** affected accounts, exposure time, related-message removal, recovery time, and repeated root causes.
- **Exercise context:** audience, scenario difficulty, delivery rate, click or submission rate, report rate, and follow-up completion.
- **Improvement delivery:** actions completed on time, retest results, and recurring findings.

![Balanced anti-phishing program measures covering reporting, triage, control coverage, incident outcomes, exercise context, and improvement delivery.](/images/editorial/anti-phishing-program/anti-phishing-program-balanced-measures.svg "1100x620")

*Source: Original Palisade measurement scorecard based on [NIST TN 2276](https://csrc.nist.gov/pubs/tn/2276/final) and [NIST SP 800-61 Revision 3](https://csrc.nist.gov/pubs/sp/800/61/r3/final). [Open the full-size anti-phishing measurement scorecard](/images/editorial/anti-phishing-program/anti-phishing-program-balanced-measures.svg).*

Compare trends only when the audience, scenario, and measurement method are sufficiently similar. A lower click rate can reflect a better program, an easier test, a familiar template, or a delivery problem. The review should explain which interpretation the evidence supports.

## Choose the next control-specific workstream

Use the [email-security hub](/learning/email-security) to choose the next implementation guide. Move to the software comparison only when product selection is the unresolved task, or to the simulation guide when campaign design is the unresolved task. A guide cannot replace assigned ownership, authorization, evidence collection, or incident response.

## Sources and further reading

- [DOJ: Anti-Phishing Program Support](https://www.justice.gov/jmd/page/file/1368721/dl?inline=)
- [CISA: Four Cybersecurity Essentials for SLTTs](https://www.cisa.gov/resources-tools/resources/four-cybersecurity-essentials-sltts)
- [CISA, NSA, FBI, and MS-ISAC: Phishing Guidance](https://www.cisa.gov/sites/default/files/2025-03/Phishing%20Guidance%20-%20Stopping%20the%20Attack%20Cycle%20at%20Phase%20One%20508.pdf)
- [NIST TN 2276: Phish Scale User Guide](https://csrc.nist.gov/pubs/tn/2276/final)
- [NIST SP 800-61 Revision 3: Incident Response](https://csrc.nist.gov/pubs/sp/800/61/r3/final)

## Frequently asked questions

### Is an anti-phishing program just employee training?

No. Training is one component. A complete program also assigns owners, operates technical controls, provides a reporting route, connects reports to triage and incident response, measures outcomes, and drives verified improvements.

### Who should own the program?

One accountable security or risk leader should coordinate it, even when IT, help desk, identity, communications, legal, HR, and business teams operate individual controls. Shared work does not remove the need for a named decision owner.

### How often should phishing simulations run?

Use a risk-based and formally authorized cadence. Frequency should reflect workforce exposure, material changes, recent incidents, legal and privacy constraints, and the team's ability to act on results. Repeated campaigns without analysis or follow-up add little value.

### What metrics should an anti-phishing program track?

Track reporting speed, triage quality, control coverage, incident outcomes, exercise context, and completed improvements. Click and report rates are useful only when interpreted with audience and scenario difficulty.

### Does DMARC stop every phishing attack?

No. DMARC can help receivers evaluate direct use of a protected domain in the visible From address. It does not stop every lookalike domain, compromised account, malicious link, attachment, text message, voice call, or fraudulent business process.