Incident Response SOP

​

Welcome to incident response

An incident rarely announces itself with perfect timing, complete information, and a neatly labeled folder. It may begin with a suspicious email, an unavailable system, an unfamiliar login, a missing device, an unexpected financial request, or the unsettling realization that information has been sent somewhere it should not have gone. This procedure establishes how Blevins Holdings identifies, reports, assesses, contains, investigates, resolves, and learns from security and operational incidents. The objective is simple:

• Protect people.
• Limit damage.
• Preserve evidence.
• Restore operations safely.
• Meet legal, contractual, and regulatory obligations.
• Communicate accurately.
• Prevent recurrence.

​

Purpose

This SOP provides a consistent response process for events that may affect:

• The confidentiality of company, employee, customer, client, or partner information.
• The integrity of systems, records, transactions, or data.
• The availability of critical technology, facilities, or business services.
• The safety of personnel.
• The security of company accounts, devices, networks, applications, or physical locations.
• The company’s legal, regulatory, contractual, financial, or reputational interests.

This procedure is intended to ensure that incidents are handled by authorized personnel using coordinated, documented, and risk-based methods.

​

Scope

This SOP applies to:

• Blevins Holdings employees, officers, managers, and contractors.
• Personnel of participating subsidiaries and affiliated entities.
• Company-owned and company-managed systems, applications, devices, networks, and facilities.
• Personally owned devices used to access company information or systems.
• Cloud platforms, hosted services, vendors, and other third-party systems used for company business.
• Security, privacy, operational, financial, physical, and technology events that may affect Blevins Holdings.

This SOP applies whether the event occurs:

• At a company facility.
• At a remote-work location.
• During business travel.
• In a cloud or vendor environment.
• On a company or personal device.
• During or outside normal business hours.

​

What counts as an incident

An incident is any actual or suspected event that has harmed—or could reasonably harm—the confidentiality, integrity, availability, safety, legality, or reliability of company operations, information, systems, or facilities. Examples include:

​

Cybersecurity incidents

• Suspected unauthorized access.
• Account compromise or credential theft.
• Malware, ransomware, spyware, or other malicious software.
• Phishing, impersonation, or social-engineering attacks.
• Suspicious logins or impossible-travel alerts.
• Unauthorized changes to systems or configurations.
• Denial-of-service attacks.
• Exploitation of a system vulnerability.
• Unapproved software or devices on company networks.
• Loss of administrative control over a system or account.
• Suspected insider misuse.

​

Privacy and data incidents

• Accidental disclosure of personal or confidential information.
• Information sent to the wrong recipient.
• Public exposure of restricted files or folders.
• Loss or theft of records, devices, or storage media.
• Unauthorized downloading, copying, or transfer of data.
• Improper disposal of records.
• Data accessed beyond a person’s authorized role.
• Suspected data exfiltration.
• Use of company information in an unauthorized artificial-intelligence or external service.

​

Technology and availability incidents

• Extended system or application outages.
• Failure of critical infrastructure.
• Loss of network, communications, or cloud services.
• Corruption or deletion of important records.
• Backup failure affecting recovery capability.
• Significant performance degradation.
• Failed software deployment with material operational impact.
• Loss of access to critical vendor systems.
• Repeated system instability suggesting a broader failure.

​

Physical and operational incidents

• Unauthorized entry to a company facility.
• Theft or loss of equipment.
• Tampering with physical security controls.
• Fire, flood, utility failure, or environmental damage affecting operations.
• Workplace threats or violence affecting business continuity.
• Loss of access to a critical facility.
• Disruption of essential operational processes.
• Vendor failure affecting a critical service.
• Fraudulent payment instructions or suspected financial manipulation.

​

Legal and compliance incidents

• Suspected violation of a legal, regulatory, contractual, or licensing requirement.
• Failure to meet a mandatory reporting or retention obligation.
• Loss or destruction of records subject to preservation.
• Unauthorized disclosure of legally privileged information.
• Government, law-enforcement, or regulatory contact relating to a suspected incident.
• Material violation of company security, privacy, or acceptable-use policy.

​

What is not ordinarily an incident

The following may be handled through normal support channels unless additional risk is present:

• A routine password reset.
• A single user unable to access a noncritical application.
• A known and scheduled service interruption.
• A minor device issue with no security or operational impact.
• A user question about system behavior.
• A previously approved and documented configuration change.

However, a routine support issue becomes a potential incident when it involves:

