Breach Response Procedure

Purpose and scope

This procedure defines how Virtus Group identifies, manages, and communicates security incidents and privacy breaches that could affect clients, client data, or the integrity of services.

It covers suspected and confirmed incidents across people, process, technology, and third‑party suppliers, including remote work and cloud services.

• We treat client impact as the primary driver for communications and prioritisation.
• We preserve evidence, maintain an audit trail, and run a post‑incident review for material incidents.
• Where legal or contractual notification obligations exist, we follow the strictest applicable requirement.

Key definitions (plain language)

• Security incident: any event that threatens confidentiality, integrity, or availability (CIA) of systems, services, or information (including malware, credential misuse, unauthorised access, or data exfiltration attempts).
• Privacy breach: unauthorised or accidental access, disclosure, alteration, loss, or destruction of personal information.
• Client data: any information provided by, generated for, or derived from a client environment, including logs, configurations, and operational records.
• Client impact: confirmed or suspected effect on a client’s confidentiality, integrity, availability, or service outcomes.

Roles and responsibilities

• Incident Lead: coordinates response, decisions, and evidence capture; maintains timeline and decision log.
• Technical Leads: execute containment, eradication, recovery, and validation steps within their domain (identity, endpoint, network, cloud, backup).
• Comms Owner: prepares client notifications and status updates using approved channels and contact lists.
• Client Owner: client‑side incident contact (nominated by the client); receives notifications and coordinates internal communications and approvals.
• Privacy Lead (if applicable): assesses notifiability of privacy breaches and coordinates privacy reporting where required.

Response lifecycle (end‑to‑end)

We use a structured lifecycle to ensure consistent, auditable outcomes.

• 1) Detect & triage: validate the signal, classify severity, identify affected assets, and start the incident timeline.
• 2) Contain: stop spread and prevent further compromise (e.g., isolate hosts, disable accounts, block IOCs, revoke tokens).
• 3) Assess impact: determine what happened, what data/systems are affected, and the likelihood of client impact.
• 4) Notify: inform impacted clients when an incident affects, or may affect, them (see Notification section).
• 5) Eradicate: remove attacker persistence, close the root cause, harden controls, and rotate credentials/keys.
• 6) Recover: restore services/data from known‑good points; validate integrity; monitor for recurrence.
• 7) Post‑incident review: document lessons learned, corrective actions, and control improvements.

Client notification obligations

We notify a client whenever the client is impacted, or could reasonably be impacted, by a security incident or privacy breach.

This includes (but is not limited to): unauthorised access, compromise, or unauthorised exfiltration of client data; or any incident that threatens the security or integrity of the services, client confidential information, or client data.

• Initial heads‑up: as soon as practicable after detection and triage, and no later than 24 hours where client impact is suspected.
• Status updates: cadence agreed with the client based on severity (e.g., every 2–4 hours for high severity; daily for lower severity).
• Final report: summary of cause, timeline, impact, actions taken, and preventive controls, provided after recovery and validation.

Notification channels and content

Client notification uses the client’s nominated contacts and agreed channels. We avoid unsecured channels for sensitive details.

• Primary: phone call to the client incident contact, followed by email to the nominated security/ICT mailbox
• Secondary: secure collaboration channel (e.g., approved Teams channel) for ongoing updates where established
• What we include (initial notice): incident summary, suspected scope, affected systems/data, containment actions taken, immediate client actions required, and next update time
• What we include (follow‑ups): confirmed impact, root cause hypothesis, evidence summary, remediation plan, and restore/validation status

Evidence, records, and audit trail

• Maintain an incident timeline with timestamps (detection, containment, decisions, comms).
• Capture relevant logs, alerts, screenshots, and exported reports (stored with integrity controls).
• Record decisions (go/no‑go, restore point selection, scope change) in a decision log.
• Preserve artefacts required for insurance, legal, or client assurance requests where applicable.

Continuous improvement and control uplift

• Run a post‑incident review for material incidents within 5–10 business days of closure.
• Create corrective actions with owners and due dates; track in an improvement backlog.
• Update runbooks, detection logic, and access controls based on observed gaps.
• Validate changes via restore drills, tabletop exercises, or targeted re-tests.