Security incident response

1. Detection

Sensitive actions (login, student contact, data export) are written to the audit log in append-only fashion: entries are not edited or deleted, and rows are retained for 24 months. Match override and credential revocation are defined as audit actions but nothing writes them today. Opening an incident remains a human decision — there is no automatic trigger wired to these patterns.

2. Real-time escalation

There is no automatic escalation wired today. lib/incident-response.ts defines four severities (low / medium / high / critical) and can post to an on-call Slack channel, but the webhook it needs (SLACK_INCIDENT_WEBHOOK_URL) is unset and nothing in the app calls it. Incidents are opened by a person reading the audit log.

3. Classification (EDPB Guidelines 01/2021)

• Confidentiality — data disclosed to unauthorized party.
• Integrity — data altered in an unauthorized way.
• Availability — data inaccessible to authorized parties.
• Suspected intrusion — abuse pattern detected but not yet confirmed.

4. Authority notification (Art. 33)

For personal-data breaches likely to risk the rights and freedoms of natural persons, we notify the Italian DPA (Garante per la Protezione dei Dati Personali) within 72 hours of discovery. The notification is drafted from the audit-log entries relating to the incident.

Authority: garanteprivacy.it

5. Data-subject notification (Art. 34)

When the breach is likely to result in a high risk to user rights, we notify them directly by email — describing the nature of the breach, data categories affected, mitigations taken, and contact points. No communication until the impact has been contained.

6. Post-mortem and prevention

For every medium-or-higher incident we run a post-mortem within 14 days: root causes, missing controls, corrective actions. Post-mortems stay internal for security reasons; an aggregate summary is published annually in the security report.