• Suspicious activity.
• Repeated failures.
• Sensitive information.
• Privileged access.
• Multiple users or systems.
• A critical business service.
• Fraud, impersonation, or manipulation.
• Possible policy or legal violations.

​

Immediate priorities

The response team will generally prioritize the following objectives in order:

1. Protect life, health, and physical safety.
2. Stop or limit active harm.
3. Protect critical operations and information.
4. Preserve evidence.
5. Determine scope and severity.
6. Meet legal, regulatory, contractual, and insurance obligations.
7. Restore services safely.
8. Communicate accurately and appropriately.
9. Document decisions and actions.
10. Identify corrective and preventive measures.

Safety always takes precedence over equipment, records, or system availability.

​

Reporting an incident

Anyone who becomes aware of an actual or suspected incident must report it immediately.

​

Primary reporting channels

• IT Security: security@blevinsholdings.com
• Emergency IT telephone: [Emergency number]
• Service desk: [Service desk channel]
• After-hours escalation: [After-hours instructions]
• Physical emergency: Call local emergency services first, then notify the appropriate company contact.
• Suspected misconduct or internal wrongdoing: [Office of Inspector General or ethics reporting channel]

​

Information to include

Provide as much of the following as is reasonably available:

• Your name and contact information.
• Date and time the issue was discovered.
• How the issue was discovered.
• Systems, accounts, devices, locations, or people involved.
• What was observed.
• Whether the activity appears to be continuing.
• Whether sensitive information may be involved.
• Whether anyone may be in immediate danger.
• Screenshots, error messages, filenames, sender addresses, or other relevant details.
• Actions already taken.
• Anyone else who has been notified.
• Whether a customer, client, vendor, regulator, or member of the public is aware of the matter.

Do not include passwords, authentication codes, encryption keys, or highly sensitive information in an ordinary email or support ticket.

​

What the person reporting should do

Unless immediate safety requires otherwise:

• Stop the activity that revealed the issue.
• Preserve relevant messages, files, screenshots, and records.
• Record the time and circumstances.
• Follow instructions from IT Security or the incident commander.
• Remain available for follow-up questions.
• Keep the matter confidential.
• Avoid changing, deleting, forwarding, or modifying potential evidence.
• Avoid discussing the incident with unauthorized parties.

​

What the person reporting should not do

Do not:

• Conduct an unauthorized investigation.
• Search another person’s account or device.
• Delete suspicious files or messages.
• run antivirus, cleanup, or forensic tools unless instructed.
• Reimage, reset, wipe, or replace the affected device.
• Power off a device unless directed or necessary for immediate safety.
• Contact the suspected attacker.
• Respond to ransom or extortion demands.
• Pay money or authorize payment.
• Notify customers, clients, regulators, insurers, law enforcement, or the media independently.
• Post about the incident on social media.
• Share screenshots or details in broad chat channels.
• Assume the incident is resolved because visible symptoms stop.

A well-intentioned amateur investigation can destroy evidence, expand the damage, or complicate legal and regulatory obligations. Restraint is not inaction. It is discipline.

​

Lost or stolen devices

When a company device or a personal device containing company information is lost or stolen:

1. Report it immediately.
2. Provide the device type, owner, telephone number, serial number, and last known location if available.
3. State whether the device was encrypted and whether it was logged in.
4. State whether company accounts, email, files, or applications were accessible.
5. Do not attempt a personal recovery that could create a safety risk.
6. Follow instructions regarding remote lock, account reset, device tracking, or remote wipe.
7. File a police report when directed or reasonably required.

​

Suspected phishing or account compromise

When a suspicious message or account event is identified:

• Do not click additional links or open attachments.
• Do not reply to the sender.
• Report the message through the approved phishing-reporting process.
• Tell IT Security whether credentials were entered.
• State whether an attachment was opened or software was installed.
• State whether an authentication request was approved.
• Follow instructions for password reset and session termination.
• Do not reuse the compromised password elsewhere.

If a payment, payroll, banking, or vendor-information change was requested, notify Finance immediately through a known and independently verified channel.

​

Suspected ransomware or active malware

If ransomware, unusual encryption, or rapidly spreading malware is suspected:

1. Disconnect the affected device from wired and wireless networks when it can be done safely.
2. Do not power the device off unless instructed.
3. Do not connect storage devices or backups.
4. Do not attempt to decrypt or remove the malware.
5. Contact IT Security immediately by telephone or another approved out-of-band method.
6. Record visible messages, filenames, times, and affected systems without interacting further.
7. Preserve any ransom message or communication.
8. Await instructions.

​

Incident severity levels

