# Phishing Simulation Plan: [Organization name]

> Plan for running ethical, lawful and useful phishing and social
> engineering simulations for one programme year. It supports ISO/IEC
> 27001:2022 + Amd 1:2024 clause 7.3 and Annex A control A.6.3
> (awareness, education and training), and produces measures of how
> well people recognise and report attacks under A.6.8 (reporting
> security events). Replace every `[bracketed]` value and every row
> marked *Example*. Parts on employee representation, monitoring and
> processing of results are a documentation format, not legal advice.

<!--
Guidance: How to use this template
- When to use: before the first simulation of a programme year, and
  whenever the rules, the tool or the audience change. The overall
  awareness programme is `security/security-awareness-program`; this plan
  is the detailed, approved plan for the simulation part of it.
- Fill first: section 3 (ethics and lures that are never used), section 4
  (consultation and approvals) and section 9 (metrics). Get HR, legal or
  privacy and, where they exist, employee representatives to agree these
  before choosing a single lure.
- Main pitfall: treating click rate as the score and clickers as
  offenders. That drives people to hide mistakes and stop reporting, which
  is the opposite of what A.6.8 needs. Lead with report rate and time to
  first report.
- Related templates: `security/security-awareness-program`,
  `isms/security-event-reporting-procedure`, `isms/employee-security-handbook`,
  `isms/isms-competence-training-matrix`, `compliance/dpia`,
  `isms/security-monitoring-procedure`, `isms/control-evidence-matrix`.
-->

## Document control

<!-- Guidance: Approve the plan once per programme year and record changes. Each campaign brief (section 7) refers to this version. -->

| Field | Value |
|---|---|
| Document ID | DOC-ISMS-074 |
| Version | [1.0] |
| Status | [Draft / In review / Approved / Superseded] |
| Owner | [@awareness-lead] |
| Approvers/reviewers | [@ciso], [@isms-manager], [@hr-lead], [@privacy-lead], [@legal] |
| Last updated | YYYY-MM-DD |
| Classification | [Internal] (campaign calendar and lure details: [Confidential]) |
| Standard and edition | ISO/IEC 27001:2022 + Amd 1:2024, clause 7.3, Annex A A.6.3 and A.6.8; ISO/IEC 27002:2022 |
| Programme year | [2027] |
| Parent document | `security/security-awareness-program` |
| Simulation tool | [Simulation platform category, hosted in [region]] |
| Employee representative consultation | [Not required / Completed YYYY-MM-DD, reference] |
| Data protection assessment | [Screening YYYY-MM-DD / DPIA reference] |
| Next scheduled review | YYYY-MM-DD |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Plan owner | [@awareness-lead] | [Prepared] | YYYY-MM-DD |
| HR lead | [@hr-lead] | [Reviewed] | YYYY-MM-DD |
| Privacy or legal lead | [@privacy-lead] | [Reviewed] | YYYY-MM-DD |
| CISO | [@ciso] | [Approved] | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change |
|---|---|---|---|
| 1.0 *(Example)* | YYYY-MM-DD | [@awareness-lead] | Plan for programme year 2027 |
| 1.1 *(Example)* | YYYY-MM-DD | [@awareness-lead] | Added voice simulation for finance after works council agreement |

## Contents

<!-- Guidance: Sections 1 to 4 set the rules and approvals, sections 5 to 8 plan the campaigns, sections 9 to 11 measure and follow up, sections 12 to 15 cover data, tiers and evidence. -->

1. Purpose and objectives
2. Principles
3. Ethics and prohibited lures
4. Consultation, consent and approvals
5. Scope and audiences
6. Frequency and campaign calendar
7. Campaign design and difficulty levels
8. Running a campaign safely
9. Metrics
10. Follow-up training and support
11. No punitive use
12. Data protection of results
13. Size tiers
14. Records and evidence
15. References

## 1. Purpose and objectives

<!-- Guidance: Simulations are a means, not the goal. State the behaviours you want to change and how you will know. Questions to answer: what real attacks does the organization see? Which teams are targeted? Pitfall: "reduce click rate to 0 %", which is neither realistic nor the right aim. -->

This plan describes how [Organization name] uses simulated phishing and
social engineering to help people recognise and report real attacks. It
sets the ethical limits, the approvals, the campaigns for the
programme year, the measures and the follow-up.

