Incident Response & Disclosure Policy

1. Purpose

This Incident Response & Disclosure Policy establishes the framework for detecting, responding to, and recovering from security incidents affecting Rocket Pool. The policy ensures a fast, coordinated, and effective response to security threats through clearly defined roles, communication protocols, and technical procedures. Additionally, this policy commits the organisation to transparency through public post-mortems and establishes procedures for managing vulnerability disclosures and bug bounty submissions.

2. Scope

This policy applies to:

• All employees, contractors, consultants, and third-party service providers
• All information systems, networks, applications, and data assets owned or operated by Rocket Pool
• Security incidents of any severity level
• Bug bounty program participants and vulnerability researchers
• Incident response team members and stakeholders

Related Controls:

• Incident History Repository
• Bug Bounty Submission Handling
• Incident Response Training and Drills
• Response Time Service Level Agreements (SLAs)
• Bug Bounty Program Management
• Security Monitoring and Alerting Systems (trigger mechanisms)

3. Definitions

Security Incident: Any event that compromises the confidentiality, integrity, or availability of information assets, including but not limited to unauthorised access, data breaches, malware infections, denial of service attacks, or system compromises.

Incident Response Team (IRT): The designated group responsible for managing and coordinating the response to security incidents.

Severity Level: Classification of incident impact ranging from Low (minimal impact) to Critical (severe operational or data impact).

Post-Mortem: A documented analysis of an incident conducted after resolution, detailing root causes, timeline, impact, and corrective actions.

Bug Bounty: A reward program that compensates security researchers for responsibly disclosing vulnerabilities.

Responsible Disclosure: The practice of reporting security vulnerabilities privately to the organisation before public disclosure, allowing time for remediation.

4. Roles and Responsibilities

4.1 Incident Response Team (IRT)

Responsibilities:

• Coordinate all incident response activities
• Assess incident severity and determine appropriate response level
• Execute containment, eradication, and recovery procedures
• Document all incident response actions
• Conduct post-incident analysis and post-mortems
• Interface with external stakeholders (law enforcement, customers, partners)

IRT Lead: Founder / General Manager

• Overall accountability for incident response coordination
• Final authority on escalation decisions
• Spokesperson for external communications

Technical Response Lead: Lead Developer

• Directs technical investigation and remediation activities
• Coordinates with system administrators and security engineers
• Ensures proper evidence preservation

Communications Lead: Marketing and Community Manager

• Manages internal and external communications
• Prepares public statements and post-mortems
• Coordinates with legal and compliance teams

4.2 All Personnel

Responsibilities:

• Report suspected security incidents immediately through designated channels
• Preserve evidence and avoid actions that might destroy forensic data
• Cooperate fully with incident response investigations
• Maintain confidentiality regarding incidents until authorised disclosure

4.3 Executive Leadership

Responsibilities:

• Provide resources and support for incident response activities
• Make decisions on legal, regulatory, and public disclosure matters
• Approve major remediation expenditures
• Review post-mortem findings and approve corrective actions

4.4 Bug Bounty Program Manager

Responsibilities:

• Triage and validate bug bounty submissions
• Coordinate with IRT for vulnerability assessment
• Manage researcher communications and reward payments
• Maintain bug bounty platform and program documentation

5. Incident Classification and Severity Levels

5.1 Severity Levels

Critical (P1)

• Protocol user funds at risk
• Active exploitation of production systems
• Ransomware or destructive malware deployment
• Response Time SLA: Initial response within 15 minutes, executive notification immediate

High (P2)

• Confirmed unauthorised access to systems or data
• Complete/partial service degradation affecting significant user population
• Compromise of privileged accounts
• Successful phishing or social engineering attack
• Response Time SLA: Initial response within 1 hour, executive notification within 2 hours

Medium (P3)

• Attempted but unsuccessful intrusion with indicators of sophisticated attack
• Malware detected but contained
• Policy violations with potential security impact
• Vulnerability disclosed through bug bounty requiring urgent patching (critical/high)
• Response Time SLA: Initial response within 24 hours, management notification within 4 hours

Low (P4)

• Minor policy violations with minimal risk
• Unsuccessful attack attempts with no system impact
• Medium/low-severity vulnerabilities identified through bug bounty
• Security tool false positives requiring investigation
• Response Time SLA: Initial response within 48 hours, routine reporting

6. Incident Detection and Reporting

6.1 Detection Mechanisms

Security incidents may be detected through:

