Security Training Operations SOP

Security Training Operations SOP

1. Purpose

Operationalises the Security Awareness Training Policy (POL-025) using a free, in-house stack (Google Workspace + Gophish + curated open content). Describes concretely how T1 (annual programme), T2 (phishing simulations), and new-joiner onboarding are delivered, tracked, and filed as audit evidence.

2. Tooling Stack

Paid LMS (KnowBe4 / Hoxhunt / SafeTitan / Infosec IQ) remains the future option if the admin burden of this stack outweighs the licence cost — decision reviewed at year-2 ISRMC.

3. Drive Folder Layout

/Security/Training/
  /<YYYY>/
    /T1-annual/
      common-track-deck.pdf
      engineering-track-deck.pdf
      sre-track-deck.pdf
      finance-ops-track-deck.pdf
      pam-track-deck.pdf
      attendance.gsheet
      acknowledgment-common.gform
      acknowledgment-engineering.gform
      ...
    /T1-ad-hoc-<YYYY-MM-DD>-<topic>/
    /T2-phishing-<YYYY-HH-NN>/
      campaign-config.md
      landing-page.html
      recipient-list.csv
      results.csv
      repeat-clickers.csv
  /onboarding/
    <new-joiner-module-v<N>>
  /content-library/     # re-usable decks, Form templates, phishing templates

All folders are owned by security@wealthy.in, edit access for CISO + HR, view access for internal auditors on request.

4. T1 — Annual Security Training Programme

4.1 Pre-session (2 weeks out)

1. CISO + HR open the GitHub Issue using the Security Training Programme template; assign to themselves.
2. Current year’s content is refreshed: common-track deck updated with any new DPDP / IRDAI / SEBI changes, role-track decks refreshed.
3. Acknowledgment Forms for each track are cloned from the content library and dated for the current year.
4. Google Classroom course Security Training <YYYY> is created; employees are enrolled via Workspace Admin bulk CSV.
5. Google Meet is scheduled — one all-hands (common track), four role-track breakouts.

4.2 Session day

1. Common track runs first (45 min), live on Meet, recorded.
2. Role-track breakouts (45–75 min each): Engineering, SRE/Security, Finance/Support/Ops, PAM holders.
3. Acknowledgment Form for each track shared in the call; completion is required within 48 hours.

4.3 Follow-up (within 7 days)

1. Attendance pulled from Meet + cross-checked against Forms submissions into the attendance.gsheet.
2. Absentees notified with a 7-day deadline to watch the recording + complete the Form.
3. Persistent non-completers (>14 days) trigger account-access review per POL-025 §6.
4. Completion % per track, per role logged in the GitHub Issue.

4.4 Sign-off

1. Trainer(s), CISO, and HR sign the Issue.
2. Issue closed with training label; all artefacts linked from the Issue body.

5. New-Joiner Onboarding (continuous)

1. HR adds the joiner to Workspace; onboarding flow auto-enrols into Security Onboarding <YYYY> Classroom course.
2. Joiner has 7 calendar days from start date to complete the module + pass the quiz with ≥ 80%.
3. Production access is gated on quiz pass — SRE checks the Classroom completion report before granting access (IAM change request won’t be approved without it).
4. HR logs completion in the joiner’s personnel record; a monthly GitHub Issue bundles all new-joiner completions for audit evidence.

6. T2 — Phishing Simulation

6.1 Gophish — ephemeral deployment on GKE

Gophish only needs to run for the ~7-day campaign window (×2 per year, plus any ad-hoc). It is brought up at campaign launch and torn down at close; nothing is kept permanently live. Persistent state (SQLite DB, templates, recipient lists, historical results) lives outside the runtime in the Training Drive folder and the phishing-simulation/ folder of the security repo — restored on bring-up, snapshotted on tear-down.

Platform: GKE, security namespace (same namespace as Wazuh). Manifests + full runbook live in phishing-simulation/README.md in the security repo. Apply with kubectl apply -k . at bring-up, kubectl delete -k . at tear-down.

Key config:

No separate domain is purchased — both hostnames use subdomains of wealthy.systems (already owned for docs.wealthy.systems, wazuh.wealthy.systems). TLS via the same *.wealthy.systems wildcard cert.

6.2 Campaign flow (per half-year — DevOps-scheduled, CISO-owned)

1. CISO picks the next theme at the start of each half (OAuth-consent abuse, CEO fraud, courier delivery, payroll — rotate) and drafts the template + landing page.
2. Template + landing page reviewed for realism and no actual harm; signed off by CISO.
3. Recipient list pulled from Workspace (exclude contractors not in scope).
4. DevOps schedules the send in Gophish for the agreed launch date — Gophish’s built-in scheduler handles the actual send, so no human needs to be at the console. Campaign runs over a 7-day window; results track live.
5. After close (automated email from Gophish to CISO):
   • Results CSV exported (automated via Gophish API + launchd script).
   • Click rate, credential-entry rate, report rate computed; trend chart updated.
   • Repeat-offender list produced (anyone who clicked in any prior campaign).
   • 1:1 coaching scheduled for repeat offenders.
6. Evidence filed in the GitHub Issue using the Phishing Simulation template.
7. If click rate or repeat-offender rate breach POL-025 §6 targets, the cadence auto-raises to quarterly until restored.

6.3 Ad-hoc campaign triggers

• Real phishing incident affecting Wealthy — re-test the same vector.
• New joiner cohort (> 5 joiners in a month) — targeted mini-campaign after their onboarding.
• New regulation / theme (e.g. DPDP Rules rollout) — targeted campaign.

7. Ad-hoc Training

Triggered by: post-incident retraining, regulation rollout, new major control, CTO / Compliance request.

1. Issue opened with training label, session type = Ad-hoc and the trigger noted.
2. Content is either an existing module (Classroom republish) or a short live session (Meet).
3. Acknowledgment Form + attendance captured same as T1.
4. Filed in /Security/Training/<YYYY>/T1-ad-hoc-<date>-<topic>/.

8. Evidence & Retention

All training evidence retained per regulatory retention (minimum 5 years for IRDAI / SEBI / CERT-In):

• Classroom completion reports (exported annually to Drive)
• Google Forms response CSVs
• Attendance sheets
• Training decks (versioned per year)
• Gophish campaign exports
• GitHub Issues with training / phishing-sim labels — the index into the above

9. Metrics Reporting

Reported quarterly to ISRMC, annually to the Board (driven by POL-025 §6):

10. Roles

11. Year-2 Re-evaluation

At the 12-month mark, CISO reviews whether the in-house stack should be replaced by a paid LMS. Decision criteria:

• Hours spent monthly on manual evidence stitching
• Audit findings related to training evidence completeness
• Click-rate / completion trends requiring finer role-based paths
• Price of available LMS licences relative to team size

Outcome logged in the ISRMC minutes + POL-025 is updated if decision is to switch.

12. Related Documents

• Security Awareness Training Policy (POL-025) — parent policy
• Security Governance Calendar — T1, T2 scheduled events
• Incident Response SOP (SOP-004) — triggers ad-hoc retraining
• Privileged Access Management Policy (POL-018) — PAM module audience

Reviewed semi-annually. Last revision: April 2026. Contact: security@wealthy.in.