Objectives for [2027] *(Example)*:

| Objective ID | Objective | Measure | Target |
|---|---|---|---|
| PSO-01 *(Example)* | More people report suspicious messages, and faster | Report rate; median time to first report | Report rate ≥ 40 % by Q4; first report within 10 minutes |
| PSO-02 *(Example)* | Fewer people enter credentials on fake pages | Credential submission rate | ≤ 2 % at moderate difficulty |
| PSO-03 *(Example)* | Finance staff verify payment change requests | Call-back performed in payment-fraud simulation | ≥ 90 % of finance recipients |
| PSO-04 *(Example)* | Real phishing is reported more often | Real malicious emails reported per month | Rising trend year on year |

Simulations are one part of the awareness programme
(`security/security-awareness-program`). They do not replace technical
controls such as email filtering, MFA and payment controls.

## 2. Principles

<!-- Guidance: Keep five or six principles that management signs. Every campaign decision should be checkable against them. -->

1. **Learning, not catching.** The purpose is to build skill and
   confidence. Results are used to improve training and controls.
2. **Transparency.** Staff are told that simulations happen, why, and
   how results are used, before the first campaign and every year.
3. **Respect.** Lures never exploit fear, grief, health, money worries
   or personal life (section 3).
4. **Reporting first.** Reporting is the most important behaviour.
   Reporting a simulation is praised, and reporting is measured before
   clicking.
5. **Proportionate data use.** Individual results are seen by as few
   people as possible and kept for a short time (section 12).
6. **Realistic, but fair.** Campaigns reflect real threats to the
   organization, at a known difficulty level, so results can be
   compared over time.

## 3. Ethics and prohibited lures

<!-- Guidance: Write down what you will never do. This list protects staff, the organization's reputation and the programme itself. Have HR and legal confirm it. A lure that upsets staff can end the programme. -->

### 3.1 Prohibited lures and techniques

| Rule ID | Never |
|---|---|
| ETH-01 | Promise bonuses, pay rises, gifts, vouchers or benefits that do not exist |
| ETH-02 | Threaten dismissal, disciplinary action, restructuring or pay cuts |
| ETH-03 | Use health emergencies, bereavement, accidents, pandemics or family matters |
| ETH-04 | Impersonate real external brands, government bodies, regulators, police, charities or unions without written legal approval; prefer fictional senders |
| ETH-05 | Impersonate a named real colleague without their prior agreement, or use executives' names without their agreement |
| ETH-06 | Target personal accounts, personal phone numbers or social media profiles |
| ETH-07 | Collect real passwords: landing pages must not store entered credentials, only the fact that something was entered |
| ETH-08 | Deliver real malware, or attachments that run code beyond a harmless tracking action approved by security operations |
| ETH-09 | Run campaigns during a real crisis, a major organizational change announcement, or a period of known distress (for example after layoffs) |
| ETH-10 | Single out individuals or teams publicly, or rank named people |

### 3.2 Ethics review

Every campaign brief is checked against section 3.1 by the awareness
lead and by a reviewer outside the security team (for example HR). Any
lure in a sensitive area (internal policies, benefits, events) needs
HR approval. Record the review in the campaign brief.

## 4. Consultation, consent and approvals

<!-- Guidance: Requirements differ by country. In some jurisdictions, works councils or employee representatives have rights to be informed or consulted on, or to agree, measures that monitor staff behaviour. Data protection law (for example the GDPR) needs a lawful basis and transparency. Ask local counsel. Do not rely on individual consent from employees where the law doubts it can be freely given. This is a documentation format, not legal advice. -->

### 4.1 Who must agree, and when

| Step | Who | What | Record |
|---|---|---|---|
| 1 | Legal or privacy lead | Confirms lawful basis, transparency notice, need for a DPIA or screening (`compliance/dpia`) | Assessment reference in Document control |
| 2 | HR lead | Confirms alignment with employment terms and the disciplinary process; approves sensitive themes | HR approval |
| 3 | Employee representatives (where they exist or local law requires) | Informed, consulted or asked to agree, as local law and agreements require | Minutes or agreement reference |
| 4 | CISO | Approves the plan | Approval table |
| 5 | Security operations and email administrators | Agree technical set-up and campaign windows (section 8) | Change record |
| 6 | Executives and named senders | Agree to the use of their names, if any | Email or minute |

