Incident Response Policy

2026-01-01

This policy defines how RevLog identifies, responds to, and recovers from security incidents affecting our wiki service and related infrastructure. It ensures compliance with GDPR breach notification requirements and establishes clear procedures for incident handling.

This policy applies to:

• The RevLog DokuWiki service and underlying infrastructure
• All data processed by the service, including personal data
• All administrators and personnel with access to systems

• Unauthorised access to user accounts or administrative systems
• Data leakage or accidental exposure of personal data
• Malware infection or ransomware
• Denial of service attacks
• Loss or theft of devices containing service data
• Credential compromise
• Defacement or unauthorised modification of wiki content

For RevLog, these roles may be held by the same person depending on team size.

Primary contact: revlog@unige.ch

Goal: Detect and confirm incidents as quickly as possible.

Detection sources:

• Monitoring alerts (Prometheus/Grafana)
• Log analysis (Victoria Logs, system logs)
• User reports
• Automated security scans
• Third-party notifications (e.g., SWITCH, eduGAIN, UNIGE IT)

Actions:

1. Assess whether the event is a confirmed incident or false positive
2. Document initial observations (time, source, affected systems)
3. Assign severity level (see Section 6)
4. Open an incident record ### 5.2 Containment

Goal: Limit the impact and prevent further damage.

Short-term containment:

• Isolate affected systems (e.g., block IPs, disable compromised accounts)
• Preserve evidence (logs, memory dumps, disk images)
• Revoke compromised credentials

Long-term containment:

• Apply temporary fixes or workarounds
• Increase monitoring on affected systems
• Communicate with affected users if necessary

Do not:

• Delete logs or evidence
• Shut down systems before preserving volatile data (unless necessary for safety)

Goal: Remove the root cause of the incident.

Actions:

• Identify and patch vulnerabilities
• Remove malware or unauthorised access mechanisms
• Reset compromised credentials
• Review and harden configurations
• Update affected software/dependencies

Goal: Restore normal operations safely.

Actions:

1. Restore systems from clean backups if necessary
2. Verify system integrity before returning to production
3. Monitor closely for signs of recurring issues
4. Gradually restore services with enhanced logging
5. Confirm with users that service is restored

Goal: Learn from the incident and improve defences.

Actions (within 5 business days of resolution):

1. Conduct a post-mortem meeting
2. Document timeline, root cause, and response effectiveness
3. Identify what worked well and what needs improvement
4. Update procedures, configurations, or monitoring as needed
5. Archive incident record

Under GDPR Article 33-34, personal data breaches must be reported:

Deadline: Within 72 hours of becoming aware of a breach (if it poses a risk to individuals).

Report to:

• FDPIC (Switzerland): https://www.edoeb.admin.ch
• CNIL (France): https://www.cnil.fr

Report must include:

• Nature of the breach and categories of data affected
• Approximate number of individuals affected
• Contact details for further information
• Likely consequences of the breach
• Measures taken or proposed to address the breach

Required when: The breach is likely to result in a high risk to individuals' rights and freedoms.

Notification must include:

• Clear description of the breach
• Contact point for questions
• Likely consequences
• Measures taken and recommended user actions

Template: See Appendix A

• Use secure channels for incident discussion
• Limit information to those with a need to know
• Document all communications in the incident record

For all incidents, preserve:

• System and application logs
• Authentication logs
• Network traffic captures (if available)
• Screenshots or recordings of anomalous behaviour
• Timeline of events and actions taken

Store evidence securely and maintain chain of custody documentation for potential legal proceedings.

• Annual review: Update this policy at least once per year
• Tabletop exercises: Conduct incident response drills annually
• Post-incident updates: Revise procedures based on lessons learned

RevLog Incident Response
Email: revlog@unige.ch

UNIGE IT Security (if applicable)
[UNIGE security contact]

SWITCH CERT
Email: cert@switch.ch
https://www.switch.ch/security/

Subject: Security Incident Notification — Action May Be Required

Dear [User],

We are writing to inform you of a security incident affecting the RevLog wiki service.

What happened:
[Brief description of the incident]

What data was affected:
[Types of data involved]

What we are doing:
[Steps taken to contain and remediate]

What you should do:
[Recommended actions, e.g., review account activity, be alert for phishing]

Questions?
Contact us at revlog@unige.ch

We sincerely apologise for any concern this may cause and are committed to protecting your data.

RevLog Team