Incident Response Policy

Rephyr Incident Response Policy


This policy defines what constitutes a security incident and outlines the incident response steps.

Incident Definition

An incident is the violation of an explicit or implied security policy that may or may not result in a loss of data confidentiality, integrity, and/or availability. Incidents can be any one or more of the following:

1) Theft of data
2) Theft of physical IT assets
3) Damage to physical IT assets
4) Denial of service, e.g. DDoS
5) Misuse of services, information, or assets
6) Infection of systems by unauthorized or hostile software
7) An attempt at unauthorized access
8) Unauthorized changes to organizational hardware, software, or configuration 9) Reports of unusual system behavior
10)Responses to intrusion detection alarms


Incidents may be reported by internal or external parties through any method of electronic communication or by telephone. If clients become aware of a security incident, they are encouraged to report it by e-mailing

Once an incident has been identified or reported, the following plan should be immediately implemented.

1) The individual or group receiving the report shall collect the following information.

• The name of the reporter
• Time of the report
• Contact information about the reporter

  • The nature of the incident
  • The equipment, persons, or data involved
  • Location of equipment or persons involved
  • How the incident was detected
  • When the event was first noticed that supported the idea that the incident occurred
  • Any other relevant information

2) The individual or group initially notified of the incident shall immediately notify the CEO, who shall then notify other appropriate parties and designate an Incident Manager. In the event that the CEO cannot be reached, the CPO shall be notified. Personnel must notify senior leadership ahead of travel or other scenarios that may render an employee unable to respond to security incidents.

Contact Information:

a) Aaron Scruggs

(512) 651-3004

b) Julianna Scruggs


3) The Incident Manager shall assemble the appropriate group of personnel to:

  • Determine origin, risk, and scope of incident and potential impact by using forensics techniques. Only designated personnel should be performing interviews or examining evidence, and the designated personnel may vary by situation.
  • Contain the incident and limit or prohibit further damage
  • Preserve evidence and document all actions related to the incident response and store in the designated document management system. Copies of logs, email, and other communication will be retained in addition to lists of witnesses and appropriate evidence as long as necessary to complete prosecution and beyond in case of an appeal.
  • Determine and execute a response strategy, if and when necessary

• Perform a Root Cause Analysis (RCA) and implement controls to prevent the incident from occurring again in the future. The RCA document is included in this policy as “Attachment A”.

  1. 4)  Designated personnel shall restore the affected system(s) to the uninfected state.
  2. 5)  Senior Leadership shall notify proper external agencies if prosecution of the offender is possible.
  3. 6)  Senior Leadership and the Incident Manager shall assess the damage to the organization, both monetarily and otherwise.
  4. 7)  CPO shall conduct a policy review to determine whether or not policies should be revised to prevent the same or a similar incident from happening again in the future.


Non-compliance with this policy may result in disciplinary action, up to and including termination.

Policy Review
Document Owner: Julianna Scruggs
Date of last review: 08/22/2019
Last reviewed by: Julianna Scruggs
Date of approval: 8/22/2019
Approved by: Aaron Scruggs




How and/or by whom was the incident detected?

How much time passed between incident occurring and incident detection?

Scope and Risk of the incident:

How the incident occurred (through e-mail, firewall, etc.)

Where the attack originated (such as IP addresses) and other related information about the attacker


What was done in response? Was the response effective?

Are operational changes recommended to remediate the risk of this incident occurring again?

Is there someone who should have been involved who was overlooked?
How was the communication process with customer support (if applicable)?

Did Support provide necessary information to keep customers informed in a timely way?

Can this intervene process be automated for future instances?


Do you have redundancy for all the layers, both physical and logical?

Are there defensive programming techniques that will make the system more resilient?

Even if the failure happens again, can your system handle it without impact?

Are there similar issues that could happen that could affect the system? What will you do different to prevent this from happening again?