Severity is determined by the incident commander in consultation with relevant response functions. Classification may change as new information becomes available.

​

Severity considerations

The response team should consider:

• Threat to life or safety.
• Whether the event is active.
• Sensitivity and volume of information involved.
• Number and type of affected systems or users.
• Criticality of the affected business service.
• Presence of privileged, executive, financial, or administrative accounts.
• Evidence of persistence, lateral movement, or exfiltration.
• Customer, client, employee, or public impact.
• Legal, regulatory, contractual, or insurance obligations.
• Financial loss or fraud exposure.
• Likelihood of media or public attention.
• Involvement of a regulated or government customer.
• Ability to contain the event.
• Availability of reliable backups and recovery methods.
• Whether the event involves a vendor or subsidiary.
• Possibility of insider activity.

​

Incident-response roles

​

Incident commander

The incident commander directs the response and is responsible for:

• Confirming or assigning severity.
• Establishing response priorities.
• Assigning roles and workstreams.
• Approving containment and recovery actions.
• Coordinating response functions.
• Maintaining an operational timeline.
• Scheduling response meetings.
• Escalating decisions requiring executive authority.
• Confirming closure criteria.

The incident commander is normally assigned by IT Security for technology and security incidents. Another qualified leader may be assigned when the event is primarily physical, operational, legal, or safety-related.

​

IT Security

IT Security is responsible for:

• Technical triage and investigation.
• Threat analysis.
• Account and system containment.
• Evidence preservation.
• Log collection and review.
• Coordination with forensic specialists.
• Security remediation.
• Validation of technical recovery.
• Security monitoring after restoration.

​

Information Systems and Technology

IST is responsible for:

• Infrastructure and application support.
• Service restoration.
• Backup and recovery operations.
• Vendor coordination.
• Configuration changes.
• System validation.
• Operational documentation.

​

Legal, Risk and Compliance

Legal, Risk and Compliance is responsible for:

• Preserving legal privilege when appropriate.
• Advising on legal and regulatory obligations.
• Determining notification requirements.
• Coordinating with law enforcement or regulators.
• Reviewing contracts and reporting deadlines.
• Advising on evidence preservation.
• Coordinating insurance notification when required.
• Reviewing external communications.
• Assessing legal and compliance risk.

​

General Counsel

The General Counsel advises on legal exposure, privilege, notification, regulatory contact, law-enforcement engagement, litigation risk, and external legal support.

​

Office of Inspector General

The Office of Inspector General may:

• Review suspected misconduct, fraud, abuse, retaliation, or control failures.
• Conduct or coordinate independent investigations.
• Preserve investigative independence.
• Recommend corrective or disciplinary action.
• Coordinate with Legal, Human Resources, Finance, or other oversight functions.

​

Global Human Resources

Global Human Resources supports incidents involving:

• Employee conduct.
• Workplace safety.
• Personnel actions.
• Employee communications.
• Insider risk.
• Harassment, retaliation, or policy violations.
• Employee assistance and support.

​

Communications and Public Affairs

Communications and Public Affairs is responsible for:

• Preparing approved internal and external communications.
• Coordinating media responses.
• Maintaining consistent messaging.
• Monitoring public reporting and reputational impact.
• Supporting executive and stakeholder communications.

​

Finance

Finance supports:

• Fraud containment.
• Payment holds.
• Banking notifications.
• Financial-impact assessment.
• Insurance and loss documentation.
• Vendor-payment verification.
• Recovery of improperly transferred funds.

​

Business and subsidiary leaders

Affected leaders are responsible for:

• Identifying operational impact.
• Prioritizing critical services.
• Providing knowledgeable personnel.
• Supporting business-continuity decisions.
• Communicating with affected teams as authorized.
• Verifying restoration of business processes.

​

Incident-response procedure

​

Evidence preservation

Evidence must be preserved in a manner appropriate to the incident. Personnel must not:

• Delete suspicious messages.
• Clear logs.
• Wipe or reimage devices.
• Alter timestamps.
• Modify relevant records.
• Destroy physical evidence.
• Remove data from company custody without authorization.
• Conduct forensic analysis using unapproved tools.
• Share evidence with unauthorized parties.

The response team should record:

• What was collected.
• Who collected it.
• When and where it was collected.
• How it was transferred.
• Where it is stored.
• Who accessed it.
• Any changes made during analysis.

​

Communication rules

Incident communications must be accurate, controlled, and appropriate to the risk.

​

Approved communication methods

The incident commander will designate approved channels, which may include:

• A restricted incident-management platform.
• A secure conference bridge.
• A limited-access chat channel.
• An out-of-band telephone or messaging channel.
• An approved email distribution list.
• In-person meetings.

Do not assume ordinary company email or messaging is secure during an active compromise.

​

Internal communications

Internal updates should:

• Be limited to people with a legitimate need to know.
• Use the incident identifier where practical.
• Distinguish confirmed facts from assumptions.
• Avoid unnecessary personal information.
• State required actions clearly.
• Include the time of the next update.
• Be preserved as part of the incident record.

​

External communications

No employee may independently communicate incident details to:

• Customers or clients.
• Vendors or business partners.
• Regulators.
• Law enforcement.
• Insurance carriers.
• News media.
• Investors.
• Members of the public.

External communications must be coordinated through the incident commander and the appropriate Legal and Communications functions.

​

Customer, client, and regulatory notification

Legal, Risk and Compliance will determine whether notification is required under:

• Applicable law or regulation.
• Customer or client contracts.
• Insurance policies.
• Government agreements.
• Industry requirements.
• Court orders.
• Licensing obligations.
• Other binding commitments.

Notification decisions should consider:

• The type of information involved.
• The affected individuals or organizations.
• The likelihood of harm.
• The date of discovery.
• Statutory or contractual deadlines.
• Required content and delivery methods.
• Coordination across jurisdictions.
• Whether law enforcement has requested a delay.

No employee should promise notification, timing, compensation, remediation, or other action without authorization.

​

Third-party and vendor incidents

When a vendor or service provider reports an incident that may affect Blevins Holdings:

1. Open an internal incident record.
2. Obtain the vendor’s incident identifier and primary contact.
3. Determine affected services, systems, and information.
4. Request available timelines and indicators.
5. Review contractual notification and cooperation requirements.
6. Identify internal dependencies.
7. Consider temporary suspension or isolation of the vendor connection.
8. Coordinate Legal, security, privacy, and business review.
9. Track vendor remediation and evidence.
10. Confirm restoration before returning to normal operations.

The vendor’s declaration that an event is “contained” does not automatically close the Blevins Holdings incident.

​

Business-continuity coordination

When an incident disrupts critical services, the incident commander should coordinate with Enterprise Operations and affected business leaders to:

• Identify essential functions.
• Establish restoration priorities.
• Activate manual or alternate processes.
• Reassign personnel or resources.
• Communicate operational limitations.
• Protect service commitments.
• Document temporary controls.
• Determine whether continuity or disaster-recovery plans should be activated.

​

Law-enforcement contact

Contact with law enforcement should be coordinated through General Counsel, Legal, Risk and Compliance, or another expressly authorized executive. Emergency situations involving immediate danger may be reported directly to emergency services. The response team should preserve:

• Contact names.
• Agency information.
• Case or report numbers.
• Requests for evidence.
• Preservation instructions.
• Disclosure approvals.
• Dates and times of communication.

​

Cyber-insurance notification

When an incident may be covered by insurance, Legal, Risk and Compliance or another designated owner should review notification requirements promptly. Certain policies may require:

• Notice before engaging outside specialists.
• Use of approved forensic, legal, or communications vendors.
• Insurer approval before incurring specified costs.
• Preservation of expense and loss records.
• Cooperation with insurer-appointed specialists.

Failure to follow policy conditions may affect coverage.

​

Status updates

For significant incidents, the incident commander should establish a regular update cadence. A status update should generally include:

​

Post-incident review

A post-incident review should determine what occurred, why it occurred, how the response performed, and what must change. The review should cover:

​

Incident summary

• Date and time of discovery.
• Detection source.
• Final severity.
• Duration.
• Affected systems, information, operations, and stakeholders.
• Business and financial impact.
• Notification obligations.
• Final status.

​

Timeline

The timeline should document:

• Initial event.
• Detection.
• Reporting.
• Escalation.
• Containment.
• Investigation milestones.
• Major decisions.
• Notifications.
• Restoration.
• Closure.

​

Root cause

The review should identify:

• Immediate technical or operational cause.
• Contributing conditions.
• Failed or missing controls.
• Human, process, vendor, technology, and governance factors.
• Why the event was not prevented or detected sooner.
• Whether similar risk exists elsewhere.

​

Response effectiveness

Evaluate:

• Speed of detection.
• Speed of reporting.
• Accuracy of severity assignment.
• Effectiveness of containment.
• Evidence preservation.
• Coordination among teams.
• Quality of communications.
• Recovery performance.
• Vendor cooperation.
• Legal and compliance handling.
• Availability of documentation and contact information.