### 4.2 Transparency to staff

Before the first campaign, and once a year, all staff receive a notice
(in onboarding and in [intranet / all-hands]) that explains:

- simulations happen at unannounced times, by email and possibly by
  text message or phone;
- the purpose is learning, and results never lead to disciplinary action
  on their own (section 11);
- what data is recorded, who sees it and how long it is kept
  (section 12);
- how to report a suspicious message, real or simulated
  (`isms/security-event-reporting-procedure`);
- who to contact with concerns.

Individual consent to each campaign is not sought, because announcing
campaigns would defeat their purpose; transparency at programme level
and the safeguards in this plan take its place. Staff may raise
objections with [@privacy-lead], who records and answers them.

## 5. Scope and audiences

<!-- Guidance: Define who receives simulations and who is excluded or treated differently. Questions to answer: are contractors included? What about people on leave or new joiners? Pitfall: forgetting senior executives, who are often the most targeted. -->

### 5.1 In scope

| Audience ID | Audience | Channels | Notes |
|---|---|---|---|
| PA-ALL | All employees and contractors with a corporate email account | Email | Includes executives |
| PA-FIN | Finance, payroll and procurement | Email, voice | Payment fraud and supplier bank change scenarios |
| PA-EXE | Executives and their assistants | Email, text message | Targeted lures; prior agreement on use of names |
| PA-IT | IT administrators and service desk | Email, voice | Help desk password reset and MFA reset scenarios |
| PA-NEW | New joiners after their first [30] days | Email | Not before onboarding training is complete |

### 5.2 Excluded or deferred

- people on long-term leave, parental leave or sick leave;
- new joiners in their first [30] days;
- anyone who has asked for a temporary pause for personal reasons
  agreed with HR (no reason needs to be shared with security);
- suppliers' staff using their own email systems (covered by contract
  requirements instead).

## 6. Frequency and campaign calendar

<!-- Guidance: Quarterly all-staff campaigns are a common pattern, with extra targeted campaigns for high-risk groups. More frequent is not better if it causes fatigue. Keep the calendar Confidential so dates do not leak. -->

| Campaign ID | Window | Audience | Channel | Theme *(Example)* | Difficulty |
|---|---|---|---|---|---|
| PSC-2027-01 *(Example)* | 2027-02-08 to 2027-02-19 | PA-ALL | Email | Shared document from an internal-style sender | Moderately difficult |
| PSC-2027-02 *(Example)* | 2027-04-12 to 2027-04-23 | PA-FIN | Email, voice | Supplier asks to change bank details | Very difficult |
| PSC-2027-03 *(Example)* | 2027-05-10 to 2027-05-21 | PA-ALL | Email | Delivery exception from a fictional carrier | Moderately difficult |
| PSC-2027-04 *(Example)* | 2027-07-05 to 2027-07-16 | PA-IT | Voice | Caller asks the service desk to reset MFA | Very difficult |
| PSC-2027-05 *(Example)* | 2027-09-13 to 2027-09-24 | PA-ALL | Email | Calendar invitation to a fictional industry webinar | Moderately difficult |
| PSC-2027-06 *(Example)* | 2027-11-08 to 2027-11-19 | PA-ALL, PA-EXE | Email (all), text message (PA-EXE only) | Sign-in alert from a fictional collaboration service | Very difficult |

```mermaid
gantt
  title Phishing simulation calendar 2027 (Example)
  dateFormat YYYY-MM-DD
  section All staff
  PSC_2027_01_document_share :a1, 2027-02-08, 12d
  PSC_2027_03_delivery_notice :a3, 2027-05-10, 12d
  PSC_2027_05_webinar_invite :a5, 2027-09-13, 12d
  PSC_2027_06_signin_alert :a6, 2027-11-08, 12d
  section Targeted
  PSC_2027_02_finance_bank_change :a2, 2027-04-12, 12d
  PSC_2027_04_service_desk_voice :a4, 2027-07-05, 12d
  section Review
  Midyear_review :r1, 2027-06-01, 10d
  Annual_review :r2, 2027-12-01, 15d
```

