Incident Response —
what happens
when things go wrong.

What this plan covers

This Incident Response Plan (IRP) establishes the procedures for detecting, responding to, and recovering from security incidents affecting the VIGIL platform operated by Anshin Risk and Resilience Consulting Private Limited (ARRC Global). It defines the roles, responsibilities, timelines, and communication obligations that apply to all incidents — from initial detection through post-incident review.

This plan applies to:

• All security incidents affecting the VIGIL platform, its infrastructure, or any data processed within it
• All personal data breaches as defined under applicable data protection law — including GDPR, India's DPDP Act, and Singapore's PDPA
• All platform availability incidents that materially affect client operations
• All confirmed or suspected compromises of ARRC Global's internal systems that could affect the VIGIL platform or client data

Compliance with this plan is mandatory for all ARRC Global personnel with any role in the VIGIL platform or its supporting infrastructure.

Definitions and event types

Not every security event is an incident. The following definitions govern how events are classified and escalated.

Security Event

Any observable occurrence in a system or network that may have security implications. Security events are logged and monitored but do not necessarily require incident response activation. Examples: failed login attempts below lockout threshold; automated scanner probing public endpoints; routine dependency vulnerability alerts.

Security Incident

A security event that has been assessed as having actually or potentially compromised the confidentiality, integrity, or availability of the VIGIL platform or any data processed within it. Incidents require activation of this plan. Examples include:

• Confirmed or suspected unauthorised access to the platform or its infrastructure
• Confirmed or suspected access to, exfiltration of, or modification of client data by an unauthorised party
• Malware infection, ransomware deployment, or cryptomining on platform infrastructure
• Exploitation of a vulnerability in the VIGIL application or its dependencies
• Credential compromise — confirmed theft or exposure of platform or infrastructure credentials
• Insider threat — authorised user accessing data outside their permitted scope
• Supply chain compromise — confirmed compromise of a software dependency used by the platform
• Platform unavailability caused by a security event (DDoS, infrastructure attack)

Personal Data Breach

A subset of security incidents involving the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data processed by ARRC Global. All personal data breaches are security incidents. Not all security incidents are personal data breaches. The distinction matters because personal data breaches carry specific regulatory notification obligations — see Sections 6 and 7.

Four tiers — each with defined response requirements

Every incident is classified at detection and reclassified as new information emerges. Classification drives response timelines, escalation paths, and notification obligations.

Classification is performed by the Incident Lead at detection. It is reviewed and confirmed or revised at each phase transition. Upward reclassification (e.g. Medium to High) can occur at any time as new information emerges — downward reclassification requires documented justification.

Six phases from detection to closure

How incidents are identified and surfaced

Detection Sources

• Automated monitoring. Central logging and alerting monitors authentication events, data access patterns, API anomalies, infrastructure health, and dependency vulnerability feeds. Alerts are configured for patterns consistent with known attack techniques.
• External disclosure. Security researchers reporting via the Responsible Disclosure Policy. CERT-In vulnerability notifications. Threat intelligence feeds.
• Client reports. Clients may observe anomalous behaviour within their platform accounts before it is detected internally. Client-reported anomalies are treated as potential incidents and triaged accordingly.
• Internal discovery. Any ARRC Global team member who discovers or suspects a security incident is required to report it immediately.
• Third-party notification. Sub-processors or infrastructure providers notifying ARRC Global of a security event affecting VIGIL's infrastructure.

Internal Reporting Obligation

All ARRC Global personnel — including developers, contractors, and any third party with platform access — must report any confirmed or suspected security incident immediately to the Founding Principal. There is no minimum severity threshold for internal reporting. The cost of an unnecessary report is negligible. The cost of a delayed report during an active incident is not.

What clients are told, when, and how

Client notification is a legal obligation under applicable DPAs and data protection law, and a fundamental commitment to the trust relationship with clients. ARRC Global's notification standards exceed the minimum required by law.

Content of Initial Notification

The initial notification to affected clients will include, to the extent known at the time of notification:

• A description of the nature of the incident — what happened, how it was detected, and when
• Whether the client's data is confirmed or suspected to be affected
• The categories and approximate volume of data involved, if determinable
• The containment measures already in place
• The current status of the investigation
• A named contact point at ARRC Global for further information and questions
• Where a personal data breach is confirmed or suspected: guidance on whether the client may need to notify its own data subjects or regulatory authority

Where all information is not available at the time of initial notification, ARRC Global will provide it in supplementary notifications as the investigation progresses. Clients will not be left without an update for more than the intervals specified in the table above, for the duration of the incident.

Obligations to supervisory authorities

Where a security incident constitutes a notifiable personal data breach under applicable data protection law, ARRC Global will notify the relevant supervisory authority within the required timeframe. ARRC Global also supports affected clients in fulfilling their own regulatory notification obligations as data controllers.

ARRC Global will provide affected clients with all information in its possession necessary to enable the client to fulfil its own regulatory notification obligations as data controller — including a draft incident summary, the data categories involved, the estimated number of data subjects affected, and ARRC Global's remediation actions.

How incidents are stopped from spreading

• Network isolation. Compromised systems are isolated from the network immediately upon confirmed compromise — before investigation, where necessary to prevent lateral movement. Isolation is documented with timestamps.
• Credential revocation. All credentials confirmed or suspected as compromised are revoked immediately. This includes API keys, database passwords, infrastructure access tokens, and platform user accounts where applicable.
• Session termination. Active sessions potentially affected by a credential compromise are terminated across all active tokens, not only the specific compromised credential.
• Traffic blocking. Identified malicious IP addresses, user agents, or traffic patterns are blocked at the infrastructure level. Blocking is logged.
• Dependency isolation. Where a supply chain compromise is confirmed, the affected dependency is removed from the build pipeline and replaced or pinned to a confirmed-clean version before the next deployment.
• Platform maintenance mode. For S1 incidents requiring significant containment action, the platform is placed in maintenance mode. Clients are notified of maintenance mode activation and estimated duration before or immediately upon activation, depending on incident urgency.
• Backup integrity check. During containment, backup integrity is verified to confirm that clean recovery points exist and have not been compromised by the incident. See the Backup & Recovery Policy for recovery procedures.

