CySA+ domain #8: Incident response process [DECOMMISSIONED ARTICLE]

August 14, 2019 by Graeme Messina

NOTE: This article reflects an older version of the CySA+ Exam, although some of the material is still relevant – please see the current CySA+ Certification page for the most up-to-date information.


CompTIA has identified a need in the market for cybersecurity professionals that want to certify their knowledge and earn a cybersecurity analyst qualification. The CySA+ certification is a way for candidates to show their employers that they are familiar with all of the concepts, theories and methods that are needed in a cybersecurity analyst role.

There are four exam objectives that you will need to master in order to pass. In this article we will be looking at the incident response process, which is covered under the third domain in the exam objectives 3.0, Cyber Incident Response. We’ll look at the requirements for the test, as well as the basics that you should know before taking on this certification. You can use this article as a starting point for your studies to help show you what you can expect from the certification in general.

Common terms and concepts

If you already work in cybersecurity, you are probably no stranger to some of the basic terminology that comes with this line of work, but learning the definitions is still important if you want to certify your knowledge. Some examples of the types of information that you should know are:

  • IR: In this context, IR stands for incident response. It is the process of mitigating or remediating the effects and symptoms of a cybersecurity incident against an IT system
  • NIST SP 800-61 revision 2: This is a NIST Special Publication that describes the entire incident response process
  • Stakeholders: These are the department heads of your organization such as HR, Legal, Marketing and management
  • Role-based responsibilities: These highlight the responsibilities of each party that responds to an incident. Examples are technical, management and law enforcement

Incident response process steps

There are six steps in the Incident Response Process. Each of these steps are designed to help the Incident Response Team to prepare and mitigate incidents, as well as learn from the incident afterwards.

Step 1. Preparation

Preparation is an important part of the IR process because it helps you to plan and map out all of the potential steps that you need to take in the event of an incident.

Step 2. Detection/identification 

The type of threat must be identified so that the appropriate actions can be taken. For instance, the way that your team deals with a data breach will be different to the way that it deals with a malware outbreak. You need to know if any laws and regulations have been violated in the incident as well, so that the appropriate authorities can be alerted by your team lead.

Step 3. Containment

You need to stop the spread of the threat over your network, and this is done in the containment step. If a segment of the network is infected, then those devices may need to be disconnected as part of a quarantine. If a server has been compromised, then you may need to fail over to a replica and take that host offline if it is a mission critical system. 

There are many things that can and should be done at this stage of the incident response process, depending on the circumstances and what steps your company has put in place.

Step 4. Remediation

This is where the actual corrective action takes place. Examples would be removing malicious code, getting rid of threats and locking down systems that were vulnerable during the incident. All processes undertaken during this step must be logged and noted so that there is a history of what was done during the remediation process.

Step 5. Recovery

At this point, you will start with the restoration of any services that were disabled or disconnected during the incident. This is also a good time to review company policies and to ensure that all procedures are being followed. Monitoring is vital at this point so that any remaining threats can be dealt with if there are any previously undetected instances.

Step 6. Lessons learned

Sometimes referred to as a post-mortem, this is the step that outlines the events that caused the incident, how it was identified and how it was eventually remedied. It focuses on what the team got right and what they got wrong. All this information is then used as the basis for any necessary changes to the incident response process for the organization. As threats change and evolve, so does the incident response process.

Purpose of communication processes

Candidates need to understand the reasons for communication during an incident, as well as what not to say. Domain 3.3 covers this in detail and will test the candidate’s knowledge on communication procedures during a cybersecurity event. Some of the subheads from this section that need to be understood are:

  • Limit communication to trusted parties
  • Disclosure based on regulatory and legislative requirements
  • The prevention of inadvertent information release
  • Establishing secure methods of communication

All of these principles feed into the overall incident response process and will be different for each of the stakeholders and relevant parties that are named in the incident response plan.


Explaining the importance of communication during the incident response process is an important part of the CySA+ exam. Although this is not an especially long objective, it needs to be understood properly, and it falls within Domain 3 of the exam objectives. This article is a basic starting point for your exam preparation and will hopefully help you to fill in the blanks from the CySA+ exam objectives.



  1. CompTIA CySA+, CompTIA
  2. CompTIA Cybersecurity Analyst (CySA+) Certification Exam Objectives, CompTIA
  3. Building Your Bullet Proof Incident Response Plan, Infosecurity Magazine
Posted: August 14, 2019
Articles Author
Graeme Messina
View Profile

Graeme is an IT professional with a special interest in computer forensics and computer security. When not building networks and researching the latest developments in network security, he can be found writing technical articles and blog posts at InfoSec Resources and elsewhere.

Leave a Reply

Your email address will not be published. Required fields are marked *