Each email is sent at a random time within the window, staggered so
colleagues do not all receive it at once and warn each other. The
mid-year review (June) checks results and lure feedback against section
3 and may adjust the second half of the calendar; the annual review
(December) feeds the next plan and the management review (section 14).

## 7. Campaign design and difficulty levels

<!-- Guidance: Rate every lure with a consistent method so results are comparable. The NIST Phish Scale (NIST TN 2276) rates detection difficulty from the number of cues in the message and how well the premise fits the audience's work. Use it, or document your own method. Pitfall: making each campaign harder to "beat" staff, then reporting that click rates went up. -->

### 7.1 Difficulty levels

| Level | Description | Typical use |
|---|---|---|
| D1 Least difficult | Many visible cues (odd sender, spelling, generic greeting); premise unrelated to the person's work | First campaign, new joiners |
| D2 Moderately difficult | Some cues; premise plausible for most staff | Quarterly all-staff campaigns |
| D3 Very difficult | Few cues; premise closely aligned with the audience's real work | Targeted groups (finance, IT, executives), later in the year |

Map D1 to D3 to the NIST Phish Scale ratings in each campaign brief, and
report the rating with the results.

### 7.2 Campaign brief *(one per campaign)*

| Field | Entry |
|---|---|
| Campaign ID | PSC-2027-03 *(Example)* |
| Objective | PSO-01, PSO-02 |
| Audience and size | PA-ALL, [number] recipients |
| Channel | Email |
| Premise | Delivery exception notice from a fictional carrier |
| Cues present | Sender domain mismatch, urgency, generic greeting, link text differs from destination |
| Difficulty and rating | D2, NIST Phish Scale rating [value] |
| Landing page | Short teaching page showing the cues in this email |
| Ethics review (section 3.2) | [@awareness-lead], [@hr-reviewer], YYYY-MM-DD |
| Technical set-up approved | Change [CHG-ID], security operations informed |
| Window | 2027-05-10 to 2027-05-21 |
| Plan version | DOC-ISMS-074 version [1.0] |

## 8. Running a campaign safely

<!-- Guidance: A simulation must not break real security. Coordinate with security operations, avoid permanent allowlisting, and stop at once if something goes wrong. -->

1. **Technical set-up.** Email administrators allow simulation traffic
   for the campaign window only, using the method the email platform
   provides, and record it as a change. Do not weaken filtering for real
   email.
2. **Security operations.** The on-call analyst knows the window and can
   identify simulation emails, so real reports are still triaged
   correctly. Reports of the simulation are acknowledged automatically
   with positive feedback.
3. **Report button.** The [Report phishing] button works for both real
   and simulated messages, and a reported simulation counts as success.
4. **Stop rule.** The awareness lead stops the campaign at once if: a
   real incident with a similar theme starts; the lure causes distress;
   external parties (customers, suppliers) receive it; or the tool
   misbehaves.
5. **Voice and text.** Use approved scripts and work numbers only. End
   the call politely if the person is distressed, and explain that it
   was an exercise.
6. **Close-out.** Remove allowlisting at the end of the window and
   confirm in the change record.

## 9. Metrics

<!-- Guidance: Report rate and time to first report come first, because they show the behaviour that protects the organization: a fast report lets the security team block a real campaign for everyone. Click rate and credential submission come next. Always show difficulty alongside results. -->

### 9.1 Measures

| Metric ID | Measure | Formula | Order of importance |
|---|---|---|---|
| PSM-01 | Report rate | Unique recipients who reported / recipients | 1 |
| PSM-02 | Time to first report | Minutes from first delivery to first report | 2 |
| PSM-03 | Reports per click | Unique reporters / unique clickers | 3 |
| PSM-04 | Click rate | Unique recipients who clicked / recipients | 4 |
| PSM-05 | Credential submission rate | Unique recipients who entered data / recipients | 5 |
| PSM-06 | Reported after clicking | Clickers who then reported / clickers | 6 |
| PSM-07 | Real phishing reports per month | Count from security operations | Trend |

### 9.2 Results *(Example)*

Quillmere Health Systems (320 staff), all-staff campaigns. Recipients
exclude staff on leave and new joiners.