• Discord event stream
• User reports of suspicious activity
• Bug bounty submissions and external vulnerability disclosures
• Endpoint detection and response tools
• Third-party security notifications
• Audit findings

[Planned]

• Monitoring and alert system

6.2 Reporting Channels

All personnel must immediately report suspected incidents through:

• Primary: Team channel in Discord with @everyone
• Emergency (24/7): IRT Lead mobile: +61 466496045

Minimum Information to Report:

• Date, time, and location of incident
• Description of suspicious activity or observed behavior
• Affected systems, applications, or data
• Any actions already taken

7. Incident Response Process

7.1 Phase 1: Preparation

Ongoing Activities:

• Update contact lists and escalation procedures

[Planned]

• Maintain incident response procedures and playbooks
• Safe harbour agreements in place
• Conduct quarterly incident response training
• Perform annual wargame exercise simulating various incident scenarios

7.2 Phase 2: Detection and Analysis

Immediate Actions:

1. First responder to triage incident and assess initial severity
2. Escalate to IRT Lead for incident management
3. Gather IRT members based on incident type and severity
4. Establish communication channels (dedicated Discord thread war room)
5. Begin evidence collection and preservation

Analysis Activities:

• Determine incident scope and affected systems
• Identify attack vectors and indicators of compromise
• Review security logs and/or blockchain transactions/events
• Assess impact to client funds

Escalation Criteria:

• Notify leadership per severity level requirements

External Escalation by IRT Lead

• Engage external resources (SEAL, whitehats, law enforcement), if needed
• Alert downstream ecosystem partners

7.3 Phase 3: Containment

Short-term Containment:

• Perform security council pausing of protocol features
• Isolate affected systems
• Disable compromised user accounts or credentials
• Block malicious IP addresses, domains, countries
• Implement emergency firewall rules or access controls
• Take forensic images before remediation activities

Long-term Containment:

• Apply temporary patches or configuration changes
• Implement enhanced monitoring on affected and related systems
• Deploy additional security controls to prevent recurrence
• Maintain business operations with temporary workarounds if needed

7.4 Phase 4: Eradication

Removal Activities:

• Develop smart contract upgrade hotfix for resolution
• Rebuild compromised systems from clean installations
• Delete unauthorised accounts or access
• Close exploited vulnerabilities through patching or configuration changes
• Verify eradication through scanning and monitoring

7.5 Phase 5: Recovery

Restoration Activities:

• Deploy smart contract upgrade via DAO governance process
• Verify system integrity before returning to production
• Restore systems from clean backups if necessary
• Reset credentials for affected accounts
• Gradually restore service while monitoring for recurrence
• Implement enhanced security controls identified during incident

Verification:

• Confirm no signs of attacker persistence
• Monitor for 72 hours minimum before declaring full recovery
• Conduct security assessment of restored systems

7.6 Phase 6: Post-Incident Activities

Within 5 business days of incident resolution:

1. Conduct internal post-mortem review meeting with IRT
2. Document complete incident timeline and technical details
3. Identify root causes and contributing factors
4. Develop corrective action plan with owners and deadlines
5. Update incident response procedures based on lessons learned
6. Prepare public post-mortem (if disclosure warranted)

8. Communication and Disclosure

8.1 Internal Communications

During Active Incident:

• IRT maintains dedicated communication in team channel in Discord
• Status updates provided to leadership per severity schedule:
• Critical: Every 1 hours or upon significant developments
• High: Every 4 hours
• Medium: Daily
• Low: As needed
• Regular organisation-wide updates for incidents affecting operations
• Confidentiality maintained until authorised disclosure

8.2 External Communications

Community Notification:

• Notification required within 4 hours if protocol funds impacted
• Communications Lead prepares community-facing statements
• Leadership review required before distribution

Ecosystem Notification:

• IRT assesses ecosystem impact
• Notifications submitted to ecosystem partners

Law Enforcement:

• Criminal incidents reported to appropriate law enforcement agencies
• Legal counsel consulted before filing reports
• Evidence preserved according to chain-of-custody requirements

8.3 Public Post-Mortem Commitment

Transparency Principles: Rocket Pool commits to publishing public post-mortems for significant security incidents to promote industry learning and maintain stakeholder trust.

Post-Mortem Publication Criteria: Public post-mortems will be published for incidents that:

• Result in protocol funds impact or service disruption
• Demonstrate novel attack techniques of industry interest
• Lead to significant changes in security architecture or practices
• Affect a material portion of the community