Preserving the integrity of the investigation

• Evidence preservation is the first priority. Before any containment action that may alter system state, relevant logs, memory dumps, and system images are captured and preserved. Containment and evidence preservation are planned together, not sequentially.
• Chain of custody. All evidence collected during an incident is logged with: what was collected, when, from which system, by whom, and the storage location. Evidence logs are write-protected from the point of collection.
• Log integrity. VIGIL's central logging is configured to be append-only during normal operations. During an incident, logs from the relevant timeframe are exported and hash-verified to confirm integrity before analysis.
• No system modification before imaging. Compromised systems are imaged before any remediation action is taken, where operationally feasible. This preserves the forensic state for root cause analysis and, if necessary, legal proceedings.
• External forensic assistance. For S1 incidents or incidents with potential legal or regulatory consequences, external forensic assistance may be engaged. External forensic experts operate under appropriate confidentiality agreements.
• Evidence retention. All forensic evidence collected during an incident is retained for a minimum of 5 years from the date of incident closure, consistent with the Data Retention Policy.

Returning to normal operations safely

• Recovery only after eradication. The platform is not returned to production until the root cause has been eradicated and the remediation has been verified. Premature recovery that returns a compromised system to production is treated as a separate incident.
• Clean rebuild preferred. Where system integrity cannot be confirmed after a compromise, affected systems are rebuilt from a clean state using verified infrastructure configuration, rather than restored from a potentially compromised image.
• Backup restoration. Where data integrity has been compromised, recovery from the most recent clean verified backup is initiated. Backup restoration procedures are documented in the Backup & Recovery Policy. The recovery point objective (RPO) and recovery time objective (RTO) applicable to the affected data are referenced at initiation.
• Verification before return. Before returning restored systems to production: security controls are verified as correctly configured, monitoring is confirmed as active, and a post-restoration security check (analogous to post-deployment verification) is conducted.
• Staged restoration. For S1 incidents, restoration is staged — read-only access first, then write access, then full production operation — with verification at each stage before proceeding.
• Client confirmation. Affected clients are notified when service is restored, with a summary of what was restored, from what point, and what, if any, data loss occurred. If data loss occurred, it is stated clearly — not minimised.

Learning from every incident

A post-incident review is conducted within 14 days of every S1, S2, and S3 incident closure. S4 incidents are reviewed in aggregate quarterly. The review produces a formal post-incident report covering:

• Incident timeline. A precise chronological record from first detection through final closure, including all key decisions and actions with timestamps.
• Root cause analysis. What failed? Why? Was it a technical control, a process gap, a human error, or a combination? The root cause — not the proximate cause — is documented.
• Impact assessment. What data was affected? Which clients? What was the business impact? What was the regulatory impact?
• Response effectiveness. Did the detection, containment, investigation, and recovery phases perform as intended? Where did the plan work well? Where did it fall short?
• Action items. Specific, assigned, time-bound actions to prevent recurrence, address identified control gaps, and improve the response plan based on the experience of this incident.
• Plan updates. Where the incident reveals gaps in this plan, the plan is updated before the next review cycle.

Post-incident reports for S1 and S2 incidents are provided to affected clients on request, in summary form that protects confidential operational detail while being honest about what occurred, how ARRC Global responded, and what has changed as a result.

Who does what during an incident

• Incident Lead. The individual responsible for coordinating the incident response from detection through closure. For S1/S2 incidents, the Incident Lead is the Founding Principal or their designated delegate. For S3/S4 incidents, the Incident Lead may be a senior developer. The Incident Lead is accountable for all decisions, documentation, and communications during the incident.
• Founding Principal. Notified immediately for S1/S2 incidents. Reviews and approves all client and regulatory notifications before dispatch. Makes decisions on platform maintenance mode, external forensic engagement, and legal escalation. Ultimate accountability for incident response.
• Development team. Executes technical containment, investigation, eradication, and recovery actions under the direction of the Incident Lead. Documents all technical actions in the incident log with timestamps.
• External forensic experts. Engaged for S1 incidents or those with potential legal/regulatory consequence. Operate under confidentiality agreement. Provide independent forensic analysis and chain-of-custody documentation.

Keeping the plan ready

• Annual tabletop exercise. At least once per year, the Incident Response Plan is tested through a structured tabletop exercise simulating a realistic incident scenario. Findings from the exercise are used to update the plan. The exercise is documented.
• Post-incident update. Every S1 or S2 incident triggers a review of this plan within 30 days of closure. Where the incident reveals gaps, corrections, or improvements, the plan is updated and the updated version is published.
• Annual policy review. This plan is reviewed annually as part of the broader policy review cycle, regardless of whether incidents have occurred. The review confirms that contact details, role assignments, regulatory notification requirements, and technical procedures remain current.
• Communication test. Annually, notification contact details for all active client DPAs are verified as current. Clients with outdated notification contacts are asked to update them.
• Backup and recovery test. Recovery from backup is tested at least annually to confirm that the recovery procedures referenced in this plan function as expected. Results are documented in the Backup & Recovery Policy.

Full document available on request

The complete Incident Response Plan — including full response runbooks, notification templates, evidence collection checklists, and contact lists — is available as a controlled PDF document to enterprise clients and procurement teams on request.