🛡️ European Parliament MCP Server — CRA Conformity Assessment

Evidence-Driven Conformity Through Systematic Assessment
Demonstrating CRA Compliance Excellence for Open Source MCP Server

📋 Document Owner: CEO | 📄 Version: 1.2 | 📅 Last Updated: 2026-04-21 (UTC) 🔄 Review Cycle: Quarterly | ⏰ Next Review: 2026-07-21 🏷️ Classification: Public (Open Source MCP Server) ✅ ISMS Compliance: ISO 27001 (A.14.2), NIST CSF 2.0 (PR.DS, ID.SC), CIS Controls v8.1 (16.1)

🗺️ Security Documentation Map

Where this document fits in the security documentation portfolio:

Document	Focus	Link
SECURITY.md	Vulnerability reporting & security policy	View
SECURITY_ARCHITECTURE.md	Current security controls & design	View
THREAT_MODEL.md	STRIDE analysis & threat scenarios	View
🛡️ CRA-ASSESSMENT.md	← You are here — CRA conformity assessment	View
SECURITY_HEADERS.md	HTTP security headers implementation	View
BCPPlan.md	Business continuity & disaster recovery	View
FinancialSecurityPlan.md	Security investment strategy	View

🎯 Purpose Statement

Hack23 AB's CRA conformity assessment demonstrates how systematic regulatory compliance directly enables business growth rather than creating operational burden. Our comprehensive assessment framework serves as both operational tool and client demonstration of our cybersecurity consulting methodologies.

This assessment documents the European Parliament MCP Server's conformity with the EU Cyber Resilience Act (CRA), providing evidence-based compliance verification for open-source software distribution via npm. The assessment follows the CRA Conformity Assessment Process template.

— James Pether Sörling, CEO/Founder

1️⃣ Project Identification

Supports CRA Annex V § 1 — Product Description Requirements

Field	Value
📦 Product	European Parliament MCP Server
🏷️ Version Tag	v1.2.10 (reflects current project state)
🔗 Repository	https://github.com/Hack23/European-Parliament-MCP-Server
📧 Security Contact	security@hack23.org
🎯 Purpose	MCP server providing AI assistants with structured access to European Parliament open datasets (MEPs, plenary sessions, committees, legislative documents, parliamentary questions) via 62 tools, 9 resources, and 7 prompts
🏪 Market	Open Source

🏪 Market Category:

🛡️ Confidentiality Level:

Open source, processes only public European Parliament data

✅ Integrity Level:

Parliamentary data accuracy important for political analysis

⏱️ Availability Level:

Tolerates brief outages; local stdio transport

🕐 Recovery Time Objective:

npm reinstallation restores service

🔄 Recovery Point Objective:

No persistent state; source-of-truth is EP Open Data API

2️⃣ CRA Scope & Classification

Supports CRA Article 6 — Scope and Article 7 — Product Classification Assessment

🏢 CRA Applicability:

🌐 Distribution Method:

Published via npm registry; source on GitHub

📋 CRA Classification:

Self-assessment approach

📝 CRA Scope Justification: The European Parliament MCP Server is a non-commercial open-source tool distributed via npm that processes publicly available European Parliament data. It does not handle critical infrastructure, cryptographic functions, or safety-critical operations. As a standard-classification product, self-assessment is the appropriate conformity route.

🔍 Classification Impact:

Standard: Self-assessment approach (this document supports the documentation requirement)
No notified body assessment required
Evidence maintained through automated CI/CD and public badges

📊 CRA Compliance Lifecycle

graph LR
    subgraph "📋 Assessment"
        A1[Product Classification] --> A2[Risk Assessment]
        A2 --> A3[Requirements Mapping]
    end
    subgraph "🛡️ Implementation"
        A3 --> B1[Security Controls]
        B1 --> B2["Testing & Validation"]
        B2 --> B3[Evidence Collection]
    end
    subgraph "📦 Maintenance"
        B3 --> C1[Vulnerability Monitoring]
        C1 --> C2[Security Updates]
        C2 --> C3[Continuous Assessment]
        C3 --> A2
    end

3️⃣ Technical Documentation

Supports CRA Annex V § 2 — Technical Documentation Requirements