Post-Mortem Content:

• Incident timeline with key events
• Root cause analysis
• Impact assessment
• Remediation actions taken
• Preventive measures implemented
• Lessons learned

Publication Process:

1. Draft post-mortem reviewed by IRT and leadership
2. Remove sensitive technical details that could aid attackers
3. Published on DAO forum within 30 days of incident closure
4. Copy maintained in Incident History Repository

Exemptions: Post-mortems may be withheld or delayed if:

• Publication would compromise ongoing investigation
• Law enforcement requests non-disclosure
• Legal proceedings are pending
• Disclosure would reveal unpatched vulnerabilities in third-party systems

9. Bug Bounty Program

9.1 Program Overview

Rocket Pool operates a bug bounty program to encourage responsible disclosure of security vulnerabilities by external security researchers.

Program Platform:

https://immunefi.com/bug-bounty/rocketpool

In-Scope Assets:

https://immunefi.com/bug-bounty/rocketpool/scope

Out-of-Scope:

https://immunefi.com/bug-bounty/rocketpool/scope

9.2 Submission Process

Researchers must:

1. Submit vulnerability reports through designated platform
2. Provide detailed reproduction steps and proof-of-concept
3. Avoid accessing, modifying, or exfiltrating data beyond demonstration needs
4. Not publicly disclose vulnerability before resolution and authorization
5. Act in good faith and comply with program rules

Required Report Information:

• Vulnerability type and severity assessment
• Affected asset and vulnerable component
• Step-by-step reproduction instructions
• Proof-of-concept code or screenshots
• Potential impact assessment
• Suggested remediation (optional)

9.3 Triage and Response

Initial Response Timeframes:

Severity Level	Acknowledged
Critical	48 hours
High	96 hours
Medium
Low

Triage Process:

1. Bug Bounty Program Team receives and acknowledges submission
2. Technical validation performed by engineering team
3. Duplicate check against known issues and previous submissions
4. Severity assessment using Immunefi Impacts

9.4 Rewards and Recognition

Reward Structure:

https://immunefi.com/bug-bounty/rocketpool/information

Reward Determination Factors:

• Vulnerability severity and exploitability
• Quality of report and reproduction steps
• Protocol and community impact
• Determination whether a code change is required

Payment Process:

• Leadership approval of payout
• Rewards paid within 30 days of vulnerability reporting
• Payment method, paid in RPL before public disclosure

9.5 Coordinated Disclosure

Standard Disclosure Timeline:

• 90 days from initial report to public disclosure
• Extensions granted for complex vulnerabilities requiring substantial remediation

Researcher Public Disclosure:

• Permitted only after vulnerability is fully remediated and organisation provides authorisation
• Technical writeups encouraged to benefit security community
• Organisation may request minor redactions to protect ongoing security measures

10. Incident History and Knowledge Management

10.1 Incident Repository

All security incidents must be documented in the centralised Incident History Repository, including:

• Complete incident timeline and technical details
• Root cause analysis and contributing factors
• Response actions taken and their effectiveness
• Financial and operational impact assessment
• Corrective actions and their implementation status
• Lessons learned and process improvements
• Related vulnerability disclosures or bug bounty submissions

10.2 Access and Retention

Access Controls:

• Full incident details: IRT members
• Summary information: Executive leadership

Retention Period:

• Active incidents: Retained indefinitely
• Historical incidents: Minimum 7 years for compliance
• Bug bounty submissions: Retained for duration of program plus 3 years

10.3 Trend Analysis [Planned]

Quarterly Review:

• Analysis of incident frequency, types, and severity trends
• Identification of recurring vulnerabilities or attack patterns
• Assessment of response time performance against SLAs (Control 4605)
• Evaluation of training effectiveness and gaps (Control 4603)
• Reporting to leadership

11. Training and Awareness [Planned]

11.1 General Employee Training

Annual Security Awareness Training:

• How to recognize and report security incidents
• Phishing identification and response
• Data handling and protection requirements
• Social engineering awareness
• Contact information for incident reporting

11.2 IRT Training

Quarterly Training Requirements:

• Review and update of incident response procedures
• Training on new security tools and technologies
• Threat intelligence briefings on emerging attack techniques
• Forensic analysis and evidence collection procedures
• Communication and stakeholder management

11.3 Incident Response Drills

Annual Full-Scale Exercise:

