Home / Incident Management

Incident Management

Purpose

This Incident Management Program establishes policies, standards, and procedures to ensure StreetPricer can quickly, effectively, and consistently respond to information security incidents across all systems, applications, and environments. It aims to minimize impact, restore services, maintain the confidentiality, integrity, and availability of data, and meet contractual and regulatory requirements.

Scope

This program applies to all systems, applications, cloud services, networks, third-party integrations, and data handled by StreetPricer. It covers all employees, contractors, and service providers who interact with StreetPricer information assets.

Definitions

Security Incident: Any event that compromises or threatens to compromise the confidentiality, integrity, or availability of information or services (e.g., data breach, malware, unauthorized access, misconfiguration, service disruption). Incident Categories:

  • Availability (e.g., outage, DoS)
  • Confidentiality (e.g., data exposure, credential leak)
  • Integrity (e.g., unauthorized changes)
  • Unauthorized Access (e.g., compromised account, privilege misuse)
  • Misconfiguration/Policy Violation

Policy Statement

StreetPricer will maintain an Incident Response Plan (IRP) and supporting procedures that include: (a) incident discovery and categorization; (b) timely notification to relevant stakeholders when applicable; (c) incident ranking/severity; (d) containment, eradication, and recovery; (e) documentation of remediation actions; (f) regulatory reporting within required timeframes; (g) lessons learned and IRP updates; (h) trend analysis of past
incidents; (i) annual testing of the IRP; and (j) formal reviews every six months and after major infrastructure or system changes.

Roles and Responsibilities

  • Incident Coordinator: Leads incident handling activities and ensures documentation. – Communications Lead: Manages internal communications and external notifications (including regulators and affected parties when applicable).
  • Technical Lead(s): Performs investigation, containment, eradication, and recovery activities.
  • Evidence Custodian: Oversees chain of custody for evidence and ensures integrity of records. (Note: In small teams, roles may be combined as needed; responsibilities must still be performed.)

Severity Classification and Response Targets

Severity Examples Initial Response Target Notification/Reporting
Critical Active breach, PII exposure, widespread outage < 1 hour Immediate escalation; assess regulatory obligations
High Compromised account, data exfil suspected < 4 hours Escalation within same business day
Medium Non-public misconfiguration, limited impact < 1 business day Internal notification
Low Minor policy violation, no data exposure < 3 business days Internal tracking

 

Incident Lifecycle Procedures

Discovery & Triage: Monitor alerts from security tools, cloud services, logs, and user reports. Confirm incident and assign severity. Containment: Isolate affected accounts, systems, or networks. Apply temporary controls. Investigation: Collect logs and evidence following chain of custody procedures. Determine root cause and scope. Eradication & Recovery: Remove malicious artifacts, fix misconfigurations, restore services
from clean backups. Notification & Reporting: Notify relevant stakeholders and meet regulatory timelines. Post-Incident Activities: Document remediation actions, conduct lessons learned, update IRP, perform trend analysis.

Chain of Custody Procedures

All evidence must be preserved with integrity. Use a Chain of Custody Log to record evidence ID, description, source, date/time collected, collector, storage location, hash, transfers, and disposition. Access to evidence stores must be restricted and auditable.

Testing and Review

The Incident Response Plan will be tested at least annually via tabletop exercise or simulated drill. The IRP will be formally reviewed every six months and after major infrastructure or system changes. Testing records and review logs will be retained for a minimum of 24 months.

Documentation and Retention

All incidents must be documented using an Incident Record Template, including severity, timeline, actions taken, and remediation. Records (incident tickets, evidence logs, notifications, lessons learned, review logs, testing reports) will be retained for at least 24 months or longer if required by law or contract..