🏗️ CRA Technical Area	📝 Implementation Summary	📋 Evidence Location
🎨 Product Architecture (Annex V § 2.1)	C4 model with Context, Container, Component views; Mermaid diagrams	ARCHITECTURE.md, ARCHITECTURE_DIAGRAMS.md
📦 SBOM & Components (Annex I § 1.1)	CycloneDX SBOM generation per release; npm dependency tree	docs/SBOM.md, GitHub Release artifacts
🔐 Cybersecurity Controls (Annex I § 1.2)	4-layer security: Zod validation → rate limiting → audit logging → GDPR compliance	SECURITY_ARCHITECTURE.md
🛡️ Supply Chain Security (Annex I § 1.3)	SLSA Level 3 build provenance, npm provenance, Dependabot	GitHub Attestations
🔄 Update Mechanism (Annex I § 1.4)	npm update mechanism with semantic versioning	CHANGELOG.md
📊 Security Monitoring (Annex I § 1.5)	CodeQL analysis, OpenSSF Scorecard, Dependabot alerts	.github/workflows/
🏷️ Data Protection (Annex I § 2.1)	Public data only, no PII storage, GDPR compliance	SECURITY_ARCHITECTURE.md
📚 User Guidance (Annex I § 2.2)	Comprehensive documentation portal, API guide, deployment guide	README.md, API_USAGE_GUIDE.md, DEPLOYMENT_GUIDE.md
🔍 Vulnerability Disclosure (Annex I § 2.3)	Coordinated disclosure via SECURITY.md, GitHub Security Advisories	SECURITY.md

📋 ISMS Policy Integration:

🏗️ Architecture & Design: Implementation aligned with 🔐 Information Security Policy
📦 Asset Management: All 62 tools + 9 resources documented in ARCHITECTURE.md
🎯 Threat Model: Quantitative risk scoring (SLE/ARO/ALE) and CRA Annex I mapping in THREAT_MODEL.md §Quantitative Risk Scoring and §CRA Annex I Mapping
🔒 Encryption Standards: HTTPS-only EP API communication per 🔒 Cryptography Policy
🌐 Network Security: stdio transport (no network listener) per 🌐 Network Security Policy

4️⃣ Risk Assessment

Supports CRA Annex V § 3 — Risk Assessment Documentation

Reference: 📊 Risk Assessment Methodology and ⚠️ Risk Register

🚨 CRA Risk Category	🎯 Asset	📊 Likelihood	💥 Impact (C/I/A)	🛡️ CRA Control Implementation	⚖️ Residual	📋 Evidence
Supply Chain Attack (Art. 11)	npm dependencies	M	L/H/M	SBOM + SLSA provenance + Dependabot + npm audit	L	Attestations
Input Injection (Art. 11)	MCP tool parameters	M	L/M/L	Zod schema validation on all 62 tools	L	`src/tools/` (Zod schemas)
Data Integrity (Art. 11)	EP API responses	L	L/H/L	HTTPS transport + response validation + Zod parsing	L	SECURITY_ARCHITECTURE.md
Denial of Service (Art. 11)	Rate limiter	M	L/L/H	Token-bucket rate limiting (100 req/min) + LRU cache	L	`src/clients/ep/baseClient.ts`
Component Vulnerability (Art. 11)	npm packages	M	L/M/M	CodeQL + npm audit + Dependabot + weekly scans	L	.github/workflows/
Information Disclosure (Art. 11)	Error messages	L	L/L/L	Sanitized error responses, no stack traces in production	L	Error handling patterns

⚖️ CRA Risk Statement: LOW — Assessment supports CRA essential cybersecurity requirements evaluation. The product processes only publicly available European Parliament data via a local stdio transport, significantly limiting the attack surface.

✅ Risk Acceptance: James Pether Sörling (CEO) — 2026-03-19

📋 Risk Management Framework:

📊 Methodology: Risk assessment per 📊 Risk Assessment Methodology
⚠️ Risk Tracking: Risks documented in ⚠️ Risk Register
🔄 Business Impact: Continuity planning via BCPPlan.md
🆘 Recovery Planning: End-of-life strategy per End-of-Life-Strategy.md
📊 Quantitative Risk: Annual Loss Expectancy (ALE) calculations in THREAT_MODEL.md §Quantitative Risk Scoring
🇪🇺 CRA Annex I: Full requirements traceability in THREAT_MODEL.md §CRA Annex I Mapping

5️⃣ Essential Cybersecurity Requirements

Supports CRA Annex I — Essential Requirements Self-Assessment

