> ## Documentation Index
> Fetch the complete documentation index at: https://docs.blevinsholdings.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Incident Response SOP
> The approved procedure for identifying, reporting, containing, investigating, and resolving security and operational incidents at Blevins Holdings.
**SOP owner:** Information Systems and Technology — IT Security
**Supporting functions:** Enterprise Operations; Legal, Risk and Compliance; Office of Inspector General; Communications and Public Affairs
**Effective date:** July 21, 2026
**Last reviewed:** July 21, 2026
**Next review due:** July 21, 2026
## 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.
When in doubt, report the matter as a potential incident. A prompt false alarm is far preferable to a genuine crisis left waiting politely in the corridor.
## 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.
A reported event does not need to be confirmed as an incident before it is escalated. Confirmation is the responsibility of the authorized response team.
## 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](mailto: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]
Do not delay a report while attempting to confirm every fact. Report what is known, identify what is uncertain, and allow the response team to determine the next steps.
### 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.
No employee may communicate with an extortionist, negotiate a demand, or make a payment without explicit authorization through the incident-response, legal, executive, and financial approval process.
## Incident severity levels
Severity is determined by the incident commander in consultation with relevant response functions. Classification may change as new information becomes available.
| Level | General description | Examples | Initial response objective |
| ----------------- | ------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------ |
| **P1 — Critical** | Active or imminent event with severe enterprise, safety, legal, financial, or reputational impact | Confirmed breach; active ransomware; material data exfiltration; compromise of critical infrastructure; widespread outage; active threat to personnel | Immediate, continuous response |
| **P2 — High** | Significant actual or suspected impact requiring urgent coordinated action | Suspected breach; privileged-account compromise; major system outage; sensitive data exposure; critical vendor disruption | Begin response within 1 hour |
| **P3 — Medium** | Limited or contained impact with no current evidence of material enterprise harm | Isolated malware; limited account compromise; contained privacy error; noncritical outage affecting a department | Begin response within 4 hours |
| **P4 — Low** | Minor anomaly or policy event presenting limited immediate risk | Blocked phishing attempt; low-risk device issue; minor control failure; suspicious event requiring review | Begin response within 24 hours |
### 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
The incident is reported through an approved channel.
The receiving team should:
* Record the date and time.
* Acknowledge receipt.
* Obtain immediate safety and impact information.
* Create an incident record.
* Provide initial instructions to the reporter.
* Escalate urgent matters immediately.
IT Security or the appropriate response function performs an initial assessment.
Triage should determine:
* What occurred or may have occurred.
* Whether the event is active.
* What systems, people, information, or facilities may be affected.
* Whether immediate containment is required.
* Whether sensitive data may be involved.
* Whether the matter may involve fraud, misconduct, safety, or legal risk.
* Which teams must be engaged.
The response team assigns a provisional severity level and names an incident commander.
For significant incidents, the incident commander establishes:
* A response team.
* A secure communication channel.
* A meeting cadence.
* An incident timeline.
* Decision and approval authority.
* Technical, legal, operational, and communications workstreams.
Immediate measures are taken to protect personnel and essential services.
This may include:
* Contacting emergency services.
* Evacuating or securing a location.
* Activating business-continuity procedures.
* Switching to alternate systems.
* Suspending hazardous operations.
* Restricting facility or system access.
Relevant evidence is identified and preserved before unnecessary changes are made.
Evidence may include:
* System and application logs.
* Security alerts.
* Email messages and headers.
* Chat records.
* Access records.
* Device images.
* Cloud audit records.
* Network captures.
* Photographs or video.
* Physical access logs.
* Transaction records.
* Vendor communications.
* Witness accounts.
Evidence handling should be documented. Chain-of-custody procedures should be used when legal, disciplinary, insurance, or law-enforcement action may occur.
The response team takes proportionate action to stop or limit harm.
Containment actions may include:
* Isolating devices, networks, applications, or cloud resources.
* Suspending compromised accounts.
* Revoking tokens, sessions, or credentials.
* Blocking malicious domains, addresses, files, or traffic.
* Disabling integrations.
* Restricting administrative access.
* Placing payment or transaction holds.
* Removing public access to exposed information.
* Temporarily shutting down an affected service.
* Restricting physical access.
Containment decisions should consider both risk reduction and operational consequences.
The response team determines:
* Initial access or root cause.
* Systems and accounts affected.
* Information accessed, altered, disclosed, or removed.
* Duration of exposure.
* Attacker or actor activity.
* Persistence mechanisms.
* Lateral movement.
* Financial and operational impact.
* Whether the event remains active.
* Whether third parties are involved.
* Whether notification obligations may apply.
Based on severity and scope, the incident commander engages relevant functions.
These may include:
* Executive leadership.
* General Counsel.
* Legal, Risk and Compliance.
* Office of Inspector General.
* Global Human Resources.
* Finance.
* Communications and Public Affairs.
* Affected subsidiary leadership.
* Insurance providers.
* External forensic or legal specialists.
* Critical vendors.
* Law enforcement or regulators.
Engagement must be coordinated. Individual employees should not make independent notifications.
Once sufficient evidence has been preserved and scope is reasonably understood, the response team removes the cause of the incident.
Actions may include:
* Removing malicious software.
* Closing vulnerabilities.
* Resetting credentials.
* Rebuilding affected systems.
* Revoking unauthorized access.
* Removing persistence mechanisms.
* Correcting misconfigurations.
* Updating software.
* Replacing compromised devices.
* Terminating malicious integrations.
* Correcting failed procedures or controls.
Systems and services are restored from known-good states.
Recovery should include:
* Validation of backups.
* Security testing.
* Integrity checks.
* Controlled restoration.
* Business-owner acceptance.
* Enhanced monitoring.
* Confirmation that the original cause has been addressed.
* Documentation of temporary workarounds.
* Prioritization of critical services.
Restoration should not be rushed merely because a system can be turned back on. It must be safe to do so.
Authorized communications are provided to affected stakeholders using approved channels.
Communications should state:
* What is known.
* What remains under investigation.
* Current operational impact.
* Actions employees or users must take.
* Where questions should be directed.
* When the next update is expected.
Speculation, blame, and unverified conclusions should be avoided.
Before the incident is closed, the response team verifies that:
* The active threat has been removed or controlled.
* Affected systems are operating reliably.
* Credentials and access have been secured.
* Required monitoring is in place.
* Business owners accept restored services.
* Required notifications have been completed or scheduled.
* Residual risks are documented and approved.
The incident commander formally closes the active response when closure criteria have been met.
Closure should identify:
* Final severity.
* Resolution date and time.
* Affected services and data.
* Confirmed or probable root cause.
* Outstanding corrective actions.
* Responsible owners.
* Post-incident review requirements.
A post-incident review should normally occur within five business days for P1 and P2 incidents, and within a reasonable period for other incidents.
The review should be factual, constructive, and focused on improving systems and processes rather than arranging an elegant search for someone to blame.
## 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.
Legal may issue a preservation or litigation-hold instruction. Such instructions must be followed immediately and override ordinary deletion or retention schedules.
## 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.
Do not confirm, deny, speculate about, or minimize an incident publicly. A confident but inaccurate statement is not an improvement.
## 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:
| Item | Description |
| ----------------------- | ------------------------------------------------------------ |
| **Incident identifier** | Assigned case or incident number |
| **Current severity** | P1, P2, P3, or P4 |
| **Current status** | Investigating, containing, recovering, monitoring, or closed |
| **Known impact** | Systems, operations, data, customers, and personnel affected |
| **Actions completed** | Material response actions since the prior update |
| **Open risks** | Active threats, uncertainties, or business concerns |
| **Decisions needed** | Items requiring executive or functional approval |
| **Next actions** | Planned response steps |
| **Next update** | Expected time of the next status report |
## 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.
“Be more careful” is not a corrective-action plan. A proper action has an owner, a deadline, a measurable result, and preferably a respectable amount of documentation.
## 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
| Situation | Minimum escalation |
| --------------------------------------------- | -------------------------------------------------------------------------------------------- |
| Immediate danger to life or safety | Emergency services, company leadership, Human Resources, and security |
| Suspected sensitive-data exposure | IT Security and Legal, Risk and Compliance |
| Confirmed or suspected ransomware | IT Security, executive leadership, General Counsel, Finance, and insurer contact as directed |
| Payment fraud or changed banking instructions | Finance and IT Security immediately |
| Employee misconduct or insider threat | IT Security, Global Human Resources, and Office of Inspector General |
| Critical vendor compromise | IT Security, service owner, Legal, Risk and Compliance, and Enterprise Operations |
| Media inquiry | Communications and Public Affairs and General Counsel |
| Government or regulator inquiry | General Counsel and Legal, Risk and Compliance |
| Widespread service outage | IST, Enterprise Operations, affected business leaders, and executive leadership |
| Lost device with sensitive information | IT Security and Legal, Risk and Compliance |
## 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
| Item | Information |
| ------------------------ | ----------------------------------------------------------------------------------------------------------------- |
| **SOP owner** | Information Systems and Technology — IT Security |
| **Supporting functions** | Enterprise Operations; Legal, Risk and Compliance; Office of Inspector General; Communications and Public Affairs |
| **Approving authority** | \[Approving authority] |
| **Effective date** | \[Date] |
| **Last review date** | \[Date] |
| **Next review date** | \[Date] |
| **Review cycle** | \[Annual / As needed] |
| **Classification** | Confidential — Internal Use Only |
| **Applies to** | Blevins Holdings and participating subsidiaries |
## Revision history
| Version | Date | Summary of changes | Approved by |
| ------- | ------- | ------------------- | ---------------------- |
| 1.0 | \[Date] | Initial publication | \[Approving authority] |
***
If an incident may be active, do not wait for ordinary business hours, a scheduled meeting, or a more elegant opportunity to mention it. Report it immediately.
## 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.**