In brief
- Incorrect output and security incidents are different, although they can overlap.
- Prompts, responses, tool calls and permissions are important evidence.
- A processor informs the controller as soon as possible; the controller assesses risk and makes the statutory notification decision.
- The notification decision follows risk to affected people, not media visibility.
- Even non-notifiable events should be documented and used for improvement.
Establish what happened
Under Swiss law, a data security breach occurs when personal data is accidentally or unlawfully lost, deleted, destroyed, modified or disclosed or made accessible to unauthorised persons. A factually incorrect answer without personal data may be a quality incident but not a data breach.
- RAG exposes documents or passages to unauthorised users.
- A prompt or log containing personal data reaches the wrong recipient.
- An agent writes or deletes personal records outside its authority.
- A provider or subprocessor reports unauthorised access.
- A manipulated document triggers disclosure through a tool.
Contain the event without losing important evidence
Initial action should stop further impact while preserving a reliable investigation. The incident team may need business, security, privacy, operations and provider representatives.
- Step 1
Contain
Restrict or disable the affected function, connector or key.
- Step 2
Preserve evidence
Secure timestamps, prompts, responses, tool calls, roles and changes without alteration.
- Step 3
Determine scope
Identify affected data, people, recipients, systems and time periods.
- Step 4
Coordinate the provider
Use contractual incident channels and request reliable facts and remedial action.
The processor reports; the controller assesses and decides
Under Article 24 paragraph 3 FADP, a processor must inform the controller of a data security breach as soon as possible. It should pass on known facts and continue supplying updates rather than waiting for a complete root-cause analysis.
The controller remains responsible for assessing risk to affected people, notifying the FDPIC where the high-risk threshold is likely met and deciding whether affected people must be informed. Contracts should therefore define an immediate incident channel, evidence access and update duties without making the processor’s first notice depend on the controller’s legal notification threshold.
- Processor: contain within its remit, preserve evidence, alert the controller and provide verified updates.
- Controller: coordinate the full data flow, assess consequences and safeguards, record the decision and make required notifications.
- Both: identify subprocessors, recipients and affected features and keep a reliable timeline.
Assess risk and notification separately from technical severity
Risk assessment considers the nature and sensitivity of the data, number and vulnerability of affected people, possible consequences, actual access and effectiveness of safeguards. Under the Swiss FADP, notification to the FDPIC is triggered by a likely high risk.
- Notify the FDPIC as soon as possible where the statutory threshold is met.
- Inform affected people where necessary for their protection or when required by the FDPIC.
- Assess other applicable timelines and bodies, including GDPR or sector rules, separately.
- Document the decision, available facts, uncertainty and later updates.
- Do not apply the GDPR’s 72-hour rule indiscriminately to every Swiss case.
Record the decision and give the FDPIC the required substance
Every assessed breach needs an internal decision record, including when the conclusion is that no notification is required. The record should make the information available at the time, the risk reasoning and later corrections traceable.
- Internal decision record
- Record detection and event timeline, affected systems, data and people, known or possible recipients, likely consequences, existing safeguards, uncertainties, containment and remediation, the notification and communication decisions, accountable decision-makers and subsequent updates.
- Notification to the FDPIC
- A required notification must state the nature of the breach; where possible its time and duration; the categories and approximate numbers of affected people and personal-data records; the consequences; measures taken or planned; and the name and contact details of a contact person. Information that is not yet available must be supplied without delay as it becomes known.
- Statutory retention after notification
- Where a breach is notified under Article 24 FADP, the facts, effects and measures taken must remain documented for at least two years from the notification. A longer internal incident-retention period may be appropriate, but it should be set separately and justified by purpose and applicable duties.
Improve the system and governance after the incident
Remediation does not end with a patch. Root causes may lie in permissions, classification, missing tests, unclear ownership or product change. Corrective action should span technical and organisational controls.
- Add the incident to access and RAG regression tests.
- Tighten agent permissions, approvals and stop conditions.
- Clarify data rules, training and reporting channels.
- Update provider and subprocessor controls.
- Revise the AI inventory, DPIA, runbook and risk assessment.
- Demonstrate effectiveness through a repeat test.
Example: Incorrect permission inheritance in a knowledge assistant
After a change, an assistant shows extracts from confidential HR documents to a small user group. The team disables the source, preserves search and response logs and identifies users, documents and access events. Privacy and security assess impact and notification duties. The permission logic is corrected, negative tests are added and an independent check precedes reactivation.
What to remember
Extend the existing incident response process to cover AI artefacts, provider channels and business consequences. Exercise the process before a real event creates time pressure.
Sources and further reading
These primary sources provide further detail on definitions, technical foundations or responsible use.
Content reviewed
Reviewed 17 July 2026. General information, not legal advice. The specific legal position and applicable scope must be assessed for each use case.