• Technical simulation involving actual systems (in isolated environment)
• Coordination with business continuity and disaster recovery teams
• Testing of backup restoration and system recovery procedures
• External party participation (legal, PR, forensic consultants)

**12. Service Level Agreements **

12.1 Response Time SLAs

Initial Response (from detection/report):

• Critical (P1): 15 minutes
• High (P2): 1 hour
• Medium (P3): 4 hours
• Low (P4): 24 hours

Executive Notification:

• Critical (P1): Immediate
• High (P2): Within 2 hours
• Medium (P3): Within 8 hours
• Low (P4): Routine reporting

Containment:

• Critical (P1): Within 2 hours of detection
• High (P2): Within 4 hours of detection
• Medium (P3): Within 24 hours of detection
• Low (P4): Within 5 business days

Resolution and Recovery:

• Critical (P1): Within 48 hours or continuous updates until resolution
• High (P2): Within 7 days or documented extended timeline
• Medium (P3): Within 30 days
• Low (P4): Within 60 days or next maintenance cycle

12.2 SLA Monitoring and Reporting

• Annual SLA performance reports generated for leadership review
• SLA violations analysed for root causes (resource constraints, process gaps, etc.)
• Continuous improvement initiatives based on SLA performance trends

13. Legal and Regulatory Considerations

13.1 Evidence Preservation

• Chain-of-custody procedures followed for all forensic evidence
• Evidence retention aligned with legal and regulatory requirements
• Coordination with legal counsel before evidence destruction

13.2 Regulatory Compliance

• Incident notification requirements assessed for:
• Data protection regulations (GDPR, CCPA, etc.)
• Industry-specific requirements (PCI DSS, HIPAA, etc.)
• Leadership and legal team involved in all incidents with regulatory implications

13.3 Legal Hold

• Legal hold procedures activated for incidents involving:
• Pending or anticipated litigation
• Criminal investigations
• Regulatory inquiries
• All relevant data and communications preserved

14. Third-Party Coordination

14.1 Service Providers

• Incident notification requirements defined in vendor contracts
• Coordination procedures established with critical service providers
• Joint incident response exercises conducted annually with key vendors

14.2 Information Sharing

• Participation in industry information sharing group
• Sharing of anonymized threat intelligence and IOCs
• Contribution to collective defense initiatives

15. Policy Violations and Enforcement

Violations of this policy may result in:

• Disciplinary action up to and including termination of employment
• Revocation of system access privileges
• Legal action for criminal violations
• Termination of contractor or vendor relationships

Specific violations include:

• Failure to report known or suspected security incidents
• Unauthorised disclosure of incident information
• Destruction or tampering with evidence
• Non-compliance with incident response procedures
• Abuse of bug bounty program

16. Continuous Improvement

16.1 Policy Review

• Annual review of incident response procedures by IRT Lead
• Updates made to reflect lessons learned from actual incidents
• Incorporation of emerging threats and industry best practices
• Alignment with changes to business operations or technology environment

16.2 Metrics and KPIs

Tracked Performance Indicators:

• Mean time to detect (MTTD)
• Mean time to respond (MTTR)
• Mean time to contain (MTTC)
• Mean time to recover (MTT Recover)
• SLA compliance rate
• Incident recurrence rate
• Training participation and effectiveness
• Bug bounty submission quality and resolution rates

17. Policy Approval and Effective Date

Policy Owner: [Founder]

Approved By:

• David Rugendyke, Founder, 8th June 2026
• Darren Langley, General Manager, 8th June 2026

Effective Date: 8th June 2026

Next Review Date: 8th June 2027

Version: 1.0

---

Appendices

Appendix A: Incident Response Contact List

Member	Title	Contact
Darren Langley	General Manager	+61 4 6649 6045
David Rugendyke	Founder	+61 4 0455 2726

Appendix B: Incident Response Playbooks

[Reference to technical playbooks for specific incident types: ransomware, phishing, DDoS, data breach, etc.]

Appendix C: Incident Report Template

Incident Report Template

Appendix D: Post-Mortem Template

Post-Mortem Template

Appendix E: Bug Bounty Program Rules

Rules of engagement

Appendix F: Evidence Collection Procedures

[Step-by-step forensic evidence collection guidelines] TODO

Appendix G: Ecosystem Partners Contact

• RockSolid

Security & Incident Response

• Blockaid
• Seal911

DEXs

• Balancer
• Uniswap

Lending

• Aave