Phishing Simulation Plan Template (ISO/IEC 27001 A.6.3)

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.

Document control

Approvals

Revision history

Contents

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

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):

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

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

3.1 Prohibited lures and techniques

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

4.1 Who must agree, and when

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

5.1 In scope

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

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

7.1 Difficulty levels

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)

8. Running a campaign safely

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

9.1 Measures

9.2 Results (Example)

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

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

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

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

13. Size tiers

14. Records and evidence

15. References

• 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.