Incident Response Policy| Atfenix

1. Purpose

The purpose of this Incident Response Policy is to establish a structured and systematic approach for detecting, reporting, analyzing, containing, and resolving security incidents that may impact the confidentiality, integrity, or availability of Atfenix systems, infrastructure, customer data, and business operations.

2. Scope

This policy applies to all incidents, including but not limited to:

Unauthorized access or hacking attempts.
Malware, ransomware, or virus outbreaks.
Denial of Service (DoS/DDoS) attacks.
Data breaches or data leaks.
Physical security breaches.
Insider threats or misuse of systems.

3. Objectives

Detect and respond to security incidents quickly and effectively.
Minimize operational disruption and data loss.
Protect customer data and maintain trust.
Ensure regulatory and contractual compliance.
Continuously improve Atfenix’s incident management process.

4. Incident Classification

Incidents are classified into four categories:

Low Severity – Minimal impact, limited to a single system, no data compromise.
Medium Severity – Service disruption, potential data exposure, requires immediate attention.
High Severity – Confirmed data breach, widespread system compromise, major service outage.
Critical Severity – Catastrophic impact (e.g., prolonged outage, regulatory breach, major data theft).

5. Roles & Responsibilities

5.1 Incident Response Team (IRT):

Incident Response Manager (IRM): Leads the response, coordinates communication.
Security Analysts: Investigate, analyze, and document incidents.
System Administrators: Contain and remediate technical issues.
Legal & Compliance Officer: Handles regulatory and legal obligations.
Communications Lead: Prepares customer/public communication.

5.2 Employee Responsibility:

Immediately report suspected incidents to the IRT via [[email protected]].
Avoid tampering with evidence or attempting unauthorized remediation.

6. Incident Response Lifecycle

6.1 Preparation

Maintain security tools: firewalls, IDS/IPS, SIEM, monitoring systems.
Train employees in security awareness and reporting.
Maintain updated contact lists, runbooks, and escalation procedures.

6.2 Identification

Detect anomalies via monitoring systems, user reports, or threat intelligence.
Validate whether the event is a true incident.
Assign severity level and log the incident in the Incident Management System (IMS).

6.3 Containment

Short-term: Isolate affected systems, block malicious traffic, disable compromised accounts.
Long-term: Apply patches, configuration fixes, and network segmentation.

6.4 Eradication

Remove malware, backdoors, or malicious accounts.
Apply permanent fixes (patches, security controls).

6.5 Recovery

Restore systems and services from clean backups.
Monitor systems for signs of reinfection or continued compromise.
Validate system integrity before returning to production.

6.6 Lessons Learned

Conduct a post-incident review within 7 business days.
Document root cause, remediation steps, and improvements.
Update security controls, policies, and training as necessary.

7. Communication & Reporting

Internal: Notify management and affected teams immediately.
Customers: If customer data or services are impacted, notify affected customers within [72 hours] of confirmation.
Regulators: If required by law (e.g., GDPR, Indian IT Act), notify relevant authorities within mandated timelines.
Public: Only the Communications Lead or authorized spokesperson may release public statements.

8. Evidence Handling

Preserve system logs, memory dumps, and forensic artifacts.
Chain of custody procedures must be followed.
Evidence must be stored securely for potential legal or regulatory review.

9. Testing & Training

Conduct incident response drills at least twice annually.
Provide employees with phishing and social engineering awareness training.
Update response procedures based on test results.

10. Policy Enforcement

Any employee found violating this policy (e.g., failing to report, tampering with evidence) may face disciplinary action, including termination.
Third-party vendors must comply with Atfenix’s incident response requirements under contractual agreements.

11. Review & Updates

This policy will be reviewed annually or after a major security incident, regulatory change, or infrastructure upgrade.

Contact Us

For any inquiries regarding this policy, please contact us.

Support

[email protected]

Corporate

[email protected]