Incident Response Policy

This document offers guidance for employees or incident responders who believe they have discovered or are responding to a security incident. In responding to any incident, we first determine the exposure of the information and determine the source of the security problem, if possible. We communicate back to the customer (and any other affected customers) via email or phone (if the email is not sufficient). We provide periodic updates as needed to ensure appropriate resolution of the incident. Our Chief Executive Officer reviews all security-related incidents, either suspected or proven, and we coordinate with affected customers using the most appropriate means, depending on the nature of the incident.

Our Approach to Handling Security Incidents

Recruit CRM has a comprehensive set of security measures in place to ensure we protect customer information and offer the most reliable and secure services we can. However, we also recognize that security incidents can (and do) still happen, and so it’s just as important to have effective methods for handling them should they arise.

As a result, we have a clearly defined approach for responding to security incidents affecting our services or infrastructure. Our incident response approach includes comprehensive logging and monitoring of our products and infrastructure to ensure we quickly detect potential incidents, supported by carefully defined processes that ensure there is clarity in what we need to do at all stages of an incident.

Security Incident Responsibilities

Just like any cloud service provider, we try our best to ensure our customers don’t experience an outage or a security incident. However, we understand that a security incident is likely to happen. It’s important to us that customers understand how they fit into our security incident response process and what responsibilities you have in the course of an incident.

Roles

Every incident we experience is managed by one of our highly-qualified and experienced Senior Engineers (or SE’s). SE’s typically make security-related decisions, oversee the response process and allocate tasks internally to facilitate our response process. The SE’s are further supported by incident analysts who lead the investigation and analysis of incidents, as well as a range of other roles to assist with the response process. In many cases, if an incident has an impact across more than one locale, two SE’s are assigned to an incident to ensure there is always someone accountable to keep our response process moving forward and containment or recovery activities don’t get held-up or otherwise affected by time differences.

Responsibilities

  • Responsible - The party will do the work to achieve the task.
  • Accountable - The party ultimately answerable for the correct and thorough completion of the activity.
  • Consulted - The party whose opinions are sought and with whom there is two-way communication.
  • Informed - The party who is kept up-to-date on progress, and with whom there is just one-way communication.

Incident Response Plan Steps

Preparation

Ideally, monitoring tools will detect and inform to team about an incident before customers even notice. Though sometimes first learn about an incident from customer support tickets.

Identification

In this stage, we perform checks and figure if the reported abnormality is an incident or not. If it is confirmed as an incident, we collect report logs, error logs and communicate it with the respective team for further investigation and measures are taken to fix the incident at the earliest.

Containment

The goal of this stage is to control the impact of the incident and prevent it from affecting the system further. We handle such a situation by isolating that particular affected area which is followed up by a backup to prevent any data loss and safeguards the data of our customers. We then investigate the root cause of the incident and create strategies to prevent such incidents in the future.

Eradication

The incident is always reported to the concerned team with enough documentation. After reviewing the documentation and code, the eradication process undergoes numerous testing which ensures the incident is no longer in the system and won’t happen again in the system in the future.

Recovery

Once security incident happens, it moves on the remediation and recovery phase of the incident lifecycle, which works towards ensuring that systems are cleansed of any malicious or other illicit content and ready to be used again within the organization. While the exact steps involved in remediation and recovery are dependent on the organization and the incident type, the following areas and actions are considered:

Patching and hardening system images

Reimaging systems

Implementing password changes

Improving monitoring and defenses

Lessons

After every incident, we perform heavy documentation. The learning from these documentations is discussed in review meetings and certain standards are set to follow. The learning helps the organization to avoid repetitive incidents & secures the systems from past incidents.