Your employee receives an email about a critical security issue. Minutes later, someone claiming to be from IT calls to "help" resolve it. Eleven hours later, attackers have compromised nine additional systems. This isn't hypothetical—Huntress documented this exact attack pattern across five partner organizations, with attackers deploying customized Havoc C2 frameworks through fake technical support channels.
The speed and sophistication of these social engineering attacks reveal a critical gap: your technical controls are only as strong as your least-prepared employee. This checklist helps you build the human defenses that technology alone cannot provide.
What This Checklist Covers
This checklist addresses the dual challenge of social engineering defense: preparing your team to recognize sophisticated impersonation attacks while implementing technical controls that limit damage when social engineering succeeds. Each item maps to specific security frameworks where applicable and defines clear success criteria.
Prerequisites
Before implementing this checklist, ensure you have:
- Designated security awareness owner: Someone accountable for training effectiveness, not just completion rates.
- Incident response plan baseline: Even a simple runbook for reporting suspicious contacts.
- Asset inventory: Know what attackers might request access to.
- Communication channel documentation: Clear records of how your IT team actually contacts employees.
Security Awareness Checklist
1. Document Your IT Support Contact Patterns
Requirement: Create a written policy defining how your IT team initiates contact with employees.
Action: Document every legitimate scenario where IT contacts employees first (password resets, security alerts, compliance checks). Specify approved channels (Slack, Teams, internal ticketing system) and explicitly state what IT will never do (call from external numbers, request credentials, ask to install software from links).
Framework reference: NIST CSF v2.0 PR.AT-1 (All users are informed and trained)
What good looks like: An employee can open a one-page reference and immediately identify that an unexpected phone call from "IT" asking them to visit a website is suspicious, regardless of how urgent it sounds.
2. Implement Out-of-Band Verification Procedures
Requirement: Establish a mandatory verification process for any IT-initiated contact requesting action.
Action: Train employees to end the call/ignore the email and contact IT through a known-good channel (internal directory, bookmarked help desk portal) before taking any action. Make this a zero-exception policy with executive buy-in.
Framework reference: ISO 27001 Control 5.16 (Identity management)
What good looks like: When an attacker calls claiming to be IT, your employee politely says "I'll call you back through the help desk" and actually does it—even if the caller sounds frustrated or claims it's urgent.
3. Deploy Technical Indicators for Suspicious Requests
Requirement: Configure systems to flag requests that match social engineering patterns.
Action: Set up alerts for: external emails spoofing internal domains, multiple failed authentication attempts followed by help desk tickets, requests to disable MFA, and installation requests for remote access tools (TeamViewer, AnyDesk, etc.) outside your standard toolset.
Framework reference: NIST 800-53 Rev 5 SI-4 (System Monitoring)
What good looks like: Your SOC receives an alert within minutes when someone attempts to install remote access software, giving you time to verify legitimacy before the installation completes.
4. Test Social Engineering Resistance Quarterly
Requirement: Run realistic social engineering simulations that mirror current attack techniques.
Action: Go beyond phishing emails. Conduct voice phishing (vishing) tests where someone calls claiming to be IT. Track not just who falls for it, but who reports it through proper channels. Use failures as immediate training opportunities, not punishment.
Framework reference: SOC 2 Type II CC6.7 (Security awareness training)
What good looks like: When you run a test, at least 80% of employees either refuse the request or report it through your incident response channel. Failures trigger one-on-one coaching within 24 hours.
5. Create Role-Specific Attack Scenarios
Requirement: Tailor social engineering training to the actual risks each role faces.
Action: Finance teams get training on CEO fraud and invoice manipulation. IT admins learn about attackers impersonating vendors requesting access. Developers understand attacks that exploit their access to code repositories. Use specific examples, not generic warnings.
Framework reference: PCI DSS v4.0.1 Requirement 12.6.3 (Personnel training)
What good looks like: Your finance director can describe three specific social engineering tactics targeting finance teams and knows the exact verification steps for payment requests, even from executives.
6. Establish Rapid Lateral Movement Detection
Requirement: Deploy monitoring that catches attackers moving between systems quickly.
Action: Configure alerts for unusual authentication patterns (same user accessing multiple systems in short timeframes, especially systems they rarely use). Given that attackers moved to nine endpoints in eleven hours in documented cases, you need detection that works in minutes, not days.
Framework reference: NIST CSF v2.0 DE.CM-1 (Networks and network services are monitored)
What good looks like: When a compromised account starts accessing systems outside normal patterns, your security team gets alerted within 15 minutes and can investigate before significant lateral movement occurs.
7. Restrict Remote Access Tool Installation
Requirement: Prevent unauthorized remote access software deployment.
Action: Use application control to block execution of remote access tools not on your approved list. If you need flexibility, require IT approval before installation. Monitor for attempts to install TeamViewer, AnyDesk, or similar tools—these are common in social engineering attacks.
Framework reference: NIST 800-53 Rev 5 CM-7 (Least Functionality)
What good looks like: When an attacker convinces an employee to download remote access software, it fails to execute. The attempt generates an alert that reaches your security team before the attacker can try an alternative approach.
8. Document and Share Near-Miss Incidents
Requirement: Create a feedback loop from reported suspicious contacts.
Action: When employees report potential social engineering attempts, investigate and share findings with the entire organization within 48 hours. Include specific details: what the attacker said, what they requested, how the employee recognized it. This turns one person's vigilance into organization-wide learning.
Framework reference: ISO/IEC 27001:2022 Control 5.6 (Contact with authorities)
What good looks like: After an employee reports a suspicious call, everyone receives a brief summary: "Yesterday, attackers called claiming to be from our help desk, citing ticket #[random]. They requested remote access to 'fix a security issue.' Remember: IT always creates tickets you can verify in ServiceNow before calling you."
Common Mistakes
- Treating awareness training as a checkbox exercise: Completion rates don't equal preparedness. If your only metric is "100% completed the annual training," you're measuring the wrong thing.
- Failing to model realistic attack scenarios: Generic "be careful of phishing" training doesn't prepare employees for a caller who knows their name, their manager's name, and references a recent company announcement.
- Punishing victims instead of improving defenses: When someone falls for social engineering, investigate why your controls failed to stop it, not just who clicked the link.
- Ignoring the speed of modern attacks: Attackers moved across nine systems in eleven hours. If your detection and response processes take days, you've already lost.
Next Steps
Start with items 1, 2, and 5—these require no budget and provide immediate risk reduction. Document your IT contact patterns this week. Next, implement out-of-band verification as policy. Then build role-specific scenarios based on actual attacks targeting your industry.
For technical controls (items 3, 6, 7), prioritize based on your current visibility gaps. If you can't detect lateral movement quickly, that's your highest-risk area.
Schedule your first realistic social engineering test within 30 days. Use the results to refine your training, not to shame participants. The goal is building organizational muscle memory: when something feels wrong, your people know exactly what to do.
Social Engineering Attacks