| Campaign | Difficulty | Recipients | Reported | Report rate | Clicked | Click rate | Credentials entered | Credential rate | Reports per click | First report |
|---|---|---|---|---|---|---|---|---|---|---|
| PSC-2027-01 | D2 | 300 | 75 | 25.0 % | 36 | 12.0 % | 12 | 4.0 % | 2.08 | 14 min |
| PSC-2027-03 | D2 | 310 | 93 | 30.0 % | 31 | 10.0 % | 9 | 2.9 % | 3.00 | 9 min |
| PSC-2027-05 | D2 | 305 | 122 | 40.0 % | 21 | 6.9 % | 5 | 1.6 % | 5.81 | 6 min |

Reading the results: at the same difficulty, the report rate rose from
25.0 % to 40.0 % and the time to first report fell from 14 to 6
minutes, while credential entry fell from 4.0 % to 1.6 %. The trend, not
any single campaign, is what goes to the management review.

### 9.3 Reporting

- Results go to the ISMS steering committee and the measurement
  programme (`isms/isms-measurement-programme`) in aggregate, with
  difficulty shown.
- Team-level results are shown only for groups of at least [10]
  recipients.
- Results never appear with names outside the awareness team
  (section 12).

## 10. Follow-up training and support

<!-- Guidance: The moment after a click is the best learning moment. Keep it short and kind. Offer support, not punishment, to people who struggle. -->

| Trigger | Follow-up | Who | Timing |
|---|---|---|---|
| Clicked a simulation | Landing page showing the cues missed, and a 3-minute lesson | Automatic | At once |
| Entered data on a simulation page | As above, plus a short module on credential phishing and MFA prompts | Automatic | Within [7] days |
| Reported a simulation | Thank-you message explaining the cues | Automatic | At once |
| Clicked in three consecutive campaigns | Offer of a one-to-one session with the awareness team; the manager is asked to free up time only if the person agrees, and is not given campaign results | Awareness lead | Within [30] days |
| Team report rate below [20] % | Team briefing by a security champion | Awareness lead | Next month |
| Real attack theme seen by security operations | New micro-lesson and next campaign theme | Awareness lead with threat intelligence | Next campaign |

Completion of follow-up training is recorded in the learning platform
and feeds `isms/isms-competence-training-matrix` for roles with
specific awareness requirements.

## 11. No punitive use

<!-- Guidance: State the rule plainly and align it with HR. Auditors and employee representatives will ask. Without this rule people stop reporting their own mistakes. -->

1. Simulation results are never used, on their own, for disciplinary
   action, performance ratings, pay, promotion or dismissal decisions.
2. Repeated clicking leads to support and training (section 10), not to
   sanctions.
3. A person who clicks a simulation and then reports it is treated as a
   success case for reporting.
4. The disciplinary process for security breaches
   (`isms/security-disciplinary-process`) applies only to real conduct
   outside the no-blame rule, never to simulation results.
5. Any request from a manager or HR for named simulation results is
   refused, except where a person asks for their own results.

## 12. Data protection of results

<!-- Guidance: Simulation results are personal data about behaviour. Define the minimum data, access, retention, transfers to the tool provider, and the transparency notice. Run a DPIA where the law or your screening requires it. -->

| Topic | Rule |
|---|---|
| Lawful basis | [Legitimate interests / other basis], confirmed by the privacy lead and recorded in `compliance/gdpr-ropa` where the GDPR applies |
| Data recorded | Recipient identifier, delivery time, open (if tracked), click, data entry yes or no (never the data itself), report, report time, follow-up completion |
| Data not recorded | Entered passwords or other typed content, device location, browsing outside the landing page |
| Access to individual results | Awareness lead and [1] named deputy |
| Pseudonymisation | Reports to management use aggregated data; individual records use IDs in the tool |
| Retention | Individual results [12] months, then aggregated or deleted; aggregates kept for trend analysis |
| Tool provider | Assessed under `compliance/supplier-security-assessment`; data processing agreement in place; hosting region [region] |
| Individual rights | Staff can ask for their own results through [privacy contact] |
| Transparency | Annual notice (section 4.2) and the staff privacy notice |

## 13. Size tiers

<!-- Guidance: The ethics and the no-punishment rule do not change with size. Frequency, tooling, consultation and reporting do. These are the library's working tiers. -->

