Hack23 Logo

πŸ”„ European Parliament MCP Server β€” Business Continuity Plan

πŸ›‘οΈ Classification-Driven Business Resilience Framework
🎯 Systematic Recovery Planning Through Enterprise-Grade Business Continuity

Owner Version Effective Date Review Cycle

**πŸ“‹ Document Owner:** CEO | **πŸ“„ Version:** 1.1 | **πŸ“… Last Updated:** 2026-03-12 (UTC) **πŸ”„ Review Cycle:** Semi-Annual | **⏰ Next Review:** 2026-09-12 | **βœ… Status:** Production Ready --- ## πŸ“‘ Table of Contents - [🎯 Purpose Statement](#-purpose-statement) - [πŸ“Š Business Impact Analysis](#-business-impact-analysis) - [🏷️ System Classification](#️-system-classification) - [πŸ”„ Recovery Objectives](#-recovery-objectives) - [πŸ“¦ Service Dependencies](#-service-dependencies) - [🚨 Disruption Scenarios](#-disruption-scenarios) - [πŸ”§ Recovery Procedures](#-recovery-procedures) - [πŸ“‹ Testing \& Maintenance](#-testing--maintenance) - [πŸ”— Policy Alignment](#-policy-alignment) - [πŸ“š Related Documents](#-related-documents) - [πŸ“ Revision History](#-revision-history) --- ## 🎯 Purpose Statement This Business Continuity Plan (BCP) establishes a **classification-driven business resilience framework** for the European Parliament MCP Server β€” a TypeScript/Node.js MCP server enabling AI assistants to access European Parliament open data. The plan demonstrates systematic recovery planning aligned with [Hack23 AB's Information Security Management System (ISMS)](https://github.com/Hack23/ISMS-PUBLIC) and ensures that service delivery can be maintained or rapidly restored following any disruption. ### πŸ” Transparency Commitment This BCP is published as part of Hack23 AB's commitment to **open source security transparency**. By documenting continuity strategies publicly, we enable the community to understand our resilience posture and contribute to its improvement. This aligns with the [Hack23 Open Source Policy](https://github.com/Hack23/ISMS-PUBLIC/blob/main/Open_Source_Policy.md). ### πŸ“ Scope Definition | Component | Description | Continuity Relevance | |-----------|-------------|----------------------| | **TypeScript/Node.js MCP Server** | Core server runtime (`src/`) | Primary service β€” must be recoverable from source control | | **npm Package Distribution** | Published package `european-parliament-mcp-server` | User-facing distribution channel β€” RTO < 1 hour | | **CI/CD Pipeline** | GitHub Actions workflows with SLSA Level 3 | Build integrity and automated release β€” RTO < 4 hours | | **European Parliament API** | External data source (`data.europarl.europa.eu`) | Upstream dependency β€” graceful degradation required | | **GitHub Pages Documentation** | Public-facing documentation site | Informational β€” RTO < 24 hours | | **61 MCP Tools** | `get_meps`, `get_mep_details`, `get_plenary_sessions`, `assess_mep_influence`, `analyze_country_delegation`, etc. | Core functionality β€” must degrade gracefully per tool | ### 🧠 BCP Structure Overview ```mermaid mindmap root((πŸ”„ Business
Continuity Plan)) πŸ“Š Business Impact Analysis πŸ’° Financial Impact βš™οΈ Operational Impact πŸ›οΈ Reputational Impact πŸ“œ Regulatory Impact 🎯 Recovery Objectives ⏱️ RTO Targets πŸ’Ύ RPO Targets πŸ”§ MTTR Targets πŸ—οΈ Infrastructure πŸ“¦ npm Registry πŸ™ GitHub Platform 🌐 EP Open Data API 🟒 Node.js Runtime 🚨 Disruption Scenarios πŸ”Œ EP API Outage πŸ“¦ npm Registry Issues πŸ™ GitHub Outage πŸ›‘οΈ Dependency Vulnerability πŸ”§ Recovery Procedures πŸ“‹ Step-by-Step Runbooks πŸ§ͺ Validation Checklists πŸ“ž Communication Plans ``` --- ## πŸ“Š Business Impact Analysis ### πŸ’° Financial Impact Assessment | Disruption Type | Duration | Financial Impact | Severity | |----------------|----------|-----------------|----------| | **npm package unavailable** | < 1 hour | 🟒 Minimal β€” users use cached versions | Low | | **npm package unavailable** | 1–24 hours | 🟑 Moderate β€” new installations blocked | Medium | | **CI/CD pipeline failure** | < 4 hours | 🟒 Minimal β€” delayed releases only | Low | | **CI/CD pipeline failure** | > 24 hours | 🟑 Moderate β€” security patches delayed | Medium | | **EP API outage** | Any duration | 🟒 Minimal β€” open source, no SLA revenue | Low | | **Supply chain compromise** | Any duration | πŸ”΄ Critical β€” trust and reputation damage | Critical | ### βš™οΈ Operational Impact Assessment | Service Component | Users Affected | Degradation Mode | Maximum Tolerable Downtime | |-------------------|---------------|-------------------|---------------------------| | **npm package** | All new installations | Cached versions available via npm mirror | 24 hours | | **MCP tool responses** | Active AI assistant sessions | Return cached data or informative error messages | 4 hours | | **GitHub source code** | Contributors and developers | Local clones available | 48 hours | | **CI/CD automation** | Release pipeline | Manual build and publish fallback | 24 hours | | **Documentation site** | New users and integrators | README available in npm package | 72 hours | ### πŸ›οΈ Reputational Impact Assessment | Scenario | Impact Level | Mitigation Strategy | |----------|-------------|---------------------| | **Data integrity failure** (serving incorrect EP data) | πŸ”΄ Critical | Zod schema validation, automated integration tests, data source verification | | **Supply chain attack** (compromised npm package) | πŸ”΄ Critical | SLSA Level 3 provenance, Sigstore signing, reproducible builds | | **Extended service unavailability** | 🟑 Moderate | Status communication via GitHub Issues, graceful degradation | | **Security vulnerability disclosure** | 🟑 Moderate | Responsible disclosure process, rapid patching (< 72h for critical) | ### πŸ“œ Regulatory Impact Assessment | Regulation | Requirement | BCP Relevance | |-----------|-------------|---------------| | **GDPR** | Data protection, minimal personal data processing | Ensure audit logs are recoverable; no personal data in caches | | **EU Cyber Resilience Act** | Software supply chain security | SLSA provenance, SBOM generation, vulnerability management | | **ISO 27001 A.17** | Information security continuity | This BCP document and regular testing | | **NIST CSF PR.IP-9** | Response and recovery plans | Recovery procedures and testing schedule | --- ## 🏷️ System Classification ### πŸ“ CIA Triad Classification Classification based on the [Hack23 ISMS Classification Framework](https://github.com/Hack23/ISMS-PUBLIC/blob/main/CLASSIFICATION.md):

Confidentiality: Public Integrity: Moderate Availability: Standard

| Dimension | Rating | Justification | |-----------|--------|---------------| | **πŸ”“ Confidentiality** | 🟒 Public | All data sourced from European Parliament open data portal; source code is open source (Apache-2.0 License) | | **πŸ”’ Integrity** | 🟑 Moderate | Data accuracy is important for trust β€” incorrect parliamentary data undermines credibility, but it is not safety-critical | | **⏱️ Availability** | πŸ”΅ Standard | No real-time SLA obligations; users can tolerate brief outages since AI assistants can retry or fall back | ### ⏱️ Recovery Time and Point Objectives | Service Component | RTO Target | RPO Target | Rationale | |-------------------|-----------|-----------|-----------| | **npm package availability** | < 1 hour | 0 (immutable releases) | Packages are immutable once published; recovery means republishing | | **CI/CD pipeline (GitHub Actions)** | < 4 hours | < 1 hour | Source code in Git; pipeline config is version-controlled | | **EP API access** | N/A (external) | N/A | Graceful degradation β€” return cached data or meaningful error | | **Source code repository** | < 2 hours | 0 (distributed Git) | Every contributor has a full clone; Git is inherently distributed | | **Documentation site** | < 24 hours | < 1 hour | Static site; can be rebuilt from source in minutes | --- ## πŸ”„ Recovery Objectives ### πŸ“Š Recovery Metrics Dashboard ```mermaid graph LR subgraph "⏱️ Recovery Time Objectives (RTO)" RTO1["πŸ“¦ npm Package
RTO: < 1 hour"] RTO2["πŸ”§ CI/CD Pipeline
RTO: < 4 hours"] RTO3["πŸ“„ Documentation
RTO: < 24 hours"] RTO4["πŸ’» Source Code
RTO: < 2 hours"] end subgraph "πŸ’Ύ Recovery Point Objectives (RPO)" RPO1["πŸ“¦ npm Package
RPO: 0 (immutable)"] RPO2["πŸ”§ CI/CD Pipeline
RPO: < 1 hour"] RPO3["πŸ“„ Documentation
RPO: < 1 hour"] RPO4["πŸ’» Source Code
RPO: 0 (Git)"] end subgraph "πŸ”§ Mean Time to Repair (MTTR)" MTTR1["πŸ“¦ npm Republish
MTTR: 30 min"] MTTR2["πŸ”§ Pipeline Fix
MTTR: 2 hours"] MTTR3["🌐 EP API Fallback
MTTR: 5 min"] MTTR4["πŸ›‘οΈ Vuln Patch
MTTR: < 72 hours"] end RTO1 --> RPO1 --> MTTR1 RTO2 --> RPO2 --> MTTR2 RTO3 --> RPO3 --> MTTR3 RTO4 --> RPO4 --> MTTR4 ``` ### 🎯 Detailed Recovery Targets | Metric | npm Registry | GitHub Actions | EP API Access | Source Code | |--------|-------------|---------------|---------------|-------------| | **RTO** | < 1 hour | < 4 hours | N/A (external) | < 2 hours | | **RPO** | 0 (immutable) | < 1 hour | N/A | 0 (Git distributed) | | **MTTR** | 30 minutes | 2 hours | 5 minutes (fallback) | 1 hour | | **MTBF** | > 8,760 hours | > 2,190 hours | Variable (external) | > 8,760 hours | | **Availability Target** | 99.9% | 99.5% | Best effort | 99.9% | ### πŸ”” Escalation Thresholds | Level | Trigger | Response Time | Action | |-------|---------|--------------|--------| | **🟒 L1 β€” Informational** | Service degradation detected | < 1 hour | Monitor and log; no immediate action needed | | **🟑 L2 β€” Warning** | Single service component unavailable | < 2 hours | Activate graceful degradation; notify maintainers | | **🟠 L3 β€” Major** | Multiple components affected or CI/CD broken | < 4 hours | Activate recovery procedures; status communication | | **πŸ”΄ L4 β€” Critical** | Supply chain compromise or data integrity issue | < 30 minutes | Immediate incident response; package yanking if needed | --- ## πŸ“¦ Service Dependencies ### πŸ—ΊοΈ Dependency Map | Dependency | Type | Criticality | Fallback Strategy | |-----------|------|-------------|-------------------| | **npm Registry** (`npmjs.com`) | Distribution | 🟠 High | Users cache packages locally; mirror registries available | | **European Parliament API** (`data.europarl.europa.eu`) | Data Source | 🟑 Medium | Graceful degradation with cached responses and error messages | | **GitHub** (Source Code) | Source Control | 🟠 High | Distributed Git clones; contributors have full repository copies | | **GitHub Actions** (CI/CD) | Automation | 🟑 Medium | Manual build and publish fallback via local npm scripts | | **GitHub Pages** (Documentation) | Documentation | 🟒 Low | README in npm package; docs in source repository | | **Node.js Runtime** (β‰₯ 25.x) | Runtime | 🟠 High | Pinned versions; current supported line (25.x Current, upgrading to 26.x LTS in β‰ˆ April 2026). Starting with Node.js 27, new annual release model with every release becoming LTS (36-month support). See [End-of-Life-Strategy.md](End-of-Life-Strategy.md) | | **TypeScript Compiler** | Build Tool | 🟑 Medium | Version-locked in `package-lock.json`; offline build possible | | **Zod** (Validation) | Library | 🟠 High | Locked version; no external runtime dependency | | **MCP SDK** (`@modelcontextprotocol/sdk`) | Protocol | 🟠 High | Locked version; protocol is standardized | ### πŸ”— External Service SLAs | Service | Published SLA | Historical Uptime | Our Dependency Level | |---------|--------------|-------------------|---------------------| | **npm Registry** | 99.9% | ~99.95% | Build-time and install-time only | | **GitHub** | 99.9% | ~99.95% | Source control, CI/CD, issue tracking | | **EP Open Data API** | No published SLA | ~99% | Runtime data source (degradation-tolerant) | | **GitHub Pages** | 99.9% | ~99.99% | Documentation hosting only | --- ## 🚨 Disruption Scenarios ### πŸ”Œ Scenario 1: European Parliament API Outage | Attribute | Detail | |-----------|--------| | **Probability** | 🟑 Medium (external service, no SLA guarantee) | | **Impact** | 🟑 Medium (MCP tools return errors instead of data) | | **Detection** | Automated health checks; HTTP error responses from EP API | | **Affected Tools** | All 61 MCP tools (`get_meps`, `get_plenary_sessions`, `assess_mep_influence`, `analyze_country_delegation`, etc.) | **πŸ›‘οΈ Graceful Degradation Strategy:** 1. **Cache Layer**: LRU cache with 15-minute TTL provides short-term resilience for repeated queries 2. **Informative Errors**: Tools return structured error messages indicating EP API unavailability 3. **Partial Availability**: Tools not requiring live EP data (e.g., cached legislative data) continue operating 4. **Status Communication**: GitHub Issue created automatically for extended outages (> 1 hour) ### πŸ“¦ Scenario 2: npm Registry Issues | Attribute | Detail | |-----------|--------| | **Probability** | 🟒 Low (npm has 99.9%+ uptime) | | **Impact** | 🟑 Medium (new installations blocked) | | **Detection** | Failed `npm install` commands; npm status page monitoring | | **Affected Users** | New installations and CI/CD pipelines pulling latest version | **πŸ›‘οΈ Mitigation Strategy:** 1. **Cached Packages**: Existing `node_modules` and `package-lock.json` continue working 2. **Mirror Registries**: Users can configure alternative npm mirrors (e.g., Verdaccio, GitHub Packages) 3. **Direct Install**: Package can be installed directly from GitHub releases as a tarball 4. **Lockfile Resilience**: `package-lock.json` ensures reproducible installs when registry recovers ### πŸ™ Scenario 3: GitHub Platform Outage | Attribute | Detail | |-----------|--------| | **Probability** | 🟒 Low (GitHub has 99.9%+ uptime) | | **Impact** | 🟠 High (source code, CI/CD, issues, and documentation affected) | | **Detection** | GitHub status page; failed CI/CD runs; inability to push code | | **Affected Services** | Source control, CI/CD pipeline, issue tracking, documentation | **πŸ›‘οΈ Mitigation Strategy:** 1. **Distributed Git**: Every contributor has a full clone of the repository with complete history 2. **Local Builds**: Project can be built locally with `npm run build` without GitHub 3. **Manual Publishing**: `npm publish` can be executed from any developer machine with credentials 4. **Alternative Hosting**: Repository can be mirrored to GitLab or Bitbucket as a contingency ### πŸ›‘οΈ Scenario 4: Critical Dependency Vulnerability | Attribute | Detail | |-----------|--------| | **Probability** | 🟑 Medium (supply chain attacks increasing industry-wide) | | **Impact** | πŸ”΄ Critical (compromised package integrity) | | **Detection** | Dependabot alerts; Snyk scans; CodeQL analysis; OSSF Scorecard | | **Affected Components** | Depends on the vulnerable dependency | **πŸ›‘οΈ Response Strategy:** 1. **Immediate Assessment**: Evaluate CVE severity and exploitability within 30 minutes 2. **Patch or Pin**: Update to patched version, or pin to last known-good version 3. **Emergency Release**: Trigger expedited CI/CD pipeline for patch release 4. **Advisory Publication**: Create GitHub Security Advisory for transparency 5. **SLSA Verification**: Ensure patched release maintains SLSA Level 3 provenance --- ## πŸ”§ Recovery Procedures ### πŸ“‹ Procedure 1: npm Package Recovery **Trigger:** npm package is unavailable, corrupted, or needs emergency replacement. | Step | Action | Owner | Time Estimate | |------|--------|-------|---------------| | 1 | βœ… Verify the issue β€” confirm package is truly unavailable via `npm view european-parliament-mcp-server` | Maintainer | 2 min | | 2 | πŸ” Check npm status page at `status.npmjs.org` for platform-wide issues | Maintainer | 2 min | | 3 | πŸ—οΈ If package is corrupted: checkout latest release tag from Git | Maintainer | 5 min | | 4 | πŸ”§ Build locally: `npm ci && npm run build && npm run test` | Maintainer | 10 min | | 5 | πŸ“¦ Publish: `npm publish` (requires npm credentials with 2FA) | Maintainer | 5 min | | 6 | βœ… Verify: `npm install european-parliament-mcp-server@latest` in a clean directory | Maintainer | 3 min | | 7 | πŸ“’ Communicate resolution via GitHub Issue or Discussion | Maintainer | 3 min | **⏱️ Total Estimated Time:** 30 minutes ### πŸ“‹ Procedure 2: CI/CD Pipeline Recovery **Trigger:** GitHub Actions workflows are failing or GitHub Actions is unavailable. | Step | Action | Owner | Time Estimate | |------|--------|-------|---------------| | 1 | βœ… Check GitHub Actions status at `githubstatus.com` | Maintainer | 2 min | | 2 | πŸ” Review recent workflow runs for error patterns | Maintainer | 10 min | | 3 | πŸ”§ If configuration issue: fix workflow YAML and push to trigger re-run | Maintainer | 15 min | | 4 | πŸ—οΈ If GitHub-wide issue: execute local build and test suite | Maintainer | 10 min | | 5 | πŸ“¦ If release is urgent: manual `npm publish` from local machine | Maintainer | 10 min | | 6 | βœ… Verify pipeline recovery by pushing a test commit | Maintainer | 5 min | | 7 | πŸ“ Document incident and update runbook if new failure mode | Maintainer | 15 min | **⏱️ Total Estimated Time:** ~1 hour ### πŸ“‹ Procedure 3: EP API Outage Response **Trigger:** European Parliament Open Data API is unreachable or returning errors. | Step | Action | Owner | Time Estimate | |------|--------|-------|---------------| | 1 | βœ… Verify API status: `curl -s -o /dev/null -w "%{http_code}" https://data.europarl.europa.eu/api/v2/meps` | Maintainer | 1 min | | 2 | πŸ” Check EP data portal for maintenance notices | Maintainer | 5 min | | 3 | πŸ›‘οΈ Confirm graceful degradation is active β€” MCP tools return informative errors | Maintainer | 5 min | | 4 | πŸ“’ If extended outage (> 1 hour): create GitHub Issue with status update | Maintainer | 5 min | | 5 | ⏳ Monitor EP API for recovery at 30-minute intervals | Maintainer | Ongoing | | 6 | βœ… Once recovered: verify all 61 MCP tools return valid data | Maintainer | 10 min | | 7 | πŸ“ Close GitHub Issue with resolution summary | Maintainer | 5 min | **⏱️ Total Estimated Time:** 30 minutes (active work) + monitoring ### πŸ“‹ Procedure 4: Dependency Vulnerability Response **Trigger:** Dependabot alert, Snyk notification, or CVE disclosure for a dependency. | Step | Action | Owner | Time Estimate | |------|--------|-------|---------------| | 1 | πŸ” Assess CVE severity (CVSS score) and exploitability | Maintainer | 15 min | | 2 | πŸ“Š Determine if vulnerability affects production code paths | Maintainer | 30 min | | 3 | πŸ”§ Update dependency: `npm update ` or pin safe version | Maintainer | 10 min | | 4 | πŸ§ͺ Run full test suite: `npm run test:coverage` | Maintainer | 10 min | | 5 | πŸ”’ Run security scans: CodeQL, license check, OSSF Scorecard | CI/CD | 15 min | | 6 | πŸ“¦ Publish patched release via CI/CD pipeline | CI/CD | 15 min | | 7 | πŸ“’ Create GitHub Security Advisory if user action needed | Maintainer | 15 min | **⏱️ Total Estimated Time:** ~2 hours **🚨 SLA by Severity:** | CVSS Score | Severity | Patch SLA | |-----------|----------|-----------| | 9.0–10.0 | πŸ”΄ Critical | < 24 hours | | 7.0–8.9 | 🟠 High | < 72 hours | | 4.0–6.9 | 🟑 Medium | < 30 days | | 0.1–3.9 | 🟒 Low | Next release cycle | --- ## πŸ“‹ Testing & Maintenance ### πŸ§ͺ BCP Testing Schedule | Test Type | Frequency | Description | Owner | |-----------|-----------|-------------|-------| | **πŸ“‹ Document Review** | Semi-Annual | Review BCP for accuracy and completeness | CEO | | **πŸ§ͺ Tabletop Exercise** | Annual | Walk through disruption scenarios with team | CEO + Maintainers | | **πŸ”§ Recovery Drill β€” npm** | Annual | Practice manual npm publish from local machine | Maintainer | | **πŸ”§ Recovery Drill β€” CI/CD** | Semi-Annual | Test local build fallback process | Maintainer | | **πŸ›‘οΈ Dependency Audit** | Monthly | Review Dependabot alerts and dependency health | Maintainer | | **🌐 EP API Health Check** | Automated (daily) | Verify EP API availability via integration tests | CI/CD | | **πŸ“¦ Package Integrity Check** | Per Release | Verify SLSA provenance and Sigstore signatures | CI/CD | ### πŸ“Š Testing Success Criteria | Test | Pass Criteria | |------|--------------| | **npm Recovery Drill** | Successfully publish a test package from local machine within 30 minutes | | **CI/CD Recovery Drill** | Successfully build, test, and lint the project locally without GitHub Actions | | **EP API Degradation Test** | All 61 MCP tools return structured error responses when EP API is mocked as unavailable | | **Dependency Vulnerability Drill** | Successfully patch a simulated vulnerable dependency and release within 2 hours | ### πŸ“ Maintenance Activities | Activity | Frequency | Description | |----------|-----------|-------------| | **πŸ”„ BCP Document Update** | Semi-Annual | Update recovery procedures, contacts, and dependencies | | **πŸ“¦ Dependency Map Review** | Quarterly | Update service dependency inventory and SLA data | | **πŸ“Š Recovery Metrics Review** | Quarterly | Review actual RTO/RPO/MTTR against targets | | **πŸ”— Policy Alignment Check** | Annual | Verify BCP alignment with ISMS policy updates | | **πŸ“’ Communication Plan Update** | Annual | Update escalation contacts and notification channels | --- ## πŸ”— Policy Alignment ### πŸ“œ ISMS Policy Mapping This BCP aligns with the following [Hack23 AB ISMS policies](https://github.com/Hack23/ISMS-PUBLIC): | ISMS Policy | BCP Section | Alignment | |-------------|-------------|-----------| | [**Backup & Recovery Policy**](https://github.com/Hack23/ISMS-PUBLIC/blob/main/Backup_Recovery_Policy.md) | Recovery Procedures, Recovery Objectives | βœ… RPO/RTO targets defined; Git distributed backup for source code | | [**Incident Response Plan**](https://github.com/Hack23/ISMS-PUBLIC/blob/main/Incident_Response_Plan.md) | Disruption Scenarios, Recovery Procedures | βœ… Escalation thresholds and response procedures documented | | [**Open Source Policy**](https://github.com/Hack23/ISMS-PUBLIC/blob/main/Open_Source_Policy.md) | Purpose Statement, Transparency | βœ… BCP published as part of open source transparency commitment | | [**Secure Development Policy**](https://github.com/Hack23/ISMS-PUBLIC/blob/main/Secure_Development_Policy.md) | Dependency Vulnerability Response | βœ… SLSA Level 3 provenance; supply chain security controls | | [**Classification Framework**](https://github.com/Hack23/ISMS-PUBLIC/blob/main/CLASSIFICATION.md) | System Classification | βœ… CIA triad classification drives recovery priority | | [**Risk Management Policy**](https://github.com/Hack23/ISMS-PUBLIC/blob/main/Risk_Management_Policy.md) | Business Impact Analysis | βœ… Risk-based impact assessment for all disruption scenarios | ### πŸ“ Standards Compliance | Standard | Requirement | Implementation | |----------|-------------|----------------| | **ISO 27001 A.17.1** | Information security continuity planning | This BCP document with defined recovery procedures | | **ISO 27001 A.17.2** | Redundancies | Distributed Git, npm mirror fallback, local build capability | | **ISO 22301** | Business continuity management | BIA, recovery objectives, testing schedule | | **NIST CSF PR.IP-9** | Response plans and recovery plans | Recovery procedures with step-by-step runbooks | | **NIST CSF RC.RP-1** | Recovery plan execution | Documented procedures with owner assignments | | **CIS Controls v8.1 #17** | Incident response management | Escalation thresholds and communication plans | --- ## πŸ“š Related Documents | Document | Description | Link | |----------|-------------|------| | **Security Architecture** | Defense-in-depth implementation and security controls | [SECURITY_ARCHITECTURE.md](./SECURITY_ARCHITECTURE.md) | | **Threat Model** | STRIDE threat analysis and risk assessment | [THREAT_MODEL.md](./THREAT_MODEL.md) | | **Architecture** | C4 model system architecture documentation | [ARCHITECTURE.md](./ARCHITECTURE.md) | | **Security Policy** | Vulnerability disclosure and security practices | [SECURITY.md](./SECURITY.md) | | **Performance Testing** | Benchmarks and performance analysis | [performance-testing.md](./performance-testing.md) | | **End-of-Life Strategy** | Technology lifecycle and Node.js transition | [End-of-Life-Strategy.md](./End-of-Life-Strategy.md) | | **Financial Security Plan** | Cost analysis and security investment | [FinancialSecurityPlan.md](./FinancialSecurityPlan.md) | | **Deployment Guide** | Production deployment and operations | [DEPLOYMENT_GUIDE.md](./DEPLOYMENT_GUIDE.md) | | **Troubleshooting** | Common issues and resolution steps | [TROUBLESHOOTING.md](./TROUBLESHOOTING.md) | | **Contributing** | Development workflow and contribution guidelines | [CONTRIBUTING.md](./CONTRIBUTING.md) | | **CI/CD Workflows** | GitHub Actions automation documentation | [WORKFLOWS.md](./.github/WORKFLOWS.md) | | **Data Model** | Data structures and entity relationships | [DATA_MODEL.md](./DATA_MODEL.md) | | **ISMS Public Policies** | Hack23 AB Information Security Management System | [ISMS-PUBLIC](https://github.com/Hack23/ISMS-PUBLIC) | --- ## πŸ“ Revision History | Version | Date | Author | Changes | |---------|------|--------|---------| | 1.0 | 2026-02-20 | CEO | Initial BCP document β€” business impact analysis, recovery objectives, disruption scenarios, recovery procedures, testing schedule, and ISMS policy alignment | | 1.1 | 2026-03-12 | CEO | Updated Node.js runtime dependency note to reference new annual release model (Node.js 27+); cross-referenced End-of-Life-Strategy.md | ---

This document is part of the Hack23 AB ISMS and is maintained under the European Parliament MCP Server project's documentation portfolio.