Security Incident Response Procedure
Document Information |
|
Document ID | Security_Incident_Response_Procedure |
Version | 2.1 |
Status | Approved |
Effective Date | Apr 6, 2026 |
Owner | Chief Information Security Officer (CISO) |
Review Cycle | Annual |
Replaces | Security Incident Response Procedure v1.0 (Feb 2022); Security Incident Response Tracking Procedure v1.0 (Feb 2024) |
Approved By | Eric Zematis, CISO |
Approval Date | Apr 6, 2026 |
1. Purpose
This procedure defines required actions for detecting, responding to, containing, recovering from, and documenting a security incident at Lehigh University. It also consolidates the requirements for tracking security incidents in the Jira Security Incident (SI) project.
This procedure is activated for security incidents classified S1 (Critical) or S2 (High) per the Lehigh Incident Response Standard severity scale. S3, S4, and S5 security events follow the lightweight response defined in Section 4.1. This procedure runs in parallel with the General Incident Response Procedure when an incident also involves service disruption.
2. Scope
This procedure applies to all Lehigh University personnel who may be involved in responding to a security incident, including:
LTS staff and the Information Security team
The Office of General Counsel (OGC)
The Crisis Management Team (CMT) and University Communications
Finance and Accounts Payable
Any third-party vendor or contractor acting on behalf of Lehigh during incident response
This procedure also applies when Lehigh receives a security incident notification from a third-party vendor or service provider, regardless of whether Lehigh systems have been directly confirmed as affected.
Sensitive Investigations Incidents requiring private or legal investigation (executive account compromise, HR-involved cases, law enforcement-requested investigations) SHALL NOT be documented in the Jira SI project and SHALL NOT follow this procedure's standard communication steps. Contact the CISO directly for out-of-band handling before taking any documented action. |
3. Roles and Responsibilities
Role | Responsibilities During a Security Incident |
Chief Information Security Officer (CISO) | Overall security incident response owner and decision authority.
|
Information Security Team | Technical investigation lead.
|
IT Operations (LTS) | Technical execution for service-impacting containment and recovery.
|
Office of General Counsel (OGC) | Legal authority including all regulatory, litigation, and law enforcement matters.
|
Director of Risk Management | CMT facilitator and initial point of contact for CMT activation.
|
Crisis Management Team (CMT) |
|
Finance / Accounts Payable | Financial fraud response and insurance documentation.
|
Incident Owner (per General IR Procedure) | Declared per the General IR Procedure when the incident has a service impact component.
|
4. What Triggers This Procedure
This procedure is triggered for security incidents classified S1 (Critical) or S2 (High) per the Incident Response Standard severity scale. S3, S4, and S5 security events are handled per Section 4.1 and do not invoke the full procedure. Common S1/S2 triggers include:
Severity | Security Incident Indicators |
Critical (Severity 1 - S1) | Active ransomware or destructive malware; confirmed exfiltration of regulated data; financial fraud confirmed at any amount |
High (Severity 2 - S2) | Confirmed unauthorized access to privileged accounts; vendor breach with confirmed Lehigh data access; BEC with pending or executed wire transfer |
4.1 Lower Classified Security Events
Security events classified S3, S4, or S5 do not invoke this procedure.
Severity | Security Incident Indicators |
Medium (Severity 3 - S3) | Suspected security incident under active investigation; vendor notification with unclear Lehigh impact; credential compromise of limited scope |
Low (Severity 4 or 5 - S4/5) | Security event under monitoring; suspicious activity not yet confirmed as compromise |
The following lightweight response applies:
Severity | Response Required | Escalation Threshold |
S3 (Medium) | Notify CISO. Open a Jira SI ticket and document findings. Monitor for escalation. No OGC, LUPD, or CMT engagement unless severity increases. | If investigation confirms S2 or S1 indicators, immediately reclassify and invoke the full procedure. |
S4/S5 (Low) | Confirmed unauthorized access to privileged accounts; vendor breach with confirmed Lehigh data access; BEC with pending or executed wire transfer | If activity escalates or a pattern emerges suggesting broader compromise, reclassify to appropriate severity and engage CISO. |
When in doubt, treat it as a security incident. Do not delay response while trying to confirm classification. Notify the CISO immediately and classify after initial triage. |
5. Phase 1: Detection and Initial Response
Upon identifying a suspected security incident, the following steps SHALL be completed in sequence. Do not skip steps or defer them pending confirmation.
Step 1 Notify the CISO Immediately Notify the CISO immediately upon identifying a suspected security incident. Do not wait for confirmation before notifying.
What to communicate: What you observed, when you observed it, what systems or accounts may be involved, and any immediate actions already taken. |
Step 2 Preserve Evidence Evidence preservation takes priority over service restoration for security incidents. Premature remediation destroys forensic value and can violate insurance policy requirements.
|
Step 3 Open a Jira SI Ticket The Information Security team SHALL create a Jira SI ticket within one hour of CISO notification. See Section 10 for required fields and minimum description template.
|
Step 4 Declare in Slack #incidentmanagement (if service-impacting) If the security incident also constitutes a service disruption affecting users, the Incident Owner SHALL declare in Slack #incidentmanagement per the General Incident Response Procedure. Both procedures run in parallel. Zoom recording note: For security incidents with potential legal, insurance, or regulatory implications, the CISO or OGC SHALL be consulted before any Zoom sessions are recorded. Recordings of security incident response may be discoverable in litigation or complicate insurance claims. |
Step 5 Classify Severity Apply the security incident severity classification from the Incident Response Standard (S1–S5). Severity determines escalation timing and external notification requirements.
|
Step 6 Notify Cyberinsurance Carrier
The carrier will provide guidance on approved forensic vendors, legal counsel, and documentation requirements. Do not engage external forensic or legal vendors without carrier authorization as this can void coverage. |
Step 7 Assess Initial Scope Conduct an initial scope assessment to inform containment decisions. The CISO directs this assessment with support from the Information Security team.
sDo not take containment action until scope assessment is complete, unless active harm is ongoing. |
6. Phase 2: Escalation and Notification
Escalation and notification run in parallel with containment. Do not defer escalation until after containment is complete.
6.1 Office of General Counsel (OGC)
The CISO SHALL engage OGC when any of the following apply:
The incident may trigger mandatory external notification obligations (PA breach notification, FERPA, federal research reporting)
A vendor breach has affected or may have affected Lehigh data
The incident involves confirmed or suspected financial fraud
Law enforcement has contacted Lehigh or is anticipated to do so
The incident may result in litigation or a regulatory inquiry
A legal hold may be required to preserve evidence
Timelines
OGC engagement for S1 incidents: within 8 hours of incident declaration.
OGC engagement for S2 incidents: within the same business day as incident declaration.
6.2 LUPD
The CISO SHALL engage LUPD when any of the following apply:
The incident involves confirmed or suspected criminal activity
Financial fraud has been confirmed at any dollar amount
Law enforcement coordination (local, state, or federal) is required
LUPD SHALL be notified before Lehigh voluntarily contacts external law enforcement agencies (FBI, USSS, etc.). LUPD coordinates that engagement.
6.3 Crisis Management Team (CMT)
The Director of Risk Management facilitates the CMT and is the initial point of contact for CMT activation. The CISO or CTO SHALL contact the Director of Risk Management when any of the following apply:
The incident is classified S1
Regulated data (student records, PHI, PII) has been confirmed or suspected as exposed
A media inquiry has been received or is anticipated
A public statement is required
► For S1 incidents, the Director of Risk Management SHALL be notified within 8 hours of incident declaration. The Director of Risk Management determines whether to notify the CMT. Members of the CMT will determine if a meeting is required.
► All external communications (media statements, public notices, Board briefs) require CMT approval before release. The CISO does not issue external communications independently.
► Director of Risk Management contact: Kim Nimmo, 610.758.3899, kin217@lehigh.edu.
7. Phase 3: Containment
Containment actions limit ongoing harm. All containment decisions require CISO authorization before execution, with one exception: if active destructive activity is occurring (e.g., active ransomware encryption) and the CISO cannot be reached, IT Operations may take immediate isolation action and SHALL notify the CISO within 15 minutes.
System and account isolation. Isolate affected systems or accounts as directed by the CISO. Before isolating, evaluate blast radius — confirm what other services or users depend on the affected system. Document every isolation action in the Jira SI ticket with timestamp and authorizing party.
Vendor disconnection. For vendor-originated incidents where a third-party service may be the attack vector, the CISO determines whether to suspend vendor connectivity. IT Operations SHALL document all dependent systems before disconnecting and SHALL notify affected users per the General IR Procedure.
Account remediation. Force password resets for confirmed or suspected compromised accounts. For senior leadership accounts, resets require explicit CISO authorization. Notify affected account holders via an independently verified communication channel — not via the potentially compromised email account.
BEC and financial fraud containment. If business email compromise or financial fraud indicators are present, immediately invoke Section 7.1 (Financial Fraud Response) in parallel with other containment steps.
Enhanced monitoring. Implement enhanced monitoring for affected systems and accounts. Document what monitoring was added, in what tool, and what alert criteria were set.
7.1 Financial Fraud Response
When BEC, wire fraud, or unauthorized financial transaction is suspected or confirmed:
Verify the transaction independently. Finance SHALL contact the purported requestor using a phone number independently obtained from Lehigh's directory — not from the suspicious email. Confirm whether the request was legitimate.
Attempt wire recall immediately. If a wire transfer may be fraudulent, Finance SHALL contact Lehigh's bank wire recall team immediately. Wire recall windows are narrow. Bank contact for wire recall.
Freeze pending transactions. Finance SHALL not process any additional transactions related to the incident until finance authorize resumption.
Notify financial leadership. Finance SHALL notify the CFO within the same business day.
Document for insurance claim. Finance SHALL preserve all records related to the fraudulent transaction: original email, approval chain, wire confirmation, bank communications, and timeline of events. This documentation is required for the cyberinsurance claim.
7.1.1 Financial Fraud Federal Resources
The FBI: Recovery Asset Team (RAT)
The FBI’s Internet Crime Complaint Center (IC3) houses the Recovery Asset Team. They work directly with financial institutions to freeze "kill" fraudulent transfers.
You must file a formal complaint at IC3.gov.
You will need the transaction dates, amount, sender/receiver bank names, account numbers, and the SWIFT/routing numbers.
After filing online, call the Philadelphia Field Office (philadelphia.fbi.gov 215.418.4000 and ask to speak with a financial crimes agent regarding the complaint you just filed.
2. The Secret Service: Global Investigative Operations Center (GIOC)
The Secret Service handles a massive amount of Business Email Compromise (BEC) and wire fraud cases. They focus heavily on the "Kill Chain" to stop the movement of illicit funds.
Contact the Philadelphia Field Office 215.861.3300
Ask for the Cyber Fraud Task Force (CFTF). They are the specific specialists who handle electronic fund recovery.
8. Phase 4: External Notification Obligations
OGC leads notification determination. The CISO provides factual incident information. All notifications require OGC review and approval before submission. The following is a reference guide for notification triggers. Note: it does not replace OGC legal analysis.
Notification | Trigger | Deadline (from discovery) | Lead |
Cyberinsurance Carrier | S1 or S2 incident declaration | 24 hours for initial notice; 72 hours for incident report (verify with carrier) | CISO to Director of Risk Management |
Pennsylvania Attorney General (73 P.S. § 2303) | Unauthorized access to personal information of Pennsylvania residents where misuse is reasonably possible | Without unreasonable delay; notify AG without unreasonable delay after notifying affected individuals | OGC |
Affected Individuals (PA law) | Same trigger as PA AG notification | Without unreasonable delay | OGC + CMT |
FERPA Breach Notification | Unauthorized disclosure of student education records | OGC determines applicability; FERPA does not impose a universal deadline but prompt notice is expected | OGC |
Federal Research Agency | Affected systems handle federally funded research data; agency-specific requirements apply | Varies by award terms; Office of Research must be engaged | Office of Research |
FBI / Law Enforcement | Voluntary cooperation or receipt of legal process | Upon CISO + OGC determination | OGC (authorizes all law enforcement communications) |
Vendor | Lehigh confirms incident scope; may trigger counter-notification obligations under MSA | Per contract terms | CISO + OGC + Contract Owner @ Lehigh |
Law enforcement communications: All communications with law enforcement whether voluntary or compulsory will be coordinated through OGC. No Lehigh employee SHALL provide records, logs, or statements to law enforcement without OGC authorization. Upon receipt of a subpoena or court order, OGC is the sole point of contact for response. |
9. Phase 5: Recovery
9.1 Vendor Reconnection
Before reconnecting any vendor service that was suspended as a containment measure, the following criteria SHALL be met:
The vendor has provided a remediation report describing: the root cause, the timeline of the threat actor's access, corrective controls implemented, and independent forensic confirmation of threat actor eradication.
The CISO has reviewed the remediation report and determined it is sufficient. The CISO MAY require additional evidence or a third-party attestation before approving reconnection.
OGC has confirmed that reconnection does not conflict with any legal hold, law enforcement request, or open insurance investigation.
IT Operations has documented all systems that will be affected by reconnection and confirmed monitoring is in place.
9.2 System Restoration
IT Operations SHALL validate backup integrity before restoring from backup. A restore test SHALL be performed in a non-production environment where possible.
Restored systems SHALL not be reconnected to the production environment until the CISO confirms the threat has been eradicated from the production environment.
9.3 Post-Recovery Monitoring
Enhanced monitoring SHALL remain in place for a minimum of 30 days following system restoration. The Information Security team SHALL define the monitoring scope and alert criteria and document them in the Jira SI ticket.
10. Jira SI Project — Documentation Requirements
All security incidents (except sensitive investigations per Section 2) SHALL be documented in the Jira Security Incident (SI) project throughout the response lifecycle. This section consolidates the requirements previously maintained in the Security Incident Response Tracking Procedure (v1.0, Feb 2024), which is retired by this document.
10.1 Access
SI project access is restricted to: TIO, Information Security team, CISO, and CTO.
► When OGC or Finance requires access to specific SI documentation (e.g., for insurance claim or legal review), the CISO SHALL provide read access on a need-to-know basis or export and share relevant records through a secure channel.
► SI project tickets SHALL NOT be shared with external parties (vendors, law enforcement, insurers) without OGC review and CISO authorization.
10.2 Required Fields
Field | Requirement |
Summary | Brief, descriptive title. Format: [Incident Type] — [Affected System/Party] — [Date]. Example: Vendor Breach — IdentiBridge — 2025-03-10 |
Severity | S1–S5 per Incident Response Standard. Update if severity changes. |
Incident Owner | Assigned at time of ticket creation. Named individual, not a team. |
Date/Time Opened | Date and time the ticket was created. |
Date/Time Closed | Date and time the incident was declared resolved. Leave blank until closure. |
Description | Minimum content per Section 10.3 below. |
Status | Updated at each phase transition: Open → Containment → Investigation → Recovery → Closed. |
10.3 Minimum Description Template
The Jira SI ticket description SHALL contain at minimum the following information at time of creation, updated as the incident develops:
Incident Description Template Incident Discovered: [Date, time, and by whom] How Discovered: [Monitoring alert / vendor notification / user report / other] Systems and Accounts Potentially Affected: [List] Data Types Potentially Exposed: [PII / FERPA records / research data / financial data / credentials / none confirmed] Immediate Actions Taken: [Numbered sequence with timestamps] Individuals Notified: [Name, role, date/time of notification] Cyberinsurer Notified: [Yes / No / Pending — date if yes] OGC Engaged: [Yes / No / Pending — date if yes] LUPD Engaged: [Yes / No / Pending — date if yes] CMT Notified: [Yes / No / Pending — date if yes] Open Questions / Unknowns: [List] Current Status: [One sentence] |
10.4 Update Frequency
Severity | Minimum Update Frequency | Who Updates |
S1 | Every 4 hours during active incident | Information Security team or CISO designee |
S2 | Every business day | Information Security team |
S3 | Every 2 business days | Information Security team |
S4/S5 | At each material development | Information Security team |
11. Post-Incident
11.1 Blameless Retrospective
Following incident closure, the CISO SHALL initiate the blameless retrospective process per the General Incident Response Procedure within 5 business days.
In addition to the standard retrospective fields, the security incident retrospective SHALL include:
External notification obligations triggered and whether they were met on time
Insurance claim status and documentation gaps identified
IR procedure gaps identified during the incident
Recommended procedure updates with specific document and section references