​

Corrective actions

Corrective actions should be:

• Specific.
• Assigned to an owner.
• Given a due date.
• Prioritized by risk.
• Tracked to completion.
• Verified for effectiveness.

Possible actions include:

• Technical remediation.
• Policy or procedure changes.
• Additional monitoring.
• Training.
• Vendor changes.
• Access-control improvements.
• Backup improvements.
• System redesign.
• Contract amendments.
• Business-continuity enhancements.
• Disciplinary or administrative action.
• Additional testing or exercises.

​

Incident documentation

The official incident record should include, as applicable:

• Incident identifier.
• Reporter information.
• Discovery date and time.
• Severity history.
• Incident commander.
• Response-team members.
• Affected assets and information.
• Timeline of events.
• Decisions and approvals.
• Evidence inventory.
• Communications.
• Legal and regulatory analysis.
• Containment and remediation actions.
• Recovery validation.
• Cost and impact estimates.
• Notification records.
• Post-incident review.
• Corrective-action plan.
• Closure approval.

Incident records must be stored in an approved restricted-access repository.

​

Confidentiality

Incident information may contain:

• Sensitive security details.
• Personal information.
• Legal advice.
• Privileged communications.
• Personnel information.
• Trade secrets.
• Customer or client information.
• Evidence of suspected wrongdoing.
• Information that could enable further attacks.

Access must be limited to individuals with a legitimate need to know. Personnel must not:

• Forward incident records to personal accounts.
• Download records to unapproved devices.
• discuss incident details casually.
• Share information with uninvolved colleagues.
• Use incident details for presentations or training without approval.
• Retain personal copies after the matter is closed.

​

Metrics and program improvement

IT Security should periodically review incident-response metrics, which may include:

• Number of incidents by category and severity.
• Time to detect.
• Time to report.
• Time to contain.
• Time to recover.
• Repeated root causes.
• Number of affected systems or users.
• Corrective-action completion rates.
• Vendor-response performance.
• Backup and restoration effectiveness.
• Phishing-reporting rates.
• Regulatory or contractual notifications.
• Business interruption and financial impact.

Metrics should be used to improve controls, training, staffing, technology, and response capability—not to discourage good-faith reporting.

​

Exercises and testing

Blevins Holdings should periodically test incident-response capability through:

• Tabletop exercises.
• Phishing simulations.
• Backup-restoration tests.
• Technical response drills.
• Vendor-response exercises.
• Business-continuity exercises.
• Executive decision simulations.
• Communications exercises.
• Contact-list validation.

Exercises should result in documented findings and tracked corrective actions.

​

Escalation guide

​

Responsibilities of all personnel

Everyone covered by this SOP is expected to:

• Report suspected incidents promptly.
• Provide truthful and complete information.
• Follow response-team instructions.
• Protect incident confidentiality.
• Preserve relevant evidence.
• Avoid unauthorized investigation or remediation.
• Cooperate with authorized reviews.
• Complete required training.
• Keep emergency contact information accessible.
• Report suspected retaliation or interference.

​

Non-retaliation

Retaliation against an individual who reports a suspected incident in good faith, preserves evidence, participates in an investigation, or follows this procedure is prohibited. Retaliation concerns should be reported to Global Human Resources, Legal, Risk and Compliance, or the Office of Inspector General.

​

Exceptions

Exceptions to this SOP must be:

• Legally permissible.
• Based on a documented operational need.
• Risk-assessed.
• Approved by the SOP owner and other required authorities.
• Limited in scope and duration.
• Supported by appropriate compensating controls.

Urgency does not eliminate the need for documentation. It merely makes timely documentation more impressive.

​

Related documents

• Information Security Policy.
• Acceptable Use Policy.
• Data Privacy Policy.
• Business Continuity Plan.
• Disaster Recovery Plan.
• Records Management Policy.
• Investigation and Non-Retaliation Policy.
• Vendor Risk Management Policy.
• Crisis Communications Plan.
• Cyber-Insurance Response Guide.
• Physical Security Procedures.
• Evidence Handling Standard.
• Data Breach Notification Procedure.

​

SOP administration

​

Revision history

---

​

A final word

Incidents are managed best when people report promptly, preserve facts, follow instructions, and resist the temptation to improvise heroically. Remain calm. Protect people. Escalate early. Preserve evidence. Communicate carefully. Restore services only when they are ready. And remember: A well-managed incident is not one in which nothing went wrong. It is one in which the organization responded with speed, discipline, accuracy, and impeccable coordination.