Security incident response procedure
How Verbalu handles a security incident: who detects it, who makes the decisions, and who notifies the customer and within what time.
Version 1.0, effective from 12 November 2026. The procedure is new and has not yet been tested in an exercise. The notification deadlines are consistent with the data processing agreement; if the agreement with the customer provides otherwise, the agreement prevails.
Ce document est disponible en polonais, en anglais et en espagnol.
1. Purpose and scope
An incident is any event that compromises or may compromise the confidentiality, integrity or availability of customer data or of the Verbalu service itself: unauthorised access, disclosure, loss or alteration of data, account takeover, a detected vulnerability and an outage. The procedure covers personal data breaches within the meaning of the GDPR and incidents that a customer which is an entity covered by the NIS2 Directive must know about as a recipient of the service.
2. Roles
Reporter: any person who notices an event, including an employee or associate of Octigo, a customer, a participant or a security researcher. Incident coordinator: a person from the Verbalu team who receives reports and alerts, runs the handling of the incident from receipt to closure and documents its course. Decision-maker: a member of the management board of Octigo sp. z o.o., who approves the classification of incidents at the high and critical levels and decides on notifying customers and authorities, on disabling a feature or the service and on involving a lawyer. Customer contact: the person designated by the customer in the agreement or in the security annex. Octigo is a small team, so one person may combine the roles of coordinator and decision-maker; the decision on notification is always made by a member of the management board.
3. Who detects
An incident may be detected by a system or by a person. Automatically: the audit log sends an alert by email when password guessing is suspected, when Verbalu administrator permissions are granted and when entries do not match the nightly seal; the external UptimeRobot monitor reports that the site is unavailable (https://stats.uptimerobot.com/67oKoekA03); the service reports AI provider errors by email; Google Cloud and the other subcontractors give notice of events on their side. By people: reports from customers, users and security researchers to hello@verbalu.com, and observations of the team. Every team member who notices an event passes it to the coordinator immediately, without assessing on their own whether it is a "real" incident.
4. Classification
Critical: confirmed unauthorised access to customer data, its loss or disclosure, or unavailability of the entire service. High: a probable data breach, takeover of the account of an organisation owner or administrator, or unavailability of a key feature, such as sign-in or joining a session. Medium: a vulnerability with no traces of exploitation, or a failure of a single tool. Low: an event with no impact on data or availability. The level may be changed during handling when new findings emerge; in case of doubt, the higher level is adopted.
5. Who decides
The coordinator acknowledges receipt of the report and makes a preliminary classification of the event. The coordinator passes an incident at the high or critical level to the decision-maker immediately. The decision-maker approves the level, decides on measures to limit the effects that have an impact on customers (blocking accounts, disabling a feature, an interruption of the service) and on the content and recipients of notifications. The coordinator records every decision in the incident register together with the time it was made. The coordinator handles incidents at the low and medium levels independently and informs the decision-maker about them in the periodic review.
6. Notifying the customer
The customer is notified by the coordinator, after the content has been approved by the decision-maker. The notification is sent by email to the contact designated by the customer, and additionally by telephone if the customer has provided a number. Deadline: without undue delay, no later than 24 hours after establishing that the incident concerns customer data or materially limits the availability of the service for the customer. The first notification contains what is known: the nature of the event, the categories and approximate number of persons and records concerned, the possible consequences, the measures taken and planned, and the details of the contact person. If some of the information cannot be provided immediately, we provide it in stages: supplementary information within 72 hours of establishing the incident, and a final report with the cause and preventive measures within 30 days of closing the incident.
7. Notifying authorities and data subjects
For the data of participants and students, the customer is the controller and Octigo is the processor: we notify the customer, and it is the customer who assesses whether to report the breach to the supervisory authority and to the data subjects. We assist the customer in this by providing the information needed for the report. For the data of trainer and organiser accounts, Octigo is the controller: we report the breach to the Polish supervisory authority (President of the Personal Data Protection Office, UODO) within 72 hours of establishing it, unless it is unlikely to result in a risk to the rights or freedoms of persons, and where the risk is high we also notify those persons. To a customer that is itself subject to NIS2, we provide the information needed for its early warning (24 hours) and incident notification (72 hours).
8. Limiting the effects and restoring operation
Depending on the event: blocking or signing out accounts, replacing access keys and passwords, disabling a feature, a fix and its deployment, and in the event of data loss a restore from a backup (the worst-case recovery point is the last weekly backup). We secure evidence against alteration: the application audit log is retained for 13 months and protected by checksums and daily seals, and operations on the infrastructure are recorded by Google Cloud logs.
9. Closure and lessons learned
An incident is closed by the coordinator, and at the high and critical levels by the decision-maker. Every incident is entered in the incident register kept by Octigo: description, time of detection, level, decisions, notifications, cause and corrective measures. After a high or critical incident we prepare a review with lessons learned. We review the procedure at least once a year and after every high or critical incident.
10. Contact
Reports: hello@verbalu.com, subject "Security incident". In the report, state what was noticed and when, which organisation or session it concerns and how to contact you. Do not send passwords or the personal data of third parties in the report.
| Stage | Deadline | Who does what |
|---|---|---|
| Receipt of the report | No later than the next working day | The coordinator acknowledges receipt to the reporter and creates an entry in the incident register. |
| Preliminary classification | On the day the report is received | The coordinator assigns a level: low, medium, high or critical. |
| Escalation | Immediately | The coordinator passes a high or critical incident to a member of the Octigo management board. |
| Decision on notification | Before the notification deadline expires | A member of the management board approves the level, the recipients and the content of the notification. |
| First notification to the customer | Within 24 hours of establishing the incident | Coordinator: email to the customer contact, additionally a telephone call if a number has been provided. |
| Supplementary information | Within 72 hours of establishing the incident | Coordinator: scope, assessment of effects, measures taken and planned. |
| Report to UODO | Within 72 hours of establishing the incident | A member of the management board, only when Octigo is the data controller. In other cases the customer reports, with our assistance. |
| Final report | Within 30 days of closure | Coordinator: cause, course of events, preventive measures. Approved by a member of the management board. |