Incident Response Plan Template
|
|
Company Name |
[Company Name] |
Effective Date |
[Date] |
Version |
[Final Version Number, e.g., 2.0] |
Policy Owner |
[CISO/IT Director] |
Document Classification |
Confidential / Internal Use Only |
Parent Policy |
Information Security Policy |
Purpose
This Incident Response Plan (IRP) establishes a comprehensive framework for [Company Name] to effectively detect, respond to, contain, and recover from information security incidents. The plan ensures a timely and coordinated response to minimize operational, financial, and reputational damage, protect sensitive data (including but not limited to cardholder data, PII, and intellectual property), maintain business continuity, and meet regulatory and compliance obligations, including PCI DSS 4.0.1 requirements. It integrates threat intelligence and specific detection mechanisms like rogue wireless scanning to provide proactive and reactive security capabilities across the enterprise.
Scope
This IRP applies to all [Company Name] employees, contractors, temporary staff, and third-party service providers (TPSPs) involved in incident response activities. It covers all information systems, networks, applications, data (including sensitive corporate data, PII, IP, and cardholder data), and physical facilities owned or managed by [Company Name]. This plan addresses a wide range of potential security incidents, such as malware infections, unauthorized access, data breaches, denial-of-service attacks, insider threats, phishing campaigns, system compromises, and the presence of unauthorized hardware like rogue access points, regardless of whether they directly impact the Cardholder Data Environment (CDE).
Roles and Responsibilities
Role/Group |
Key Responsibilities |
Executive Management |
Provide strategic oversight; approve significant resource allocation; make critical business decisions during major incidents; authorize public statements. |
Incident Response Commander |
Oversee and direct all incident response activities; determine incident severity; activate the CSIRT; coordinate cross-functional efforts; final decision authority during active response. |
Cyber Security Incident Response Team (CSIRT) |
Perform technical investigation, analysis, containment, eradication, and recovery; collect and preserve evidence; document actions; maintain forensic readiness. |
Information Security & IT |
Monitor security systems; provide technical support for response actions; implement system changes; maintain security tools, logs, and inventories (including authorized APs). |
Legal Counsel |
Advise on legal implications, regulatory notification requirements (including PCI DSS, GDPR, etc.); guide evidence handling; manage potential litigation; review external comms. |
Communications/PR |
Manage internal and external communications; coordinate media responses; ensure consistent messaging; protect company reputation. |
Human Resources |
Manage personnel issues related to incidents; handle internal communications regarding employee actions or impacts; coordinate relevant training. |
Business Unit Leaders |
Report potential incidents; assess business impact; implement business continuity plans; support user awareness and policy adherence. |
Third-Party Service Providers |
Report incidents affecting [Company Name] data/systems promptly per contractual obligations; cooperate fully with investigations and response efforts. |
Policy Requirements
1. Incident Definitions and Classification
- Security Event: Any observable occurrence in a system or network. Events may not necessarily be negative.
- Adverse Event: An event with negative consequences, such as system crashes, packet floods, or unauthorized use of privileges.
- Security Incident: A violation or imminent threat of violation of security policies, acceptable use policies, or standard security practices that compromises the confidentiality, integrity, or availability of information assets.
- Data Breach: A confirmed incident involving unauthorized access, acquisition, disclosure, or loss of sensitive data (including cardholder data, PII, IP).
- Incidents must be classified based on impact and severity using the following matrix (See Appendix Appendix B for detailed criteria):
Severity |
Description |
Response Time Goal |
Escalation Required |
Critical |
Widespread impact, CDE compromise, significant data loss, major service disruption, regulatory requirement |
< 1 hour |
Exec Mgmt, Legal, Comms, Full CSIRT Activation |
High |
Significant impact, potential CDE involvement, sensitive data exposure, moderate service disruption |
< 4 hours |
IR Commander, Legal, Partial CSIRT Activation |
Medium |
Localized impact, non-sensitive data exposure, minor service disruption, policy violation |
< 8 hours |
IR Commander, IT/Security Team |
Low |
Minimal impact, isolated event, no data exposure, no service disruption |
< 24 hours |
IT/Security Team Lead |
- Note: Any confirmed compromise of cardholder data automatically triggers a Critical severity classification and requires adherence to PCI DSS notification protocols (Req 12.10.1).
2. Incident Response Team (CSIRT) Structure and Readiness
- Maintain a dedicated CSIRT with clearly defined roles, responsibilities, and up-to-date contact information (See Appendix Appendix C).
- Ensure CSIRT members possess diverse skills (technical analysis, forensics, network, systems, legal, communications, cloud environments).
- Provide role-specific training for CSIRT members at least annually on incident handling procedures, forensic techniques, evidence preservation, communication protocols, and relevant regulatory requirements (PCI DSS Req 12.10.4).
- Designate specific personnel to be available 24/7/365 to respond to security alerts and initiate the response process (PCI DSS Req 12.10.3). Ensure primary and backup personnel are assigned for critical roles with defined escalation paths.
3. Threat Intelligence Integration
- Threat Intelligence Program: Maintain a program to gather, analyze, and operationalize threat intelligence from diverse sources (e.g., commercial feeds, ISACs, government agencies, OSINT, dark web monitoring).
- Integration with Risk Management: Use threat intelligence (e.g., relevant TTPs, threat actor profiles, industry-specific threats) to inform risk assessments, identify potential attack vectors, and prioritize security control implementation and testing.
- Enhancing Detection: Continuously incorporate Indicators of Compromise (IoCs) and Tactics, Techniques, and Procedures (TTPs) from threat intelligence into security monitoring tools (SIEM, IDS/IPS, EDR, SOAR) to improve detection accuracy, context, and speed.
- Informing Response: Utilize threat intelligence during incident analysis to understand attacker methodologies, predict potential lateral movement or follow-on actions, guide containment and eradication strategies, and identify potential attribution.
- Proactive Defense: Leverage intelligence to proactively hunt for threats within the environment, adjust security controls (e.g., firewall rules, endpoint policies), inform vulnerability management prioritization, and stay ahead of evolving attack techniques.
- Collaboration & Sharing: Participate in relevant threat-sharing communities or platforms (where appropriate and legally permissible) to contribute and consume intelligence, strengthening collective defense.
4. Detection, Reporting, and Alerting
- Security Monitoring: Implement and maintain comprehensive security monitoring systems (e.g., SIEM, IDS/IPS, EDR, FIM, Network Detection and Response (NDR), log analysis tools) to detect potential incidents across the enterprise. Ensure correlation rules and analytics leverage threat intelligence feeds and are tuned to minimize false positives while maximizing detection of critical events, including alerts necessary for PCI DSS compliance (PCI DSS Req 12.10.5).
- Rogue Access Point (AP) Detection Process:
- Frequency: Conduct scans using appropriate tools to detect and identify authorized and unauthorized wireless access points across all [Company Name] facilities at least quarterly (PCI DSS Req 11.2.1).
- Methodology: Utilize dedicated wireless scanning tools capable of identifying APs across all relevant frequencies (e.g., 2.4 GHz, 5 GHz, 6 GHz) using wireless detection methods. Wired-side scanning (e.g., checking switch ports) may supplement but does not replace wireless scanning.
- Scope: Scanning must cover all physical locations, including areas where wireless is not intentionally deployed or is prohibited, to detect unauthorized devices. Scanning should occur within business hours to detect temporary rogue APs.
- Inventory Management: Maintain an accurate, up-to-date inventory of all authorized wireless APs, including MAC addresses, location, and business justification.
- Comparison & Investigation: Compare scan results against the authorized inventory. Investigate any discrepancies or detected unauthorized APs immediately.
- Response & Remediation: Implement documented procedures to locate, disable (e.g., shut down switch port), and physically remove verified rogue devices promptly upon detection. Document findings, actions taken, and remediation steps within the incident tracking system.
- Alerting: Configure Wireless Intrusion Detection/Prevention Systems (WIDS/WIPS), where deployed, to provide automated alerts for detected rogue devices and other wireless threats. Integrate these alerts into the central SIEM/SOC workflow.
- Reporting Channels: Establish clear, accessible procedures for all personnel and TPSPs to report suspected incidents, security weaknesses, or unauthorized devices immediately through multiple channels (e.g., dedicated security hotline, email alias, service desk portal, SOC). Promote awareness of reporting responsibilities.
- Tracking & Triage: Implement a centralized incident management system (e.g., ITSM or SOAR platform) for logging, tracking, and prioritizing all reported incidents and alerts, including rogue AP detections. Define alert triage processes based on severity criteria, enriched by threat intelligence context.
5. Incident Response Lifecycle (Based on NIST Framework)
- 5.1 Preparation: Maintain this IRP, associated playbooks (informed by threat intelligence and tailored to specific incident types like ransomware, phishing, rogue AP), tools (including forensic software and wireless scanners), and trained personnel. Conduct regular risk assessments incorporating threat intelligence. Maintain asset inventories (including authorized wireless devices) and network diagrams. Ensure forensic readiness (e.g., adequate logging, trained personnel, necessary tools).
- 5.2 Detection and Analysis: Continuously monitor alerts (including WIDS/IPS and TI-enhanced SIEM); actively hunt for threats based on intelligence; perform regular rogue AP scans; identify potential incidents; analyze available data (leveraging TI and forensic techniques) to determine nature, extent, and impact; classify severity; activate appropriate response personnel according to this plan.
- 5.3 Containment: Implement timely and effective strategies to limit the scope and magnitude of the incident (e.g., isolating affected systems/networks, blocking malicious IP addresses/domains, disabling compromised accounts, disabling network ports connected to rogue APs). Containment strategies should prioritize preventing further damage while preserving critical evidence in a forensically sound manner. Document all containment actions, rationale, and timestamps.
- 5.4 Eradication: Identify and eliminate the root cause(s) of the incident (e.g., remove malware, securely delete unauthorized data, remove rogue devices, patch vulnerabilities, revoke compromised credentials). Verify the complete removal of the threat and any associated artifacts or persistence mechanisms.
- 5.5 Recovery: Restore affected systems, services, and data securely from trusted backups; validate system integrity and functionality through testing; implement enhanced monitoring and security controls on recovered systems; coordinate with business units to return systems to normal operation according to pre-defined Recovery Time Objectives (RTOs). Ensure vulnerabilities exploited during the incident are fully remediated before reconnection or restoration.
- 5.6 Post-Incident Activity (Lessons Learned): Conduct a formal post-mortem review within two weeks of incident resolution for all Critical and High severity incidents (and optionally for Medium/Low). Analyze the incident timeline, response effectiveness (including use of TI, handling of rogue APs, communication), root cause(s), and business impact. Document lessons learned, identify areas for improvement in security controls, policies, procedures, TI integration, and training. Assign owners and track remediation actions to completion. Update this IRP and associated documentation as needed (PCI DSS Req 12.10.6).
6. Communication and Notification
- Develop and maintain a detailed Communication Plan outlining internal (employees, management, board) and external (customers, partners, regulators, media, law enforcement, payment brands) notification procedures based on incident type, severity, and regulatory requirements.
- Define specific procedures, triggers, and timelines for notifying relevant parties, including mandatory reporting timelines for PCI DSS (Req 12.10.1), GDPR, state breach laws, and contractual obligations. Maintain contact information for all relevant parties (See Appendix Appendix C).
- Designate and train authorized spokespersons for internal and external communications. Ensure Legal Counsel reviews all external notifications related to breaches or significant incidents.
- Utilize pre-approved communication templates for various scenarios to ensure consistency, accuracy, and speed during incidents. Maintain secure communication channels for sensitive incident discussions.
7. Plan Testing and Maintenance
- Test the IRP comprehensively at least annually through various methods (e.g., tabletop exercises, functional drills, full simulations) covering different scenarios (e.g., ransomware, data breach, insider threat, DDoS, rogue AP detection/response, TPSP compromise) including those impacting the CDE and utilizing threat intelligence injects (PCI DSS Req 12.10.2).
- Review and update the IRP, associated playbooks, contact lists, and inventories at least annually, or more frequently based on lessons learned from incidents or tests, significant changes in the threat landscape (informed by TI), regulatory updates, or major organizational/technological changes (PCI DSS Req 12.10.6).
- Maintain detailed documentation of all testing activities, participants, results, identified gaps, and subsequent plan improvements. Track remediation actions from tests to completion.
Enforcement
- Failure to comply with this Incident Response Plan by employees, contractors, or TPSPs may result in disciplinary action, up to and including termination of employment or contract, access revocation, and/or legal action, in accordance with established HR policies and contractual agreements.
- Intentional failure to report a security incident, unauthorized interference with incident response activities, or unauthorized introduction of devices (like rogue APs) will be subject to severe disciplinary action.
- Exceptions to this plan require written justification detailing the necessity, associated risks, proposed compensating controls, and documented approval from the Incident Response Commander and the CISO/IT Director. Approved exceptions must be time-bound and reviewed periodically.
Revision History
Version |
Date |
Author |
Change Details |
1.0 |
[Date] |
[Author Name] |
Initial enterprise policy release |
2.0 |
[Date] |
[Author Name] |
Mature version incorporating TI & Rogue AP procedures |
[Next Ver #] |
[Date] |
[Author Name] |
[Summary of Changes] |
Approval
Name |
Title |
Signature |
Date |
[Exec Name] |
[Executive Title, e.g., CEO] |
|
[Date] |
[CISO Name] |
[CISO/IT Director Title] |
|
[Date] |
Appendix A: Incident Response Process Flow
Phase |
Key Activities |
Responsible Parties |
1. Preparation |
Maintain IRP & playbooks (TI-informed); Train CSIRT; Deploy/configure tools (incl. Wireless scanners, Forensics); Conduct TI-informed risk assessments; Maintain inventories (assets, APs); Establish secure comms |
CISO, IR Commander, InfoSec/IT, Legal |
2. Detection & Analysis |
Monitor alerts (SIEM, WIDS/IPS, EDR, TI); Conduct Rogue AP scans/Threat Hunts; Receive Reports; Triage & validate; Assess scope/impact (using TI); Classify; Activate CSIRT |
InfoSec/IT (SOC), IR Commander, CSIRT |
3. Containment |
Isolate systems/networks; Block malicious activity/traffic; Disable compromised accounts/rogue APs; Preserve evidence (forensically sound); Document actions & rationale |
CSIRT, IT/Systems Admin, Network Team |
4. Eradication |
Identify root cause(s); Remove malware/threats/rogue APs; Patch vulnerabilities; Reset credentials; Harden systems; Verify complete removal |
CSIRT, IT/Systems Admin, App Teams |
5. Recovery |
Restore systems from trusted backups; Validate data integrity/functionality; Implement enhanced monitoring; Coordinate return to normal ops (per RTO); Ensure vulnerabilities fixed |
IT/Systems Admin, Business Units, InfoSec |
6. Post-Incident |
Conduct lessons learned review; Document findings, root cause, recommendations; Update IRP, controls, inventories, TI sources; Track actions; Report to stakeholders |
IR Commander, CSIRT, All Stakeholders |
Appendix B: Incident Classification Matrix - Example Criteria
Severity |
Data Impact Criteria |
System/Operational Impact Criteria |
Business/Financial Impact Criteria |
Compliance/Legal/Reputational Impact |
Critical |
Confirmed CDE breach (any size); >10k PII/PHI records exposed/lost; Loss of critical IP; Widespread data integrity issues |
Core system compromise; CDE unavailable; Critical infrastructure failure; >8hrs major service outage affecting majority of users |
Significant financial loss (> $[X]); Major disruption to core business function |
PCI DSS breach confirmed; Likely GDPR/other major regulatory fine; Public disclosure required; Severe reputational damage |
High |
Potential CDE impact; 100-10k PII/PHI records exposed/lost; Sensitive internal data leak; Significant data integrity issues |
Key server/application compromise; Partial CDE impact; Key service degraded/unavailable for 4-8hrs; Rogue AP transmitting sensitive data |
Moderate financial loss ($[Y] - $[X]); Significant disruption to key department/service |
Potential regulatory inquiry; Legal action probable; Negative media attention possible; Mandatory notification likely |
Medium |
Non-sensitive internal data exposure; <100 PII/PHI records potentially exposed; Localized data integrity issues |
Non-critical server/multiple workstations compromised; Minor service degradation <4hrs; Isolated Rogue AP detected (no sensitive data tx) |
Limited financial impact (< $[Y]); Minor disruption to non-critical function |
Internal policy violation; Low legal/regulatory risk; Limited reputational impact |
Low |
No sensitive data involved; Public data potentially exposed; Minor data error (no compromise) |
Single endpoint malware (contained); Failed unauthorized access attempt; Rogue AP detected (guest network/isolated) |
No service disruption; Negligible financial impact |
No external impact; Internal notification only |
Appendix C: Contact List (Internal/External) - Template
(Maintain a separate, detailed, and regularly updated contact list accessible securely to the CSIRT and authorized personnel. This should include multiple contact methods and 24/7 availability where required.)
Role/Entity |
Primary Contact (Name, Title, Phone, Email) |
Secondary Contact (Name, Title, Phone, Email) |
Notes (e.g., 24/7, Area of Expertise) |
Internal |
|
|
|
Incident Response Commander |
|
|
24/7 On-Call Primary/Backup |
CSIRT Members (by role) |
(List individually or by function) |
|
24/7 Rotation; Skills: Forensics, NetSec, etc. |
Executive Management |
(CEO, CIO, etc.) |
|
Critical Incident Escalation Path |
Legal Counsel |
(Internal/External) |
|
Regulatory & Notification Lead |
Communications/PR |
|
|
Media & External Comms Lead |
Human Resources |
|
|
Personnel Issues Lead |
IT/Network/SysAdmin Teams |
(Leads/On-Call) |
|
Technical Support Leads |
Physical Security |
|
|
Facility Access, Rogue AP Location |
Business Unit Leaders |
(Per Dept/Function) |
|
Business Impact Assessment |
External |
|
|
|
Acquiring Bank (for PCI) |
(Relationship Manager/Security Contact) |
|
PCI Breach Notification |
Payment Card Brands |
(Breach Reporting Contacts - Visa, MC, etc.) |
|
PCI Breach Notification |
PCI Forensic Investigator (PFI) |
(Retained Vendor Contact Info) |
|
Required if CDE breach confirmed |
Law Enforcement (FBI, Local) |
(Cyber Crime Unit Contacts) |
|
If criminal activity suspected |
Regulatory Bodies |
(Contact Info per regulation - GDPR, State AG) |
|
Required Breach Notifications |
Cyber Insurance Provider |
(Broker/Claims Contact) |
|
Claim Reporting / IR Support |
External IR Support (Retainer) |
(Vendor 24/7 Hotline) |
|
Surge Capacity / Specialized Skills |
Threat Intelligence Providers |
(Vendor Support/Analyst Contact) |
|
Contextual Info during Incident |
Key TPSPs |
(Vendor Security/Incident Contacts) |
|
Incident Coordination |
Appendix D: PCI DSS 4.0.1 Incident Response Requirements Mapping
PCI DSS Requirement |
Plan Section(s) Covering Requirement |
Key Elements Addressed |
11.2.1 |
Policy Req 4 (Rogue AP Detection Process) |
Quarterly (or more frequent) wireless scanning process using appropriate tools, inventory comparison, investigation & remediation. |
12.10 |
Entire Plan |
Overall framework for immediate response to breaches affecting CDE and other systems. |
12.10.1 |
Purpose, Scope, Policy Req 1, 5, 6; Appendix Appendix Appendix A, C |
Roles, responsibilities, communication (incl. payment brands), procedures, business recovery links, backup refs, legal analysis. |
12.10.2 |
Policy Req 7 |
Annual plan testing (all elements of Req 12.10.1, including scenarios like Rogue AP, TPSP compromise). |
12.10.3 |
Roles & Responsibilities, Policy Req 2; Appendix Appendix C |
Designated personnel available 24/7 with backups. |
12.10.4 |
Policy Req 2 |
Annual training for staff with security breach response responsibilities. |
12.10.5 |
Policy Req 4 (Security Monitoring, Rogue AP Detection) |
Inclusion and monitoring of alerts from security systems (IDS/IPS, FIM, Firewalls, WIDS/WIPS, Anti-malware, etc.). |
12.10.6 |
Policy Req 5.6, Policy Req 7 |
Process to review/modify/evolve plan based on lessons learned (incl. TI insights) and industry developments at least annually. |
12.10.7 |
Policy Req 1, 5 (Handled under Data Breach classification & response) |
Procedures for responding to discovery of unprotected cardholder data (treated as a potential incident/breach). |
(Implied) |
Policy Req 3 (Threat Intelligence Integration), Policy Req 5.1, Req 5.2 |
Use of Threat Intelligence to enhance risk assessment, preparation, detection, analysis, and response capabilities. |
Appendix E: Incident Report Template
Appendix F: Incident Response Report Template
1. Executive Summary
- Incident ID:
- Date and time of incident:
- Date and time of detection:
- Incident type:
- Severity level:
- Systems/data affected:
- Brief description:
- Current status:
- Business impact:
- Key actions taken:
2. Incident Details
- Detailed chronology:
- Detection method:
- First responder actions:
- CSIRT activation time:
- Attack vectors and techniques:
- Systems and applications affected:
- Data potentially compromised:
- Evidence collected:
3. Response Actions
- Containment measures implemented:
- Investigation activities:
- Eradication steps:
- Recovery procedures:
- Communication and notifications:
- External parties involved:
- Timeline of key response actions:
4. Impact Assessment
- Technical impact:
- Business operations impact:
- Customer impact:
- Financial impact:
- Regulatory/compliance implications:
- Reputational impact:
5. Root Cause Analysis
- Identified vulnerabilities:
- Attack entry points:
- Contributing factors:
- Failed controls:
- Timeline of events leading to incident:
6. Recommendations
- Immediate actions:
- Short-term improvements:
- Long-term strategic changes:
- Policy and procedure updates:
- Training requirements:
- Technology improvements:
7. Lessons Learned
- What worked well:
- What didn't work well:
- Unexpected challenges:
- Response time analysis:
- Communication effectiveness:
- Resource adequacy:
8. Supporting Documentation
- Evidence inventory:
- Communications log:
- System logs and forensic data:
- Screenshots and technical findings:
- Third-party reports:
- Related incident tickets:
Appendix G: General Incident Response Checklist
Step |
Task |
Completed |
Responsible Party |
Notes |
Initial Response |
|
|
|
|
1 |
Record date and time of incident detection |
☐ |
First Responder |
|
2 |
Notify Incident Response Commander |
☐ |
First Responder |
|
3 |
Determine type of data potentially affected |
☐ |
Incident Response Commander |
|
4 |
Activate CSIRT and assign roles |
☐ |
Incident Response Commander |
|
5 |
Establish secure communication channel |
☐ |
Communications Coordinator |
|
Containment |
|
|
|
|
6 |
Isolate affected systems (without powering down) |
☐ |
Technical Lead |
|
7 |
Document system state before containment |
☐ |
Forensic Analyst |
|
8 |
Block malicious IP addresses/traffic |
☐ |
Network Specialist |
|
9 |
Disable compromised accounts |
☐ |
System Administrator |
|
10 |
Preserve logs and digital evidence |
☐ |
Forensic Analyst |
|
Assessment & Notification |
|
|
|
|
11 |
Determine scope of potentially affected data |
☐ |
Technical Lead |
|
12 |
Notify legal counsel |
☐ |
Incident Response Commander |
|
13 |
Determine regulatory notification requirements |
☐ |
Legal Counsel |
|
14 |
Engage external forensic experts if required |
☐ |
Legal Counsel |
|
15 |
Notify relevant external parties as required |
☐ |
Legal Counsel |
|
Investigation |
|
|
|
|
16 |
Create forensic images of affected systems |
☐ |
Forensic Analyst |
|
17 |
Analyze logs and system images |
☐ |
Forensic Analyst |
|
18 |
Document attack timeline and methods |
☐ |
Technical Lead |
|
19 |
Determine root cause |
☐ |
CSIRT |
|
20 |
Assess impact on systems and data |
☐ |
Technical Lead |
|
Eradication & Recovery |
|
|
|
|
21 |
Remove malware and unauthorized access points |
☐ |
Technical Lead |
|
22 |
Patch vulnerabilities |
☐ |
System Administrator |
|
23 |
Reset all credentials in affected environment |
☐ |
System Administrator |
|
24 |
Verify eradication through security scanning |
☐ |
Information Security Team |
|
25 |
Implement additional security controls |
☐ |
Information Security Team |
|
26 |
Restore systems from clean backups |
☐ |
System Administrator |
|
27 |
Conduct security testing before return to production |
☐ |
Information Security Team |
|
Post-Incident |
|
|
|
|
28 |
Document all incident response actions |
☐ |
Documentation Specialist |
|
29 |
Submit required reports to regulators |
☐ |
Legal Counsel |
|
30 |
Conduct post-incident review meeting |
☐ |
Incident Response Commander |
|
31 |
Update incident response procedures |
☐ |
Information Security Team |
|
32 |
Provide additional security awareness training |
☐ |
Information Security Team |
|