Unauthorised access or disclosure
Suspected or confirmed access to client data, credentials, environments, reports, models, source code, or confidential business information by an unauthorised person.
Trust Center · Incident Response
A structured approach to security and data incidents.
We use a measured, evidence-led process to identify, assess, contain, investigate, remediate, recover from, and learn from incidents that may affect data consulting, analytics, AI, cloud, reporting, automation, or managed data engagements.
Specific actions, roles, communication routes, and notification obligations depend on the confirmed facts, engagement scope, applicable law, and contractual requirements. This page does not create a fixed response or notification commitment.
Executive summary
Incident response is both a technical and business process.
For data and AI engagements, an event can affect not only infrastructure but also datasets, reports, access credentials, models, automation, intellectual property, service continuity, and stakeholder obligations.
- Risk-based decisions We consider the nature, likelihood, scope, persistence, and potential impact of the event rather than relying on a single indicator.
- Evidence before conclusions Initial assessments can change as logs, system records, stakeholder input, and technical findings become available.
- Shared responsibilities Effective response may require coordinated action by our team, the client, platform providers, vendors, legal advisers, or other authorised parties.
- Context-specific notification Communication and notification decisions depend on confirmed facts, contract terms, applicable roles, and legal or regulatory analysis.
Recognising an incident
What may be considered a security or data incident
A reported concern is assessed on its facts. The following examples illustrate events that may require review; they do not form an exhaustive or automatic classification list.
Loss of confidentiality, integrity, or availability
Events that may expose information, alter data or outputs without authorisation, or materially disrupt agreed data, analytics, AI, reporting, or managed-service activities.
Malicious or suspicious activity
Phishing, compromised credentials, malware indicators, unusual account behaviour, attempted intrusion, misuse of access, or activity that may require investigation.
Operational or handling error
Incorrect sharing, unintended deletion, misconfiguration, mistaken recipient selection, inappropriate permission assignment, or another error affecting protected information or delivery.
Detection and reporting
Concerns should be easy to raise and safe to assess.
Signals may come from monitoring, access reviews, delivery checks, system alerts, employees, clients, vendors, or other authorised stakeholders. A concern can be reported before its cause or impact is known.
Detection sources
Depending on the engagement and available systems, detection may draw on logs, alerts, quality checks, access activity, service observations, user reports, or platform notifications.
Reporting channels
Clients should use the verified security contact, agreed project escalation route, or authorised support channel. Urgent reports should clearly identify the engagement and a safe return contact.
Response lifecycle
A coordinated path from initial signal to corrective action
Stages can overlap, repeat, or occur in a different order. The response is adapted to the nature of the incident, available evidence, affected systems, and engagement responsibilities.
Detect and report
Capture the concern through available reporting routes and preserve the initial facts.
Triage and assess
Validate the event, identify affected assets and stakeholders, and determine priority.
Contain
Limit further exposure or disruption while considering business and evidence needs.
Investigate
Establish scope, chronology, likely cause, impact, and available evidence.
Remediate
Remove contributing conditions, correct weaknesses, and implement proportionate actions.
Recover and validate
Restore affected services or workflows and verify that corrective measures are effective.
Review and improve
Document lessons, assign actions, and update relevant practices where warranted.
Triage and severity assessment
Triage aims to determine whether an event is credible, what may be affected, who should be involved, and which immediate decisions are required. Severity is not treated as permanent; it can increase or decrease as the investigation develops.
- Nature and sensitivity of the data, systems, credentials, or intellectual property involved
- Evidence of unauthorised access, disclosure, alteration, loss, misuse, or exfiltration
- Number and type of affected clients, users, records, systems, or business processes
- Operational impact, persistence, exploitability, and whether the event remains active
- Potential contractual, privacy, legal, regulatory, financial, or reputational consequences
- Availability and reliability of evidence, including logs, records, messages, and system context
Contain, investigate, remediate
Response actions balance risk reduction, evidence, and service needs.
Actions are selected according to the event and may require coordination with the client or relevant platform, cloud, identity, security, legal, privacy, or operational teams.
Containment
Potential measures may include restricting access, isolating an account or workflow, pausing a transfer, changing credentials, correcting permissions, blocking suspicious activity, or temporarily suspending an affected process.
Investigation and evidence preservation
The investigation may review timelines, access records, logs, files, communications, configurations, user actions, and third-party information, subject to availability, authority, retention, and legal considerations.
Eradication and remediation
Corrective work may remove malicious artefacts, close inappropriate access, repair configurations, update credentials, change workflows, improve validation, or address another identified contributing condition.
Recovery and validation
Recovery is more than restarting a service. It includes confirming that affected access, systems, datasets, reports, models, automations, or delivery processes can return to an acceptable operating state.
- Confirm agreed remediation actions are implemented.
- Validate affected access and permissions.
- Review data, output, or workflow integrity where relevant.
- Observe for recurrence or continuing suspicious activity.
- Coordinate service restoration with authorised stakeholders.
- Document residual risks, dependencies, and follow-up work.
Communication and notification
Clear communication should reflect verified facts and assigned responsibilities.
Communication may evolve as the investigation develops. Early updates can contain uncertainty, and later findings may refine the scope, impact, cause, or required actions.
| Consideration | Our approach | Key dependency |
|---|---|---|
| Client communication | Relevant clients or engagement contacts may receive factual updates appropriate to the incident, available evidence, and agreed communication route. | Confirmed relevance, stakeholder contacts, confidentiality, and contract terms. |
| Content of updates | Updates may cover known facts, affected services or data, actions taken, requested client steps, current limitations, and planned next actions. | Investigation maturity and information approved for release. |
| Regulatory or legal notification | Applicable privacy, legal, regulatory, and contractual duties may be assessed with authorised stakeholders. We do not treat every event as automatically notifiable. | Jurisdiction, legal role, data type, risk, contract, and confirmed facts. |
| Timing | Timing follows verified procedures and applicable obligations. This public page does not promise a universal fixed timeline. | Contractually confirmed requirements and legal analysis. |
| External statements | Public, media, customer, or third-party statements should be coordinated and approved by the authorised parties. | Ownership, confidentiality, accuracy, and legal review. |
Important legal and contractual consideration
This page provides general information about our approach and is not legal advice. Notification duties can differ by jurisdiction, data type, contractual role, risk level, and the relationship between parties. Verified legal, privacy, security, and contractual requirements take precedence.
Root cause and improvement
The objective is not only to close the incident, but to reduce recurrence.
After stabilisation, the response can examine why the event occurred, which controls or assumptions contributed, and what proportionate corrective actions should follow.
Root cause analysis
Analysis may distinguish the immediate trigger from deeper contributing factors such as access design, configuration, process gaps, human error, unclear ownership, dependency failure, or insufficient validation.
Corrective actions
Actions may be assigned to technical, operational, governance, training, documentation, vendor, or engagement owners, with priority based on risk, feasibility, and scope.
Post-incident review
A review may consider response effectiveness, communication, decision points, evidence quality, unresolved risks, and opportunities to improve plans, controls, or shared responsibilities.
Shared responsibility
Client responsibilities when a concern is suspected
Prompt, coordinated client action can materially improve assessment and containment, especially where the client controls relevant identities, environments, data sources, devices, platforms, or third-party relationships.
Report promptly
Share suspected issues as soon as reasonably possible through the agreed project or security channel rather than waiting for complete certainty.
Preserve context
Retain relevant emails, screenshots, timestamps, logs, file names, user details, error messages, and other information that may support assessment.
Avoid unnecessary changes
Unless needed to reduce immediate harm, avoid deleting evidence, resetting affected environments, or making broad changes before coordination with the response contact.
Coordinate communications
Do not make statements on our behalf. Align on facts, ownership, notification obligations, and communication responsibilities where the engagement requires joint action.
What this means for clients
A due-diligence view of our incident response approach
- Concerns can be raised before full evidence is available.
- Assessment is risk-based and may change as facts develop.
- Containment considers business impact and evidence preservation.
- Communication is aligned to relevance, facts, contracts, and law.
- Clients may have important actions within shared environments.
- Corrective actions and lessons can inform future delivery practices.
Related Trust Center pages
Continue your security and supplier review
Use these pages to understand related practices, responsibilities, and engagement considerations.
Frequently asked questions
Incident response questions from buyers and reviewers
These answers support procurement, security, legal, privacy, technical, and operational review without replacing engagement-specific documentation.
What should be reported as a suspected security or data incident?
Report any event that may involve unauthorised access, disclosure, alteration, deletion, loss, misuse, suspicious account activity, malware, misdirected information, unexpected system behaviour, or disruption affecting an engagement. Reporting a concern does not require proof that an incident has occurred.
How can a client report a security concern?
Use the security or project contact identified for the engagement. Before publication, this page should be updated with the company’s verified security-reporting email address or secure reporting form. For urgent matters, clients should also use agreed escalation routes.
What information should be included in an initial report?
Useful details include when the issue was noticed, affected users or systems, relevant project or account information, what occurred, actions already taken, screenshots or error messages, and a safe method for follow-up. Do not send passwords or highly sensitive evidence through an unapproved channel.
How do you decide the severity of an incident?
Our approach considers the information and systems involved, likely impact, affected parties, evidence of access or misuse, whether activity is ongoing, operational disruption, and potential contractual, privacy, legal, or regulatory implications. The assessment may change as facts develop.
Do you promise a fixed incident-response or notification time?
No general fixed timeline is stated on this page. Response, escalation, and notification expectations depend on verified company procedures, the engagement contract, applicable law, the nature of the event, and the information available. Contractually agreed timelines apply where confirmed.
Will clients always be notified about every security event?
Not every alert, attempted event, or operational anomaly becomes a reportable incident. Communication depends on validation, relevance to the client or engagement, contractual requirements, applicable legal obligations, and the assessed risk or impact.
How is evidence preserved during an investigation?
Where relevant and available, the response may preserve logs, access records, messages, file details, configuration information, timelines, and other artefacts. Collection and retention depend on system capability, access rights, engagement scope, legal considerations, and documented practices.
Can incident response affect service availability?
Containment or investigation may require temporary access restrictions, credential changes, process pauses, isolation, or other measures. Decisions should balance risk reduction, evidence preservation, client priorities, and operational continuity.
How are privacy or regulatory notification duties assessed?
Relevant legal, privacy, security, and contractual stakeholders may assess whether notification obligations apply. The decision depends on jurisdiction, role, data type, affected individuals, risk, contract terms, and confirmed facts. This page is not legal advice.
What happens after containment?
The response may continue with investigation, cause analysis, removal of contributing conditions, remediation, recovery, validation, stakeholder communication, and documentation of follow-up actions. The exact sequence can overlap or change according to the event.
Do you conduct a root cause analysis for every incident?
Root cause analysis is considered according to severity, complexity, recurrence, available evidence, and business value. Some events may require a focused causal review, while more significant incidents may warrant a formal analysis and tracked corrective-action plan.
How are lessons from incidents used?
Relevant lessons may inform updates to procedures, access practices, monitoring, training, technical configurations, client guidance, vendor oversight, documentation, or service design. Actions are prioritised according to risk, feasibility, ownership, and engagement scope.
What responsibilities remain with the client?
Clients remain responsible for promptly reporting suspected issues, protecting their credentials and environments, preserving relevant evidence, maintaining accurate contacts, following agreed security responsibilities, and coordinating actions or notifications assigned to them by contract or law.
Can procurement or security teams request supporting documentation?
Yes. Available documentation can be discussed through the Trust Team or engagement contact, subject to confidentiality, security sensitivity, relevance, and company approval. Some materials may require a non-disclosure agreement or controlled review process.
Report a Security Concern
Share a suspected issue through the approved reporting route.
Provide a factual summary, the affected engagement or service, when the issue was observed, and a safe contact method. Avoid sending credentials or unnecessary sensitive data through an unapproved channel.
For due-diligence documentation rather than an active concern, contact the Trust Team or your authorised business representative.