This policy is intended to clarify roles, responsibilities, and procedures in the event of an incident involving Bound's systems or information. The integrity of Bound's systems is critical to the operation of the organization, and a swift and thorough response to incidents is necessary in order to maintain business continuity, and to protect information.
This policy is applicable to all data, hardware, software, and computing infrastructure owned, operated, or otherwise used by Bound and its employees in the service of Bound's business interests. Any information not specifically identified as the property of other parties that is transmitted or stored on Bound's IT resources (including but not limited to email, messages, files, customer data, and employee information) is the property of Bound. Anyone who uses or has used Bound's IT resources is subject to this policy, including Bound employees, contractors, vendors, and any other temporary or long-term system users.
The Incident Response Team includes the following roles and responsibilities:
The CEO of Bound is responsible for executive-level decision making during an incident. Responsibilities include but are not limited to:
- Financial impact assessments and spending approvals during an incident
- Legal assessments relating to an incident, and communication with legal representation and/or law enforcement
- Public and employee relations related to an incident
Technical Response Manager
The CTO of Bound is responsible for technical decision making during an incident. Responsibilities include but are not limited to:
- Incident response planning, training, and playbook development
- Regular review and revision of this policy, and related trainings and playbooks
- Technical decision-making and approvals during an incident
- Sourcing of 3rd party vendors during an incident
- Emergency purchasing management and approvals during an incident
- Communication with the Executive during an incident, including details necessary to for effective PR or employee relations purposes
- Assisting and coordinating technical support staff during an incident
- Spearheading the forensic review of incidents
Technical Support Staff
Engineers and systems administrators are responsible for diagnosing issues and carrying out remediations during an incident. Responsibilities include but are not limited to:
- Planning systems to ensure redundancy and stability, including steps to rebuild or restore service in the event of an incident
- Problem classification, evaluation, and root cause analysis during an incident
- Technical response the the incident, including repairing in-place, moving, or otherwise restoring affected systems to full service
- Communicating to the Technical Response Manager during an incident, including the severity, type and likely impact of the incident
- Coordinating with the Technical Response Manager on any major technical decisions, particularly those with an outsized cost, service, or PR impact
- Aiding in forensic review of incidents
Customer Support Staff
Customer Service Managers are responsible for communicating to clients during an incident. This includes proactive and reactive communication. CSMs should provide only information that has been explicitly approved for release by the Technical Response Manager and the Executive.
It is the responsibility of all Bound employees to adhere to corporate security policies and procedures. Employees are required to promptly report information security incidents to Bound's Incident Response Team for evaluation.
Reporting And Notification
All incidents must be tracked in Bound's ticketing system. In the event of an incident, all non-technical communication should flow through a ticket, created immediately by the incident reporter, or by the employee who received the report. This ticket should be referenced in subsequent communications, and should include the following information:
- A short description of the incident
- The time reported, and the original reporter (i.e. was it reported by a customer)
- Proof of the incident (i.e. steps to validate the existence of or reproduce the incident)
- A list of affected customer(s), systems, and/or specific campaigns/rules/segments/users, etc.
Further notification protocol depends on the type and severity of the incident (see section 5 of this document for identifying incident severity). If the incident severity cannot be deduced by the reporter, it should be assumed to be a level 3 incident.
Level 5 Incident (Disaster)
For service outages, the reporter should immediately and directly alert the Technical Response Manager, the Technical Support Staff, and the Executive. This should happen by telephone, SMS, or direct IM (in that order of preference), in addition to a ticket being filed. Outage incidents should immediately trigger the disaster recovery plan specific to the affected system or subsystem.
Levels 3 and 4 (Major and Critical Incidents)
For incidents that include breaches data, partial service outages, or substantial service degradation for most or all customers, the reporter should immediately and directly alert the Technical Response Manager, and the Technical Support Staff. This should happen by telephone, SMS, or direct IM (in that order of preference), in addition to a ticket being filed.
Level 2 (Non-trivial Incidents)
For incidents that include minor service outage or degradation, or an issue specific to a minority of customers, the reporter may alert the Technical Support Staff via direct IM or email.
For incidents with low customer impact, the reporter should file a ticket, and assign the ticket to a member of the Technical Support Staff.
Incident Type And Severity
Bound considers incidents to exist at five levels of severity. It is up to the incident reporter to make an initial assessment of severity, but severity may be reassessed or reassigned by the Incident Response Team as information emerges. Incidents are classified as follows:
Level 5 (Disaster)
- A total ongoing service outage
Level 4 (Critical Incident)
- Any partial or temporary outage or major service defect that is anticipated to last longer than one hour, and impacts a majority of Bound customers
- Any verified intrusion on, or security breach of, Bound's systems
- Any breach of sensitive internal or customer data
- Any event that may greatly impact Bound's reputational or legal risk if not addressed immediately
Level 3 (Major Incident)
- Any partial or temporary outage or major service defect that is anticipated to last longer than one hour, but impacts a minority of Bound customers
- Any breach of non-sensitive internal or customer data
- Disclosure of security vulnerabilities that would allow a 3rd party to degrade service stability, or to access sensitive data
Level 2 (Non-trivial Incident)
- Any degradation of Bound's service that is anticipated to last less than one hour, or impacts a small number of Bound customers
- Any defect preventing customers from achieving their business goals (i.e. bugs or deficiencies with no known workaround)
- Any security incident which has been successfully responded to, and which does not have the potential to affect operational, legal or reputational risk
- Disclosure of security vulnerabilities that do not pose risk of major service disruption, or of sensitive data compromise
Level 1 (Minor Incident)
- Deficiencies or events that do not materially impact core service operation, stability, or security for most customers
Bound uses automated processes to monitor network traffic, logs, processes, and various other information points in order to detect exploitation attempts, system failures, and other potential issues.
Alarms are in place for major service degradation or outages, and in most disaster cases the Technical Support Staff is alerted in real time.
Monitors exist to automatically detect some types of intrusion by 3rd parties, and many types of incidents will trigger automated remediations and alerting. Bound also regularly conducts audits to determine if 3rd parties have gained access to internal systems or data, and to assess possible vulnerabilities.
Bound conducts regular penetration and vulnerability tests to ensure the integrity of Bound systems, and to assess possible attack or intrusion vectors.
Team members are critical in reporting service incidents--they are constantly using Bound's systems, and are in regular contact with clients.
The general public may submit security notices via our contact form, or by email.
Bound's general framework for responding to incidents is as follows:
- Incident reporting: incident is reported and classified by the reporter based on the criteria defined in section 5 of this document
- Evaluation and coordination: Incident Response Team is notified of the incident, verifies and re-assesses the report, and plans any necessary remediation
- Remediation: the Incident Response Team communicates relevant findings and sets recovery expectations, remediates the incident, and returns critical systems to working order
- Recovery and communication: the Incident Response Team cleans up any compromised resources, restores any compromised data or non-critical systems, and communicates any further findings or expectations
- Continuous improvement: the Incident Response Team analyzes the root cause of the failure, and plans/recommends improvements that would prevent a similar incident from occurring in the future
Training, Testing, And Maintenance
This document will be reviewed by the Incident Response Team (and revised where appropriate) once per quarter. During this review, roles will be (re)assigned to specific individuals where necessary.
Once per year, the Incident Response Team will review this document, in order to reassess and understand their assigned roles and duties. During this time, members of the incident response team will run through a test incident, to ensure that they have the information, tools, and access required to perform assigned duties.