| Topic | Small: Quillmere Analytics Ltd *(Example)* | Medium: Quillmere Health Systems *(Example)* | Large: Quillmere Group *(Example)* |
|---|---|---|---|
| Context | 46 staff (38 employees, 8 contractors), one office plus remote staff | 320 staff, two offices and one colocation suite | 2,400 staff, 6 sites in 4 countries, OT and IT |
| Campaigns per year | 2 all-staff email campaigns; 1 finance payment-fraud scenario | 4 all-staff, 2 targeted (finance, IT service desk) | 4 all-staff per country in local languages, targeted campaigns for finance, executives and plant administration |
| Tooling | Simulation feature of the email security service | Dedicated simulation platform with learning integration | Enterprise simulation platform with regional data hosting |
| Consultation | Staff informed at all-hands; privacy screening | Privacy lead DPIA screening, HR approval | Works council or employee representative consultation in each country where required, group privacy DPIA |
| Who runs it | ISMS manager (0.5 FTE) with an external template library | Awareness lead in the 3-person security team | Group awareness team, local security champions |
| Group size for reporting | Company-wide only (teams under 10 people) | Teams of at least 10 | Sites and functions of at least 10 |
| Plant and OT staff | Not applicable | Not applicable | Shop-floor staff without email receive classroom social engineering briefings instead of simulations |

## 14. Records and evidence

<!-- Guidance: List the records that prove the plan operates, and map them in the control evidence matrix (DOC-ISMS-033) against clause 7.3, A.6.3 and A.6.8. Auditors typically ask for the plan, two campaign briefs with ethics review, results and the follow-up records. -->

| Record | Proves | Owner | Location | Retention |
|---|---|---|---|---|
| Approved plan (this document) | Simulations are planned and approved | Awareness lead | [Document management system] | Superseded plus [3] years |
| Consultation and privacy assessment records | Lawful and agreed basis | Privacy lead, HR lead | [GRC tool] | [5] years |
| Campaign briefs with ethics review | Each campaign respects section 3 | Awareness lead | [GRC tool] | [3] years |
| Change records for technical set-up | Allowlisting was temporary and controlled | Email administrator | [ITSM tool] | Per change policy |
| Aggregated results per campaign | Awareness effectiveness measured | Awareness lead | `isms/isms-performance-report` | [5] years |
| Individual results | Follow-up was targeted | Awareness lead | [Simulation platform] | [12] months |
| Follow-up training completion | Training delivered after simulations | Awareness lead | [Learning platform] | [3] years |
| Annual review and lessons | Programme improves | Awareness lead | Management review input (`compliance/management-review`) | [5] years |

## 15. References

<!-- Guidance: Cite editions; keep links to official pages only. -->

- ISO/IEC 27001:2022, https://www.iso.org/standard/82875.html, with
  Amendment 1:2024, https://www.iso.org/standard/88435.html (clause 7.3,
  Annex A A.6.3 and A.6.8 cited by number only)
- ISO/IEC 27002:2022, https://www.iso.org/standard/75652.html
- NIST SP 800-50 Rev. 1, *Building a Cybersecurity and Privacy Learning
  Program*, September 2024, https://csrc.nist.gov/pubs/sp/800/50/r1/final
- NIST TN 2276, *NIST Phish Scale User Guide*, November 2023,
  https://csrc.nist.gov/pubs/tn/2276/final
- Regulation (EU) 2016/679 (GDPR), as an example of data protection law
  that applies to processing simulation results
- Related templates: `security/security-awareness-program`,
  `isms/security-event-reporting-procedure`, `isms/employee-security-handbook`,
  `isms/isms-competence-training-matrix`, `compliance/dpia`,
  `isms/security-disciplinary-process`, `isms/control-evidence-matrix`

## Standard and licence note

Structure aligned with ISO/IEC 27001:2022 + Amd 1:2024 clause 7.3 and
Annex A controls A.6.3 and A.6.8, with practical content informed by
NIST SP 800-50 Rev. 1 and NIST TN 2276 (US Government works in the
public domain). Difficulty level names in section 7.1 follow the NIST
Phish Scale; read the method in the official guide. The text of this
template is original. No ISO/IEC text is reproduced; control numbers
and short descriptive labels only are used, and you need the official
standards to read the requirements and guidance. Check the current
editions before use. Parts on consultation and data protection are a
documentation format, not legal advice. Template licence: MIT.