Incident Response & Breach Notification
No organisation can promise that an incident will never happen. What we can promise is a prepared, documented and fast response that protects your data, keeps you informed and meets every legal and contractual obligation. This page summarises our Incident Response and Breach Notification Procedure (FX-IRP-01).
1. What counts as an incident
An incident is any event that has compromised, or may have compromised, the confidentiality, integrity or availability of client data or of the systems we use to process it. Examples include:
- A document or email sent to the wrong recipient.
- A lost or stolen laptop or phone used for firm work.
- A compromised email, cloud or accounting-software account, including through phishing.
- Unauthorised access to a client folder or system.
- Malware or ransomware on a device used for firm work.
- Accidental deletion or corruption of client records.
2. Reporting
Every person in the firm must report a suspected incident to the Security Owner immediately, even if they are unsure whether it is serious. Reporting is never penalised; delay in reporting is. Clients, vendors and members of the public can report a concern to [email protected] with "Security" in the subject line.
3. Response phases
Phase 1: Contain
- Revoke or reset affected credentials and sessions; enforce MFA re-enrolment where relevant.
- Remote-lock or wipe lost devices where possible.
- Withdraw wrongly shared links and request deletion and written confirmation from any unintended recipient.
- Isolate affected systems and preserve logs and evidence.
Phase 2: Assess
- Establish what happened, when, how, which data and which clients are affected, and the likely risk to individuals and to the client.
- Record every step and decision in the incident log.
Phase 3: Notify
- Clients: affected clients are notified without undue delay, and in any case within the period agreed in the client contract (our standard commitment is within 72 hours of becoming aware). The notice explains what is known, the data involved, the steps taken, recommended actions and a named contact.
- CERT-In: cyber-security incidents of the types specified under Indian law are reported to the Indian Computer Emergency Response Team within the time required by its directions.
- Other authorities and individuals: where the client is the data controller, we provide all the information the client needs to make any notification it must make under its own laws (for example under GDPR, UK GDPR, US state breach laws or the Australian Notifiable Data Breaches scheme). We do not notify regulators or individuals on the client's behalf unless the client instructs us or the law requires us to.
Phase 4: Recover
- Restore data and services from clean sources, verify integrity, and resume work only when the cause has been removed.
Phase 5: Learn and improve
- Identify the root cause, update controls, training and procedures, and share a written post-incident summary with affected clients.
4. Roles
| Role | Responsibility during an incident |
|---|---|
| Security Owner (Partner) | Leads the response, decides on notifications, keeps the incident log. |
| Engagement Partner | Communicates with the affected client and coordinates any client actions. |
| Engagement Manager | Identifies affected data and engagements, supports containment and recovery. |
| All personnel | Report immediately, preserve evidence, follow instructions, keep the matter confidential. |
5. Records and testing
All incidents, including near misses, are recorded with their root cause and corrective actions. The procedure is reviewed at least annually, and after every significant incident, to make sure it still works in practice.
Questions about security?
We are happy to complete your vendor-security questionnaire and walk your team through our controls.