📋 CRA Annex I Requirement	✅ Status	📋 Implementation Evidence
🛡️ § 1.1 — Secure by Design	[x]	TypeScript strict mode, Zod validation for all 62 tools, defense-in-depth architecture — SECURITY_ARCHITECTURE.md
🔒 § 1.2 — Secure by Default	[x]	Safe defaults, no credentials required, public data only, stdio transport (no network exposure) — `src/config.ts`
🏷️ § 2.1 — Personal Data Protection	[x]	Public data only, no PII storage, GDPR compliance, data minimization in API requests — SECURITY_ARCHITECTURE.md
🔍 § 2.2 — Vulnerability Disclosure	[x]	Public VDP via SECURITY.md + GitHub Security Advisories + ⚠️ Vulnerability Management
📦 § 2.3 — Software Bill of Materials	[x]	CycloneDX SBOM generation per release: docs/SBOM.md + GitHub Release artifacts
🔐 § 2.4 — Secure Updates	[x]	npm registry distribution with SLSA Level 3 attestation: GitHub Attestations
📊 § 2.5 — Security Monitoring	[x]	CodeQL (every PR), OpenSSF Scorecard, Dependabot, npm audit in CI/CD — .github/workflows/
📚 § 2.6 — Security Documentation	[x]	Comprehensive security documentation: SECURITY.md, SECURITY_ARCHITECTURE.md, THREAT_MODEL.md, SECURITY_HEADERS.md

Extended Annex I Requirements:

#	Requirement	Implementation	Evidence	Status
1	Security by design	TypeScript strict mode, Zod validation, defense-in-depth	SECURITY_ARCHITECTURE.md	✅
2	Secure default configuration	Safe defaults, no credentials required, public data only	`src/config.ts`	✅
3	Protection against unauthorized access	stdio transport (local only), input validation on all tools	SECURITY_ARCHITECTURE.md	✅
4	Confidentiality of data	Public data only, no PII storage, GDPR compliance	SECURITY_ARCHITECTURE.md	✅
5	Integrity of data	HTTPS for EP API calls, Zod response validation, typed schemas	`src/tools/` (all tool handlers)	✅
6	Data minimization	Request only needed fields, TTL-based LRU caching	`src/clients/ep/baseClient.ts`	✅
7	Availability	Rate limiting (100 req/min), graceful error handling, circuit patterns	`src/clients/ep/baseClient.ts`	✅
8	Minimize negative impact	Error isolation per tool, no cascade failures, sanitized errors	Error handling patterns	✅
9	Security updates	Dependabot automated updates, CI/CD pipeline, npm publishing	.github/workflows/	✅
10	Vulnerability handling	CodeQL, npm audit, responsible disclosure process	SECURITY.md	✅
11	Information and instructions	README, API docs, security documentation, deployment guide	README.md, API_USAGE_GUIDE.md	✅
12	Software Bill of Materials	CycloneDX SBOM generation per release	docs/SBOM.md	✅
13	Coordinated vulnerability disclosure	Security policy, GitHub advisories, 48h acknowledgment SLA	SECURITY.md	✅

🎯 CRA Self-Assessment Status: EVIDENCE_GATHERED — All requirements documented with implementation evidence

6️⃣ Conformity Assessment Evidence

Supports CRA Article 19 — Conformity Assessment Documentation

📊 Quality & Security Automation Status

Reference: 🛠️ Secure Development Policy

🧪 Control	🎯 Requirement	✅ Implementation	📋 Evidence
🧪 Unit Testing	≥80% line coverage, ≥70% branch	✅ 80%+ coverage, 1130+ tests	Coverage Reports
🌐 E2E Testing	Critical user journeys validated	✅ 4 E2E suites / 71 tests passing	E2E Results
🔍 SAST Scanning	Zero critical/high vulnerabilities	✅ CodeQL on every PR	CodeQL Workflow
📦 SCA Scanning	Zero critical unresolved dependencies	✅ Dependabot + npm audit	Dependabot Config
🔒 Secret Scanning	Zero exposed secrets/credentials	✅ GitHub secret scanning enabled	GitHub Security Settings
📦 SBOM Generation	CycloneDX per release	✅ Automated in release workflow	docs/SBOM.md
🛡️ Provenance	SLSA Level 3 attestation	✅ npm provenance + GitHub attestations	Attestations
📊 Quality Gates	Passing quality metrics	✅ CI/CD pipeline with lint, build, test gates	Workflows
🔐 License Compliance	OSI-approved license verification	✅ Apache-2.0, automated license checks	LICENSE.md, `npm run test:licenses`

🎖️ Security & Compliance Badges

🔍 Supply Chain Security:

🏆 Best Practices & Quality:

📊 Project Health:

📊 Evidence Summary

Evidence Type	Location	Verification	CRA Mapping
OpenSSF Scorecard	Scorecard	Automated	Annex I §10
SLSA Level 3	Attestations	Build provenance	Annex V §8
SBOM (CycloneDX)	docs/SBOM.md	Generated per build	Annex V §7
Test Coverage (80%+)	Coverage	Automated	Annex I §1
Dependency Scanning	Dependabot alerts	Automated	Annex I §10
Static Analysis	CodeQL results	Automated per PR	Annex I §1
Security Documentation	This repository	Manual review	Annex V §1-9
npm Audit	CI/CD pipeline	Automated	Annex I §9
License Compliance	`npm run test:licenses`	Automated	Annex V §1
Branch Protection	GitHub settings	Configured	Annex I §2

