Incident Response Plan (Annex A.16)

Public version

Effective Date: 01 July 2025

Owner: Chief Information Security Officer (CISO)

Applies To: All employees, all new hires of Advntg.AI

ISO 27001 & SOC 2 Mapping

This plan supports compliance with the following standards and controls:

ISO 27001 Annex A Controls

• A.6 – Organization of Information Security: Assigning clear incident response roles and responsibilities.
• A.9 – Access Control: Limiting and securing access during incident handling to prevent further compromise.
• A.12 – Operations Security: Monitoring, logging, and forensic analysis to detect and analyze incidents.
• A.16 – Information Security Incident Management: Establishing processes for reporting, assessing, responding to, and learning from incidents.
• A.18 – Compliance: Meeting legal, regulatory, and contractual obligations for incident reporting.

SOC 2 Trust Services Criteria

• Security (CC7.x) – Detecting, responding to, and recovering from security incidents.
• Confidentiality (C1.x) – Protecting confidential data during and after an incident.
• Availability (A1.x) – Restoring affected systems and services promptly to maintain availability.

Table of Contents

1. Purpose

2. Scope

3. Incident defined

4. Roles and Responsibilities

5. Incident Response

6. Escalation and Notification

7. Documentation and Evidence

8. Testing and Review

1. Purpose

The purpose of this Policy is to ensure that all security incidents are promptly detected, accurately reported, effectively contained, and fully resolved in a coordinated manner.

This process is designed to:

• Minimize impact on Company operations, clients, and stakeholders.
• Protect the confidentiality, integrity, and availability of Company information assets.
• Meet all applicable legal, regulatory, and contractual obligations for incident handling and reporting.

2. Scope

This Policy applies to:

1. All Company systems, networks, applications, and data – including those hosted or managed by third parties on behalf of the Company.
2. All personnel – employees, contractors, vendors, and third parties who create, process, store, or transmit Company information.

It covers any incident that may impact the confidentiality, integrity, or availability of Company information assets.

3. Incident defined

3.1. A security incident is any event that:

• Results in, or has the potential to result in:

• Unauthorized access to Company data.
• Unauthorized disclosure, alteration, or destruction of Company data.

• Disrupts or threatens to disrupt normal IT services.
• Compromises or attempts to compromise the effectiveness of Company security controls.

3.2. Examples include, but are not limited to:

• Malware or ransomware infection.
• Data breach involving personal, client, or proprietary information.
• Unauthorized system or account access.
• Phishing or social engineering attacks.
• Insider threats, whether intentional or accidental.
• System outages or service disruptions caused by malicious cyber activity.

4. Roles and Responsibilities

5. Incident Response

5.1. Identification

• Continuously monitor system logs, SIEM alerts, Endpoint Detection and Response (EDR) tools, and user reports to detect potential incidents.
• Assign a severity level upon identification:

• Low – Minimal operational impact, no confirmed data compromise.
• Medium – Potential or confirmed compromise with limited scope and containment.
• High/Critical – Significant data breach, major service disruption, or potential regulatory impact.

5.2. Containment

• Short-term containment – Immediately isolate affected systems, accounts, or networks to prevent incident spread.
• Long-term containment – Implement measures such as applying security patches, rotating credentials, or deploying additional protective controls to prevent recurrence.

5.3. Eradication

• Remove all malicious software, disable or delete compromised accounts, and remediate vulnerabilities exploited in the incident.

5.4. Recovery

• Restore affected systems and data from verified clean backups.
• Monitor restored systems for anomalies or recurring threats before returning them to full production status.

5.5. Lessons Learned

• Conduct a post-incident review within ten (10) business days of incident closure.
• Update relevant security policies, technical controls, and employee training based on review findings to reduce the likelihood of recurrence.

6. Escalation and Notification

6.1. Internal Notification

All incidents must be reported immediately to the Cybersecurity Team via the designated incident reporting channel.

Reports should include initial observations, suspected scope, and any immediate actions taken.

6.2. External Notification

If required by applicable laws, regulations, or contractual obligations, the Company must notify:

• Regulators (e.g., GDPR within 72 hours of awareness).
• Clients or business partners who may be impacted.
• Other stakeholders as required by contractual agreements.

6.3. Communication Protocol

• All external communications related to an incident must be coordinated and approved by the Communications Officer.
• Unauthorized personnel must not make public statements or release information regarding the incident.

7. Documentation and Evidence

7.1. Incident Reporting Requirements

For every incident, the Incident Response Manager or designated team member must complete a formal Incident Report containing:

• Date and time of detection.
• Systems, applications, or user accounts affected.
• Detailed description of the incident, including suspected cause and timeline of events.
• Actions taken during containment, eradication, and recovery phases.
• Root cause analysis identifying vulnerabilities or control failures.
• Preventive measures implemented to avoid recurrence.

7.2. Evidence Preservation

All relevant system logs, forensic artifacts, and other digital or physical evidence must be:

• Preserved securely in accordance with legal and regulatory requirements.
• Protected from alteration to maintain evidentiary integrity.
• Retained for the duration required for potential legal action or regulatory investigation.

8. Testing and Review

8.1. Incident Response Testing

• The Company must conduct incident response simulations at least once per year to evaluate the effectiveness of the plan, identify gaps, and validate team readiness.
• Simulations should include a variety of realistic scenarios, such as data breaches, ransomware attacks, and insider threats.

8.2. Post-Test and Post-Incident Review

• Following each simulation or actual security incident, this plan must be reviewed and updated to incorporate lessons learned, changes in threat landscape, or regulatory requirements.
• Updates must be approved by the Chief Information Security Officer (CISO) and communicated to all relevant stakeholders.

This Policy shall be reviewed and edited from time to time, subject to the CEO approval.

For questions or reports regarding this Policy, contact:

security@adnvtg.ai

* * *

‍