Incident Response Policy [RevLog]

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
# Incident Response Policy

*2026-01-01*

## 1. Purpose

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.

## 2. Scope

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

## 3. Definitions

^ Term ^ Definition ^
| *Security incident* | Any event that compromises the confidentiality, integrity, or availability of systems or data |
| *Personal data breach* | A security incident involving unauthorised access, disclosure, alteration, or destruction of personal data |
| *Near miss* | An event that could have resulted in an incident but was prevented or detected before impact |

### Examples of Incidents

- 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

## 4. Roles and Responsibilities

^ Role ^ Responsibilities ^
| *Incident Lead* | Coordinates response, makes decisions, communicates with stakeholders |
| *Technical Responder* | Investigates, contains, and remediates technical issues |
| *Communications Lead* | Handles user and external notifications |

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

**Primary contact**: revlog@unige.ch

## 5. Incident Response Phases
### 5.1 Identification

**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)

### 5.3 Eradication

**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

### 5.4 Recovery

**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

### 5.5 Post-Incident Review

**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


## 6. Severity Classification

^ Severity ^ Description ^ Response Time ^ Examples ^
| *Critical* | Major breach, data exfiltration, complete service outage | Immediate (< 1 day) | Database compromise, ransomware, mass data leak |
| *High* | Significant impact, potential data exposure, partial outage | < 2 day | Admin account compromise, targeted attack, authentication bypass |
| *Medium* | Limited impact, contained threat, degraded service | < 1 week | Single account compromise, failed intrusion attempt, suspicious activity |
| *Low* | Minimal impact, near miss, policy violation | < 2 weeks | Misconfiguration detected, minor policy breach, spam |

## 7. GDPR Breach Notification

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

### 7.1 Supervisory Authority Notification

**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

### 7.2 User Notification

**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

## 8. Communication

### Internal Communication

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

### External Communication

^ Audience ^ When to Notify ^ Method ^
| Affected users | High-risk breaches, service outages | Email, wiki notice |
| UNIGE IT Security | All significant incidents | Email, phone |
| SWITCH Security | Federation-related incidents | sectort@switch.ch |
| Supervisory authority | Personal data breaches (per GDPR) | Official reporting form |

## 9. Evidence Preservation

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.

## 10. Testing and Maintenance

- **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

## 11. Contact Information

**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/

---

## Appendix A: User Breach Notification Template

**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

---

## Appendix B: Incident Record Template

^ Field ^ Details ^
| Incident ID | INC-[YYYY]-[NNN] |
| Date/time detected | |
| Date/time reported | |
| Reported by | |
| Severity | Critical / High / Medium / Low |
| Status | Open / Contained / Resolved / Closed |
| Summary | |
| Affected systems | |
| Affected users | |
| Root cause | |
| Actions taken | |
| GDPR notification required | Yes / No |
| Notification sent | Date, recipient |
| Post-mortem completed | Yes / No |
| Lessons learned | |