Skip to main content

Overview

This runbook covers incident response for PensionsPortal.ie, an IORP II compliance platform handling GDPR-protected personal data (including AES-256 encrypted PPS numbers) for Irish pension trustees. Incidents must be handled in compliance with GDPR Art. 33 (72-hour breach notification), DORA Art. 17 (ICT incident reporting), and DORA Art. 13 (post-incident review).
This runbook must be reviewed and contacts updated before the platform goes live. All email addresses below are placeholders. Store the real contacts in the company password manager and link to this document from the on-call channel.

1. Incident Classification Matrix

When in doubt, escalate up. Downgrading a P0 to a P1 after assessment is always safer than under-escalating a genuine data breach. GDPR Art. 33 clock starts from when you “become aware” — not from when you finish your assessment.

2. On-Call Contacts

These are placeholder contacts. Replace with real names, phone numbers, and out-of-hours contact methods before production launch. Store actual contact details in the company password manager, not in this document.

3. P0 — Data Breach Response Procedure

Follow these steps sequentially. Time targets are maximums — act faster where possible.

Step 1 — Detect

An incident may be detected via:
  • Automated monitoring alerts (Vercel, Neon, Cloudflare)
  • User or broker report
  • Internal team discovery
  • Third-party security researcher notification
Immediately open an incident channel (e.g., #incident-YYYY-MM-DD) and assign an Incident Commander.

Step 2 — Contain (within 15 minutes)

Act to stop the bleeding before completing the full assessment. If an active external attack or breach is suspected:
If unauthorized internal access is suspected:
Log every containment action taken with timestamps in the incident channel.

Step 3 — Assess (within 1 hour)

Query audit logs to identify the scope of suspicious activity:
Complete the following assessment:
  • Identify the attack vector (how did the breach occur?)
  • Identify affected data categories (PII? PPS numbers? Compliance records? Documents?)
  • Estimate the number of affected data subjects (members, users)
  • Identify which tenants (brokers) are affected
  • Determine whether PPS encryption key may be compromised
  • Determine whether AUTH_SECRET may be compromised

Step 4 — Notify (within 72 hours — GDPR Art. 33)

The 72-hour clock runs from the moment you “become aware” of a breach involving personal data — not from when the investigation concludes. File the initial DPC notification even if the full scope is not yet known. You can supplement with additional information later.
Data Protection Commission (DPC) — GDPR Art. 33:
  • Notify at dpc.ie if any personal data is involved
  • Use the DPC’s online breach notification form
  • Include: incident date/time, data categories affected, estimated number of subjects, containment actions taken, remediation plan
Pensions Authority — DORA Art. 17:
  • Notify if the incident qualifies as a “significant ICT incident” (see Section 4 below)
  • Email: supervision@pensionsauthority.ie
  • Subject line: DORA Incident Notification — PensionsPortal.ie — [YYYY-MM-DD]
Affected Brokers / Trustees:
  • Notify affected broker firms via their registered contact email
  • Use the communication template in Section 7
Notification template:

Step 5 — Remediate

If PPS_ENCRYPTION_KEY may be compromised, follow the PPS Encryption Key Rotation Procedure in Section 5 before anything else. Additional remediation steps:
  • Patch the identified vulnerability
  • Reset credentials for any compromised accounts
  • Review and tighten Cloudflare WAF rules
  • Run full audit log review for the affected period
  • Verify all containment measures are still active
  • Re-enable normal operations only after remediation is confirmed

Step 6 — Post-Incident Review (within 5 business days — DORA Art. 13)

Write a post-mortem document covering: File the completed post-mortem with the DPO for GDPR Art. 30 Records of Processing Activities.

4. DORA ICT Incident Reporting

Per DORA Art. 17, significant ICT incidents affecting pension scheme operations must be reported to the Pensions Authority.

Classification as “Significant”

An ICT incident is significant if it:
  • Causes service unavailability affecting trustees’ ability to meet compliance obligations
  • Results in data loss or corruption affecting pension records
  • Involves a security breach affecting member PII or scheme data
  • Disrupts critical functions for more than a defined threshold period

Reporting Timeline

DORA Notification Email Format

Send to: supervision@pensionsauthority.ie

5. PPS Encryption Key Rotation Procedure

PPS key rotation is a destructive operation. Every PPS number in the database must be decrypted with the old key and re-encrypted with the new key. Perform this during a maintenance window with the application in read-only mode. A failed rotation can result in permanent data loss.
Follow these steps in order: Step 1 — Generate new encryption key:
Step 2 — Add new key to Vercel environment (do not remove old key yet):
Step 3 — Run key rotation migration:
Pre-launch requirement: The db:rotate-pps-key script must be implemented before the platform processes real PPS numbers. The script must: (1) select all members with a non-null pps_number_encrypted, (2) decrypt each with PPS_ENCRYPTION_KEY, (3) re-encrypt with PPS_ENCRYPTION_KEY_NEW, (4) update the record in a transaction, (5) log each rotation in audit_logs, (6) rollback on any error. Test this procedure end-to-end in staging before production launch.
Step 4 — Verify re-encryption:
Step 5 — Swap keys in Vercel environment:
Step 6 — Redeploy and verify:
After deployment:
  • Log in as a BrokerAdmin and view a member with a PPS number
  • Confirm PPS decrypts and displays correctly
  • Confirm the decryption is logged in audit_logs
  • Log key rotation completion in audit_logs with actor system

6. Rollback Procedure

For application rollback steps (reverting to a previous deployment), see Vercel Deployment Runbook. For database rollback (restoring to a pre-incident state), see Backup & Restore Runbook.

7. Customer Communication Template

Use this template for communicating with broker firms and trustees during incidents. Send via email to the broker’s registered contact address.
For confirmed data breaches involving a broker’s client data, the DPO must review and approve all external communications before they are sent. Do not send breach-related communications without DPO sign-off.