India's #1 Amazon Developer Partner

Start Free
logo
eVa

eVa

Powered with eVanik AI

eVa

Hi there!

My name is eVa!

How can I help you?

Start Chat

⚡ Powered by eVanik AI

INCIDENT RESPONSE STRATEGY/PLAN

Our company (eVanik Networks Pvt Limited) is following the best methodology of Incident Response Plan. It includes the following basic methods to overcome with any incident occurred in our systems.

Incident Response Strategy/Plan

An incident is no time to have multiple people doing duplicate work. It’s also a terrible time to have important tasks ignored, all because everyone thought somebody else was working on it. Incidents are made worse when incident response team members can’t communicate, can’t cooperate, and don’t know what each other is working on. Work gets repeated, work gets ignored, customers and the business suffer.

That’s why effective incident response teams designate clear roles and responsibilities. Team members know what the different roles are, what they’re responsible for, and who is in which role during an incident.

Here are a few of the most common incident management roles that we have been using as keys to our own incident response strategy.

Role

Incident manager

Primary responsibility: The incident manager has the overall responsibility and authority during the incident. They coordinate and direct all facets of the incident response effort.
Secondary responsibilities: Everything someone else isn’t assigned to.

Tech lead

Primary responsibility: The tech lead is typically a senior technical responder. They are responsible for developing theories about what’s broken and why, deciding on changes, and running the technical team during the incident. This role works closely with the incident manager.
Secondary responsibilities: Communicate updates to incident manager and other team members, document key theories and actions taken during the incident for later analysis, participate in incident postmortem, page additional responders and subject matter experts.

Communications manager

Primary responsibility: The communications manager is the person familiar with public communications, possibly from the customer support or public relations teams. This position is responsible for writing and sending internal and external communication about the incident. This is usually also the person who updates the status page.
Secondary responsibilities: Collect customer responses, interface with executives and other high-level stakeholders.

Subject matter expert

Primary responsibility: A technical responder familiar with the system or service experiencing an incident. Often responsible for suggesting and implementing fixes.
Secondary responsibilities: Providing context and updates to the incident team, paging additional subject matter experts.

Common Security Incident Types

There are many types of cyber security incidents that could result in intrusions on an organization’s network.

We have been responsive the following most common incident types.

Unauthorized attempts to access systems or data
Privilege escalation attack
Insider threat
Phishing attack
Malware attack
Denial-of-service (DoS) attack
Man-in-the-middle (MitM) attack
Password attack
Web application attack
Advanced persistent threat (APT)

Incident Response And Esclation Path Procedure

Pre-assessments

At this stage, I review and dig-out the underlying security policy that invokes my incident response plan. Perform a risk assessment and prioritize security issues. Identify the most sensitive assets, and by extension, which are the critical security incidents my team will focus on. Create a communication plan, and prepare documentation that clearly, and briefly, states the roles, responsibilities and processes. At last but not least I ensure that my team has access to all relevant systems, and the tools and technologies they need to identify incidents and respond to them.

Identification

My team effectively detect deviations from normal operations in organizational systems and identify if those deviations represent actual security incidents.

When a potential incident is discovered, the team immediately collect additional evidence, decide on the type and severity of the incident, and document everything they are doing.

Containment

Once the team identifies a security incident, their immediate goal is to contain the incident and prevent further damage from occurring. This involves:

Short term containment

This can be as simple as isolating a network segment which is under attack or taking down production servers which have been hacked and are diverting traffic to backup servers.

Long term containment

Applying temporary fixes to affected systems to allow them to be used in production, while rebuilding clean systems, preparing to bring them online in the recovery stage.

Eradication

Eradication

The team identify the root cause of the attack, removal of malware or threats, and preventing similar attacks in the future. For example: if an authentication mechanism was the entry point for the attack, it is repelled whilst strong authentication; if a vulnerability was exploited, it should be immediately patched.

Recovery

Recovery

The team brings affected production systems back online carefully to ensure another incident doesn’t take place. Important decisions at this stage are from which time and date to restore systems, how to test and verify that affected systems are back to normal, and how long to monitor the systems to ensure everything is back to normal.

Lessons Learned

Lessons Learned

At last stage the team compiles documentation that could not be prepared during the response process and investigate the incident further to identify its full scope: how it was contained and eradicated, what data or systems or areas where the response team was effective, and areas that require improvement.

Intimation to Amazon

Intimation to Amazon

I will inform Amazon via email to 3p-security@amazon.com within 24 hours of detecting any Security Incidents.

Data Secrecy

I will not notify any regulatory authority, nor any customer, on behalf of Amazon unless Amazon specifically requests in writing that the Developer do so.

Evanik

eVanik Seller Digest

Weekly fee recovery tips, GST updates & exclusive seller resources. No spam.

Amazon
Facebook
ISO Certified
VPAT Compliant
Capterra
Trustpilot
Google Partner

D79, Ground Floor,Sector-2,Noida,Uttar Pradesh-201301

Balaji Complex,Veer Sarvarkar Block Shakarpur,Delhi-110092

CompanyFeaturesSupport
Help & Support
hello@evanik.com
8599900025

© 2025 Evanik Networks Private Limited

Become a Partner|Privacy Policy|Refunds|Terms of Service