🛡️ Vulnerability Disclosure

📋 Disclosure Process

Step	Action	Timeline
1	Report via SECURITY.md or GitHub Security Advisories	Immediate
2	Acknowledgment of report	48 hours
3	Initial assessment and triage	72 hours
4	Fix development and testing	Based on severity
5	Security advisory publication	With fix release
6	npm package update	Same day as fix

⏱️ Remediation SLAs

Per ⚠️ Vulnerability Management:

Severity	CVSS Score	Remediation Target
🔴 Critical	9.0 – 10.0	24 hours
🟠 High	7.0 – 8.9	7 days
🟡 Medium	4.0 – 6.9	30 days
🟢 Low	0.1 – 3.9	90 days

🛡️ Proactive Security Measures

✅ Dependabot automated dependency updates
✅ CodeQL static analysis on every PR
✅ npm audit in CI/CD pipeline
✅ OpenSSF Scorecard monitoring
✅ SLSA Level 3 build provenance
✅ GitHub secret scanning
✅ Dependency review on PRs

🔍 Standard Security Reporting Process:

📧 Private Reporting: GitHub Security Advisories for confidential disclosure
⏱️ Response Timeline: 48h acknowledgment, 72h validation, severity-based resolution
🏆 Recognition Program: Public acknowledgment unless anonymity requested
🔄 Continuous Support: Latest version maintained with security updates
📋 Vulnerability Scope: Input injection, data integrity, dependency vulnerabilities, rate limit bypass

ISMS Integration: All vulnerability reports processed through ⚠️ Vulnerability Management procedures

🔗 Reference Implementations

The following Hack23 AB projects demonstrate completed CRA assessments using the CRA Conformity Assessment Process template:

🚀 Project	📦 Product Type	🏷️ CRA Classification	📋 Assessment Status	🔗 Reference Link
🕵️ CIA	Political transparency platform	Standard (Non-commercial OSS)	✅ Complete	📄 CRA Assessment
⚫ Black Trigram	Korean martial arts game	Standard (Non-commercial OSS)	✅ Complete	📄 CRA Assessment
🛡️ CIA Compliance Manager	Compliance automation tool	Standard (Non-commercial OSS)	✅ Complete	📄 CRA Assessment
🇪🇺 European Parliament MCP Server	Political intelligence MCP server	Standard (Non-commercial OSS)	✅ Complete	This document

🔗 Policy Alignment

ISMS Policy	Relevance	Link
🔐 Information Security	Overarching security governance	Information_Security_Policy.md
🔒 Secure Development	Development security practices	Secure_Development_Policy.md
📦 Open Source Policy	OSS governance and transparency	Open_Source_Policy.md
🔍 Vulnerability Management	Vulnerability handling SLAs	Vulnerability_Management.md
🏷️ Classification	Data classification framework	CLASSIFICATION.md
🔒 Cryptography	Encryption standards	Cryptography_Policy.md
🚨 Incident Response	Incident procedures	Incident_Response_Plan.md
🛡️ CRA Process	CRA conformity assessment template	CRA_Conformity_Assessment_Process.md

📚 Related Documents

Document	Description	Link
🎯 Threat Model	STRIDE analysis, attack trees, and risk assessment	THREAT_MODEL.md
🛡️ Security Architecture	Current security controls and 4-layer defense model	SECURITY_ARCHITECTURE.md
🏛️ Architecture	C4 model system design overview	ARCHITECTURE.md
🔄 Business Continuity Plan	Recovery procedures and degradation strategy	BCPPlan.md
💰 Financial Security Plan	Security investment strategy	FinancialSecurityPlan.md
📦 End-of-Life Strategy	Technology lifecycle and migration planning	End-of-Life-Strategy.md
🔒 Security Headers	HTTP security headers implementation	SECURITY_HEADERS.md
📊 Data Model	Entity relationships and data flows	DATA_MODEL.md
🔄 Workflows	CI/CD pipeline documentation	WORKFLOWS.md

This CRA assessment follows the Hack23 CRA Conformity Assessment Process template.
Maintained as part of the Hack23 AB ISMS framework.
Licensed under Apache-2.0

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

🛡️ European Parliament MCP Server — CRA Conformity Assessment

📑 Table of Contents

🗺️ Security Documentation Map

🎯 Purpose Statement