🛡️ EU Parliament Monitor — CRA Conformity Assessment

Evidence-Driven Conformity Through Systematic Assessment
Demonstrating CRA Compliance for European Parliament Intelligence Platform

📋 Document Owner: CEO | 📄 Version: 2.2 | 📅 Last Updated: 2026-05-03 (UTC)
🔄 Review Cycle: Quarterly | ⏰ Next Review: 2026-08-03
🏛️ Process Reference: CRA Conformity Assessment Process

---

📚 Architecture Documentation Map

---

🎯 Purpose Statement

Hack23 AB's CRA conformity assessment process demonstrates how systematic regulatory compliance directly enables transparency and trust in open-source European Parliament monitoring. This assessment covers the EU Parliament Monitor's compliance with the EU Cyber Resilience Act (CRA) requirements.

As a static site generating multi-language news articles from European Parliament open data, EU Parliament Monitor has a minimal attack surface while maintaining comprehensive security practices aligned with the CRA framework. This assessment follows the Hack23 AB CRA Conformity Assessment Process and the Open Source Policy requirements.

— James Pether Sörling, CEO/Founder

---

1️⃣ Project Identification

📋 Attribute	📊 Value
Product Name	euparliamentmonitor (npm package + static site)
Version	v0.8.54 (2026-05-03)
Repository	github.com/Hack23/euparliamentmonitor
Homepage	euparliamentmonitor.com
Security Contact	security@hack23.com
License	Apache-2.0
Purpose	Multi-language European Parliament transparency platform — 1894+ HTML articles / 14 languages / 14 article types / 15 unified gh-aw workflows (14 news-<type>.md + news-translate.md) / 3061+ tests / 52 test files
Technology Stack	Node.js 26, TypeScript 6.0.3, ESM, HTML5/CSS3, Vitest, Playwright
Deployment Model	npm (provenance + SLSA L3), AWS S3 + CloudFront primary, GitHub Pages fallback
Data Sources	European Parliament MCP Server 1.2.13 (public open data)

📎 Evidence Links

📂 Evidence Area	📄 Document	🔗 Link
System Architecture	ARCHITECTURE.md	View
Security Architecture	SECURITY_ARCHITECTURE.md	View
Future Security Architecture	FUTURE_SECURITY_ARCHITECTURE.md	View
Threat Model (STRIDE)	THREAT_MODEL.md	View
Security Policy	SECURITY.md	View
Classification & BCP	CLASSIFICATION.md	View
Data Model	DATA_MODEL.md	View
System Mindmap	MINDMAP.md	View
Workflow Documentation	WORKFLOWS.md	View
Business Continuity	BCPPlan.md	View
Financial Security Plan	FinancialSecurityPlan.md	View
End-of-Life Strategy	End-of-Life-Strategy.md	View
Unit Test Plan	UnitTestPlan.md	View
E2E Test Plan	E2ETestPlan.md	View
Performance Testing	performance-testing.md	View
SBOM & Provenance	GitHub Release Artifacts	View
OpenSSF Scorecard	Scorecard Results	View
CodeQL Results	GitHub Code Scanning	View
Dependency Alerts	Dependabot Alerts	View

---

2️⃣ CRA Scope & Classification

CRA Product Category

📋 Attribute	📊 Assessment
Product Name	EU Parliament Monitor
Product Type	Open-source static website generator
CRA Category	Standard — Default (non-critical digital product)
Digital Elements	HTML5, CSS3 (static generation via Node.js/TypeScript)
Network Connectivity	Build-time only: read-only access to European Parliament open data APIs
Runtime Network	None — output is pre-rendered static HTML served via CDN
Data Processing	Public EU Parliament data only (no PII, no user data)
User Interaction	Read-only static pages — no forms, no authentication, no cookies
Commercial Status	Non-commercial open-source (Apache-2.0 license)

Scope Justification

EU Parliament Monitor falls under CRA Article 6 — Standard (Default) category as a non-critical digital product. The product is an open-source static site generator that produces pre-rendered HTML pages from publicly available European Parliament data. It has no runtime network connectivity, processes no personal data, requires no user authentication, and poses minimal cybersecurity risk.

🏛️ Open Source Software CRA Exemption

Important CRA Note for Open Source Software: Under CRA Recital 18 and Article 3, open-source software developed and distributed non-commercially (subject to the "in-the-course-of-a-commercial-activity" test) may qualify for full or partial CRA exemption. EU Parliament Monitor is:

• ✅ Free and open-source (Apache-2.0 license)
• ✅ Non-commercial civic technology — zero revenue generated
• ✅ No monetary consideration for distribution
• ✅ No commercial exploitation by manufacturer (Hack23 AB)

Assessment: EU Parliament Monitor likely qualifies as non-commercial OSS under CRA Article 3, meaning most manufacturer obligations do NOT apply. However, the platform voluntarily implements CRA best practices as part of Hack23 AB's security commitment and ISMS framework — demonstrating proactive security transparency to citizens, regulators, and the open-source community.

As a non-commercial open-source project (CRA Recital 18), it benefits from reduced obligations while voluntarily maintaining comprehensive security practices aligned with CRA Annex I essential requirements.

---

🏛️ Article 24 OSS Steward — 2026-04-20 Position

The CRA introduces a dedicated Article 24 "Open-Source Software Steward" regime offering reduced obligations (versus the full manufacturer duties in Articles 13–15) for legal entities that systematically and sustainedly support non-commercial open-source projects. EU Parliament Monitor adopts this regime as its primary CRA position.

Dual-surface interpretation:

• (a) npm package euparliamentmonitor@0.8.40 — as a "product with digital elements" that can be consumed by downstream commercial users, it is likely classified as Important Class I library (Annex III), subject to standard conformity assessment (Module A).
• (b) Static website (euparliamentmonitor.com) — as a free public civic-transparency service that is not marketed as a product and has no runtime compute surface, it is likely non-critical (Standard / Default) and outside CRA's "product with digital elements" scope.

Adopted stance: Article 24 OSS Steward regime + Important Class I for the npm package. The static website benefits from the same controls as defense-in-depth but is treated as out-of-scope.

Responsible legal entity: Hack23 AB (Sweden) — as the upstream legal entity registered in the EU, Hack23 AB acts as the OSS Steward for all CRA cooperation with ENISA and national market-surveillance authorities.

Article 24 OSS Steward Duties — Evidence Map

Article 24 Duty	Evidence	Status
Cybersecurity policy	SECURITY.md + Hack23 ISMS-PUBLIC Information Security Policy	✅
Vulnerability handling process	SECURITY.md + .github/workflows/codeql.yml + Dependabot + .github/workflows/scorecards.yml + gh-advisory-database gate	✅
Coordinated disclosure policy	SECURITY.md disclosure section (GitHub private vulnerability reporting enabled)	✅
SBOM	CycloneDX from package-lock.json + tool-schemas.json; npm provenance statements; SLSA L3 attestations	⚠️ SBOM auto-publish gap (see §Gap Table)
Cooperation with market surveillance	Hack23 AB (Sweden) as responsible legal entity; contact via SECURITY.md	✅
Documentation of security risks	THREAT_MODEL.md + SECURITY_ARCHITECTURE.md + this document	✅

---

2️⃣ᵃ EU CRA Enforcement Timeline

Understanding CRA's phased enforcement timeline is essential for compliance planning. EU Parliament Monitor monitors these milestones to ensure timely readiness.

🗓️ Milestone	📅 Date	📋 Requirements	🚦 Status
CRA Published in Official Journal	2024-11-20	Regulation (EU) 2024/2847 published	✅ Completed
CRA Entry into Force	2024-12-11	20 days after publication in Official Journal	✅ Completed
Market Surveillance Provisions	2026-06-11	Chapter VI market surveillance rules applicable (18 months)	🔄 Upcoming
Vulnerability & Incident Reporting Obligations	2026-09-11	Articles 14 & 15 — Vulnerability and incident reporting to ENISA/national CSIRTs	🔄 Upcoming
Full CRA Compliance Required	2027-12-11	All CRA requirements for manufacturers, importers, and distributors	🔄 Upcoming
CE Marking Mandatory	2027-12-11	Products covered by CRA must bear CE marking	N/A (non-commercial OSS)

📍 Current Position (Feb 2026): CRA is in force. Vulnerability reporting requirements under Articles 14 & 15 apply from September 2026 — approximately 7 months away. EU Parliament Monitor's existing SECURITY.md coordinated disclosure process and GitHub Security Advisories integration already satisfies these upcoming requirements. No additional action required before the September 2026 deadline.

gantt
    title EU CRA Enforcement Timeline
    dateFormat  YYYY-MM-DD
    axisFormat  %b %Y

    section Completed
    CRA Published (2024-11-20)          :done, pub,  2024-11-20, 1d
    CRA Entry into Force (2024-12-11)   :done, eif,  2024-12-11, 1d

    section Upcoming
    Market Surveillance (2026-06-11)    :active, ms,  2026-06-11, 30d
    Vulnerability Reporting (2026-09-11):active, vr,  2026-09-11, 30d
    Full CRA Compliance (2027-12-11)    :crit, fc,  2027-12-11, 30d

---

3️⃣ Technical Documentation (CRA Annex V)

📋 CRA Technical Area	📊 Implementation	🔗 Evidence
Product Architecture	C4 architecture model (Context, Container, Component levels); static site generator with GitHub Pages deployment; Node.js 26/TypeScript build pipeline	ARCHITECTURE.md, SECURITY_ARCHITECTURE.md, MINDMAP.md
SBOM & Components	CycloneDX SBOM generated per release; npm package-lock.json provides full dependency tree; single runtime dependency (european-parliament-mcp-server)	GitHub Release Attestations, package.json
Cybersecurity Controls	Static site security model (no server-side code execution); CSP headers via GitHub Pages; Content Security Policy; HTTPS-only delivery; no cookies or tracking	SECURITY_ARCHITECTURE.md, THREAT_MODEL.md
Supply Chain Security	SLSA Level 3 provenance via release.yml; Dependabot daily dependency scanning; OpenSSF Scorecard weekly assessment; dependency-review on PRs; npm audit in CI	release.yml, scorecards.yml, OpenSSF Scorecard
Update Mechanism	Automated CI/CD via GitHub Actions; daily news generation workflows; automated dependency updates via Dependabot PRs; release workflow with SBOM and provenance attestation	WORKFLOWS.md, release.yml
Security Monitoring	CodeQL SAST on every push/PR; Dependabot alerts with severity-based SLAs; SonarCloud code quality analysis; ESLint with security plugin; HTMLHint for output validation	codeql.yml, dependency-review.yml
Data Protection	Public data only — all source data from official European Parliament open data portal; no PII collected, processed, or stored; no user tracking or analytics; GDPR compliant by design	CLASSIFICATION.md, SECURITY.md
User Guidance	README.md with quick-start instructions; comprehensive architecture documentation suite (20+ documents); Security Policy with vulnerability reporting process; API documentation	README.md, SECURITY.md, ARCHITECTURE.md
Vulnerability Disclosure	GitHub Security Advisories enabled; coordinated disclosure process in SECURITY.md; severity-based SLAs (Critical: 7 days, High: 30 days, Medium: 90 days); security@hack23.com contact	SECURITY.md, GitHub Security Advisories
Technology Lifecycle	End-of-Life Strategy documenting Node.js 26 LTS support timeline (Node.js 26 nightly CI testing active); dependency lifecycle tracking; proactive technology migration planning	End-of-Life-Strategy.md
Testing & Validation	Vitest unit tests (82%+ coverage); Playwright E2E tests across 14 languages; axe-core accessibility testing (WCAG 2.1 AA); Lighthouse performance benchmarking; ESLint + HTMLHint linting	UnitTestPlan.md, E2ETestPlan.md, performance-testing.md
Business Continuity	GitHub Pages CDN with global distribution; git-based disaster recovery; repository mirroring capability; classification-driven recovery priorities	BCPPlan.md, FinancialSecurityPlan.md

📦 SBOM Implementation Details

EU Parliament Monitor generates a comprehensive Software Bill of Materials (SBOM) for every release per CRA Annex I, Part I, §2(3) requirements — ensuring complete software supply chain transparency.

📋 SBOM Attribute	🔧 Implementation	📜 CRA Requirement	✅ Status
SBOM Format	SPDX JSON (via npm list --json)	Machine-readable format	✅
Component Inventory	All npm dependencies — direct and transitive	Complete software component listing	✅
Version Information	Exact semantic versions from package-lock.json	Precise version identification	✅
License Information	REUSE.toml + SPDX headers per file	License compliance metadata	✅
Vulnerability Status	npm audit + Dependabot alerts	Known vulnerability tracking	✅
Generation Frequency	On every release via GitHub Actions release workflow	Current at time of distribution	✅
Public Availability	Released as GitHub Release artifact	Freely accessible to downstream users	✅

Note: The package-lock.json provides a machine-readable, version-pinned dependency graph that serves as a complementary SBOM artifact for all build-time consumers. Both the CycloneDX SBOM (generated per release) and package-lock.json are publicly accessible, fulfilling CRA Annex I Part II §7.

---

4️⃣ Risk Assessment

🎯 CRA Risk Category	💎 Asset	📊 Likelihood	💥 Impact	🛡️ CRA Control Implementation	📉 Residual	🔗 Evidence
Supply Chain Compromise	Build pipeline, npm dependencies	🟡 Medium	🟡 Medium	SLSA Level 3 provenance; Dependabot daily scanning; dependency-review workflow; npm audit in CI; lock file integrity verification	🟢 Low	release.yml, dependency-review.yml
Known Vulnerability Exploitation	Node.js runtime, npm packages	🟡 Medium	🟡 Medium	CodeQL SAST on every push; Dependabot with severity-based SLAs; OpenSSF Scorecard assessment; npm audit enforcement; ESLint security plugin	🟢 Low	codeql.yml, SECURITY.md
Content Integrity Compromise	Generated HTML/CSS news articles	🟢 Low	🟡 Medium	Git-based version control with signed commits; HTMLHint output validation; Playwright E2E verification; immutable deployment artifacts	🟢 Low	ARCHITECTURE.md, E2ETestPlan.md
CI/CD Pipeline Tampering	GitHub Actions workflows	🟢 Low	🟡 Medium	Branch protection rules; required PR reviews; pinned action versions; workflow permissions with least privilege; CODEOWNERS enforcement	🟢 Low	WORKFLOWS.md, scorecards.yml
Data Source Manipulation	European Parliament MCP Server data	🟢 Low	🟢 Low	Read-only access to official EU Parliament open data; data consumed at build-time only; output reviewed before deployment; public data with inherent transparency	🟢 Low	DATA_MODEL.md, SECURITY_ARCHITECTURE.md
Availability Disruption	Static site hosted on GitHub Pages	🟢 Low	🟢 Low	GitHub Pages CDN with 99.9%+ uptime SLA; static files require no server-side processing; git-based disaster recovery; no database dependencies	🟢 Low	BCPPlan.md, CLASSIFICATION.md
Cross-Site Scripting (XSS)	Generated HTML pages in 14 languages	🟢 Low	🟡 Medium	No user input accepted at runtime; content generated from sanitized templates; HTMLHint validation; CSP headers; static pre-rendered output only	🟢 Low	THREAT_MODEL.md, SECURITY_ARCHITECTURE.md
License & IP Compliance	Open-source dependencies, Apache-2.0 license	🟢 Low	🟢 Low	REUSE compliance checking via reuse.yml workflow; SBOM generation with license metadata; Apache-2.0 compatible dependency selection	🟢 Low	reuse.yml, REUSE.toml

---

5️⃣ Essential Requirements Assessment (CRA Annex I)

Part I: Security Properties of Products with Digital Elements

#	📋 CRA Requirement	✅ Status	🔧 Implementation	🔗 Evidence
1	Delivered without known exploitable vulnerabilities	✅ Met	Automated dependency scanning via Dependabot (daily); CodeQL SAST on every push/PR; npm audit enforcement in CI pipeline; zero known critical/high vulnerabilities maintained	codeql.yml, SECURITY.md, GitHub Code Scanning
2	Secure by default configuration	✅ Met	Static site requires zero configuration; no server processes, no databases, no authentication configuration needed; CSP headers enforced via GitHub Pages; HTTPS-only delivery; no optional insecure modes	SECURITY_ARCHITECTURE.md, ARCHITECTURE.md
3	Protection against unauthorized access	✅ N/A	No authentication or authorization needed — platform serves public information only; no admin interface; no writable API endpoints; GitHub repository access controlled via branch protection and CODEOWNERS	SECURITY.md, THREAT_MODEL.md
4	Protect confidentiality of stored/transmitted/processed data	✅ Met	No personal or confidential data processed; all European Parliament data is public and freely available; HTTPS-only delivery ensures transport confidentiality; no cookies, local storage, or session data	CLASSIFICATION.md, SECURITY_ARCHITECTURE.md
5	Protect integrity of stored/transmitted/processed data	✅ Met	Git-based version control with immutable commit history; SLSA Level 3 provenance for release artifacts; HTMLHint validation on all generated content; Playwright E2E tests verify output integrity across 14 languages	release.yml, E2ETestPlan.md
6	Process only data adequate, relevant, and necessary	✅ Met	Data minimization by design — only public European Parliament data processed; no telemetry, analytics, or user tracking; no personal data collection; build-time data processing with no runtime data flows	DATA_MODEL.md, CLASSIFICATION.md
7	Protect availability of essential functions	✅ Met	GitHub Pages CDN provides global distribution with 99.9%+ uptime; static HTML files require no server-side compute; no single points of failure in serving; BCP plan covers disaster recovery	BCPPlan.md, ARCHITECTURE.md
8	Minimize negative impact on availability of services provided by other devices/networks	✅ Met	Static site generates zero outbound network traffic at runtime; no WebSockets, no API calls, no tracking pixels; no JavaScript required for content rendering; minimal bandwidth consumption	SECURITY_ARCHITECTURE.md, performance-testing.md
9	Designed and produced to limit attack surfaces	✅ Met	Minimal attack surface: pre-rendered static HTML/CSS with no JavaScript execution required; no server-side code; no user input processing at runtime; no database connections; CDN-delivered immutable files	THREAT_MODEL.md, ARCHITECTURE.md
10	Designed to reduce impact of security incidents	✅ Met	Static site architecture inherently limits blast radius; no persistent server state to compromise; no user data at risk; content easily regenerated from git; rollback via git revert	BCPPlan.md, SECURITY_ARCHITECTURE.md
11	Provide security-relevant information through recording/monitoring	✅ Met	GitHub Actions provides complete CI/CD audit trail; GitHub Pages access logs available; CodeQL findings tracked via GitHub Code Scanning; Dependabot alerts with historical records	WORKFLOWS.md, codeql.yml
12	Provide ability to remove data by users	✅ N/A	No user data collected, stored, or processed; no user accounts; no forms; no cookies; no local storage usage; GDPR data subject rights not applicable	CLASSIFICATION.md
13	Security updates shall be made available	✅ Met	Automated CI/CD pipeline for rapid deployment; Dependabot auto-generates PRs for vulnerable dependencies; release workflow generates SBOM and provenance attestation; severity-based remediation SLAs documented	SECURITY.md, release.yml

🔄 Annex I Part I — 2026-04-20 Evidence Map Refresh

Supplementary evidence map aligning each Annex I Part I essential cybersecurity requirement to current implementation artefacts. Complements the table above.

• Secure-by-default ← static site, no auth, HSTS + CSP <meta http-equiv> emitted by src/aggregator/article-html.ts (shared chrome, applied uniformly to every rendered language variant); deterministic markdown render via markdown-it (raw HTML disabled by default) + src/utils/html-sanitize.ts; branded type safety system (SafeHtmlString, SafeXmlString, AbsoluteUrl, RelativeFilePath in src/generators/shared/) eliminates unescaped-string interpolation at compile time; shell-safety enforcement (test/unit/shell-safety.test.js) ensures no agentic workflow helper uses dangerous expansion patterns
• No known exploitable vulns at release ← CodeQL + Dependabot + gh-advisory-database gate (blocks PRs with new advisories); SBOM includes markdown-it and its audit-enabled plugin set (markdown-it-anchor, markdown-it-footnote, markdown-it-attrs, markdown-it-deflist)
• Authenticated / integrity-verified updates ← npm provenance statements + SLSA L3 build attestations + signed commits via CODEOWNERS
• Confidentiality ← TLS 1.2+/1.3 on all outbound HTTPS (WB, IMF, GitHub, npm, AWS); no user PII collected, stored, or transmitted
• Integrity ← src/utils/html-sanitize.ts on every MCP string; compile-time branded types prevent raw-string interpolation into HTML/XML templates (see SECURITY_ARCHITECTURE.md §Branded Type Safety System); canonical tool-list drift tests (IMF + WB + EP asserted in test/integration/mcp/*); Stage-C completeness review over the committed artifact set (agent-side; the runtime validator in src/utils/validate-analysis-completeness.ts was purged with the aggregator migration — see SECURITY_ARCHITECTURE.md § Aggregator Migration for the defence-in-depth rationale)
• Data minimization ← no accounts, no tracking, no analytics; theme preference only in localStorage (no cross-site tracking)
• Availability ← BCP per-asset RTO/RPO targets; gh-aw engine-switch (Copilot ↔ Claude ↔ Codex); editorial IMF-primary rule enforced at Stage-C review (the Wave-2 articlePolicyHasEconomicContext runtime OR-gate was purged with the aggregator migration — policy now lives in analysis/methodologies/imf-indicator-mapping.md)
• Attack surface minimization ← static content only; no AI-authored HTML step (aggregator eliminates the template-prose-leak class of defects); AWF Squid firewall egress allowlist; Docker sandbox for agentic workflows; shell-safety filter blocks 9 classes of dangerous bash expansion in agent-emitted code (nested expansion, indirect expansion, ${var@P} transformation, nested command substitution, default-with-$(), redirection inside $(), adjacent ${RANDOM}, eval) — enforcement via test/unit/shell-safety.test.js drift guard + prompt-level rules (.github/prompts/00-scope-and-ground-rules.md §47)
• Impact mitigation ← OIDC federation (no long-lived keys on GitHub→AWS or GitHub→npm); max-patch-size caps; safe-outputs scoped to PR only
• Logging ← JSONL agent stdio audit trail; AWS CloudTrail; GitHub audit log; CodeQL findings persisted as security alerts
• Remediation ← Dependabot auto-PRs for vulnerable deps; pinned GH_AW_VERSION=v0.71.3 with documented bump procedure; rollback via git revert (BCP Scenario 11)

Part II: Vulnerability Handling Requirements

#	📋 CRA Requirement	✅ Status	🔧 Implementation	🔗 Evidence
1	Identify and document vulnerabilities and components	✅ Met	SECURITY.md documents vulnerability reporting process; THREAT_MODEL.md provides STRIDE analysis; CycloneDX SBOM generated per release cataloging all components; package-lock.json provides complete dependency tree	SECURITY.md, THREAT_MODEL.md, GitHub Releases
2	Address and remediate vulnerabilities without delay	✅ Met	Severity-based SLAs: Critical (7 days), High (30 days), Medium (90 days); Dependabot auto-generates update PRs; CodeQL runs on every commit; automated npm audit in CI pipeline	SECURITY.md, Dependabot Alerts
3	Apply effective and regular testing and review	✅ Met	Vitest unit tests (82%+ coverage); Playwright E2E tests across all 14 language pages; axe-core accessibility testing (WCAG 2.1 AA); Lighthouse performance benchmarks; ESLint + HTMLHint linting; CodeQL SAST; jscpd code duplication detection	UnitTestPlan.md, E2ETestPlan.md, performance-testing.md
4	Publicly disclose information about fixed vulnerabilities	✅ Met	GitHub Security Advisories enabled for coordinated disclosure; fixed vulnerabilities published via GitHub releases; security@hack23.com for private reporting; public SECURITY.md documents full process	SECURITY.md, GitHub Security Advisories
5	Provide mechanism for security updates	✅ Met	Automated CI/CD pipeline via GitHub Actions; Dependabot generates PRs for dependency updates; SLSA Level 3 provenance ensures update integrity; static site redeploys automatically on merge to main branch	WORKFLOWS.md, release.yml
6	Share vulnerability information in a timely manner	✅ Met	Public SECURITY.md with clear reporting instructions; GitHub Security Advisories with CVE assignment capability; coordinated disclosure timeline (acknowledge 48h, validate 7d, remediate per SLA); public security metrics	SECURITY.md
7	Provide a machine-readable SBOM	✅ Met	CycloneDX SBOM generated in release workflow; npm package-lock.json provides exact dependency versions; SLSA provenance attestation links SBOM to build; REUSE compliance for license metadata	release.yml, REUSE.toml
8	Define security support period	✅ Met	End-of-Life Strategy documents technology lifecycle and support timeline; Node.js 26 LTS active (Node.js 26 nightly CI testing); dependency EOL monitoring; proactive migration planning documented	End-of-Life-Strategy.md, SECURITY.md

🔄 Annex I Part II — 2026-04-20 Vulnerability Handling Evidence Map

Supplementary evidence map mapping each Annex I Part II vulnerability-handling duty to current implementation artefacts.

• Identify & document vulnerabilities ← GitHub Security Advisories + private vulnerability reporting + CodeQL + Dependabot alerts
• Address without delay (free security updates) ← npm patch releases distributed via automated release workflow; severity SLAs (Critical 7d / High 30d / Medium 90d)
• Public disclosure ← coordinated disclosure via SECURITY.md; CVE assignment through GitHub Security Advisories
• Secure distribution of updates ← npm provenance statements + SLSA L3 build attestations; signed release commits
• 24h CVE reporting to ENISA ← process documented in SECURITY.md; responsible party Hack23 AB CEO (not yet exercised — see §Gap Table for ENISA runbook)

---

5️⃣ᵃ Substantial Compliance Overlap

The platform's existing compliance programme — OpenSSF Scorecard, OpenSSF Best Practices #12068, SLSA Level 3 build attestations, SPDX license metadata (REUSE.toml), CodeQL SAST, Dependabot SCA, gh-advisory-database publish-gate, npm provenance, and the ISMS-PUBLIC policy framework — together deliver substantial CRA compliance today. The residual delta between current coverage and the December 2027 full-compliance deadline is tracked in the gap table below and is dominated by (a) CycloneDX SBOM auto-publish per release, (b) ENISA 24-hour CVE reporting runbook, and (c) EP MCP canonical tool-list drift test. None of these are technically blocking; they are procedural hardening items scheduled across 2026–2027.

---

5️⃣ᵇ Compliance Gap Table — December 2027 Readiness

Tracking delta to CRA full-compliance deadline (2027-12-11). All Article 24 OSS Steward duties and Annex I Parts I + II essential requirements are mapped. Items marked ✅ Complete require no further action; ⚠️/Gap items have owners and target dates.

#	CRA Requirement	Current Status	Evidence	Gap	Target Date
1	Article 24 OSS Steward self-declaration	Draft	This doc §2	Need Hack23 AB signed legal declaration	2026-Q3
2	CycloneDX SBOM auto-publish per release	Gap	Manual generation only	Add CycloneDX generation step to release.yml with release-asset upload	2026-Q4
3	CVE 24h ENISA reporting runbook	Gap	None	Draft runbook + test ENISA Single Point of Contact (SPOC) form submission path	2027-Q1
4	Vulnerability handling process docs	✅ Complete	SECURITY.md	—	—
5	Coordinated disclosure policy	✅ Complete	SECURITY.md	—	—
6	npm provenance + SLSA L3	✅ Complete	release.yml	—	—
7	Branch protection + required reviews	✅ Complete	GitHub repository settings	—	—
8	CodeQL + Dependabot + Scorecards + gh-advisory-database	✅ Complete	.github/workflows/	—	—
9	CSP + HSTS + security headers (per-article meta tag)	✅ Complete	src/aggregator/article-html.ts	Consider CloudFront response-headers policy as defense-in-depth layer	2027-Q2
10	Threat Model + Risk Assessment	✅ Complete	THREAT_MODEL.md v2.1	—	—
11	BCP + incident response	✅ Complete	BCPPlan.md v2.1	—	—
12	SPDX licensing	✅ Complete	REUSE.toml + .github/workflows/reuse.yml	—	—
13	EP MCP canonical tool-list drift test	✅ Complete	src/mcp/ep-mcp-client.ts exports EP_MCP_TOOLS (60+ tools); drift-guarded by test/integration/mcp/ep-mcp.test.js	—	—
14	Security advisories auto-subscribe monitoring	Partial	Dependabot monitors npm advisories	Extend monitoring to upstream EP MCP repository (european-parliament-mcp-server) via repo watching + advisory feed	2026-Q4

---

5️⃣ᶜ CE Marking Position

CE marking under CRA Article 13(3) applies to commercial manufacturers of products with digital elements. For open-source software distributed under the Article 24 OSS Steward regime, CE marking is not clearly required — open-source stewardship is a distinct regulatory regime from CE marking of commercial products, and the current draft ENISA guidance treats the two regimes separately.

Hack23 AB is monitoring EU Commission implementing acts and ENISA guidance for any determination that would extend CE marking obligations to OSS stewards or to npm packages distributed free-of-charge. The CE marking determination will be revisited Q4 2027 as the December 2027 full-compliance deadline approaches, or sooner if the Commission publishes clarifying implementing acts. Until then, no CE marking is affixed to any EU Parliament Monitor artefact.

---

6️⃣ Conformity Assessment Procedure

Assessment Methodology

EU Parliament Monitor follows CRA Module A — Internal Production Control (self-assessment), which is the appropriate conformity assessment procedure for Standard (Default) category digital products. This assessment is conducted by Hack23 AB as the manufacturer/maintainer.

Self-Assessment Process

flowchart TD
    A([Start Assessment]) --> B[Review CRA Annex I Requirements]
    B --> C[Map Technical Documentation]
    C --> D[Evaluate Security Controls]
    D --> E[Verify Testing Evidence]
    E --> F[Assess Supply Chain Security]
    F --> G{All Requirements Met?}
    G -->|Yes| H[Document Conformity]
    G -->|No| I[Implement Remediation]
    I --> D
    H --> J[CEO Review & Approval]
    J --> K[Publish Assessment]
    K --> L([Quarterly Review Cycle])
    L --> B

    style A fill:#003399,stroke:#FFCC00,color:#FFFFFF
    style H fill:#009933,stroke:#FFCC00,color:#FFFFFF
    style L fill:#003399,stroke:#FFCC00,color:#FFFFFF

Self-Assessment Checklist

✅	📋 Conformity Checkpoint	📊 Status	📅 Verified
✅	CRA Annex I Part I — All security property requirements assessed	Complete	2026-02-25
✅	CRA Annex I Part II — All vulnerability handling requirements assessed	Complete	2026-02-25
✅	CRA Annex V — Technical documentation complete and current	Complete	2026-02-25
✅	SBOM — Machine-readable CycloneDX SBOM generated per release	Complete	2026-02-25
✅	SLSA — Level 3 provenance attestation for release artifacts	Complete	2026-02-25
✅	Vulnerability Disclosure — SECURITY.md with coordinated disclosure process	Complete	2026-02-25
✅	Security Testing — SAST (CodeQL), SCA (Dependabot), unit, E2E, accessibility	Complete	2026-02-25
✅	Lifecycle Management — End-of-Life Strategy documenting support period	Complete	2026-02-25
✅	Risk Assessment — STRIDE threat model with residual risk evaluation	Complete	2026-02-25
✅	ISMS Alignment — Mapped to Hack23 ISMS public policy framework	Complete	2026-02-25

CRA Article Cross-References

• Article 6: Scope determination → Section 2 (CRA Scope & Classification)
• Article 11: Essential cybersecurity requirements → Section 5 (Essential Requirements Assessment)
• Article 19: Conformity assessment → Section 6 (Conformity Assessment Procedure)
• Article 23: Post-market obligations → Section 7 (ISMS Policy Alignment for ongoing monitoring)
• Annex I: Technical requirements → Section 5 (Essential Requirements self-assessment)
• Annex V: Technical documentation → Section 3 (Technical Documentation)

---

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	✅ 82%+ coverage	UnitTestPlan.md + Vitest reports
🌐 E2E Testing	Critical user journeys validated	✅ 14 language pages	E2ETestPlan.md + Playwright reports
🔍 SAST Scanning	Zero critical/high vulnerabilities	✅ CodeQL clean
📦 SCA Scanning	Zero critical unresolved dependencies	✅ Dependabot active	Security Overview
🔒 Secret Scanning	Zero exposed secrets/credentials	✅ GitHub Secret Scanning	Security Overview
📦 SBOM Generation	CycloneDX per release	✅ Automated	Release Artifacts
🛡️ Provenance	SLSA Level 3 attestation	✅ Active	Attestations
📊 Quality Gates	ESLint + HTMLHint + Prettier	✅ Enforced in CI	Validate Workflow
📜 License Compliance	REUSE specification	✅ FSFE REUSE compliant

🎖️ Security & Compliance Badges

📦 Release Evidence Pattern

Each release includes CRA-aligned evidence:

release/v0.7.x/
├── euparliamentmonitor-v0.7.x-sbom.json    # CycloneDX SBOM (Annex V)
├── euparliamentmonitor-v0.7.x.tar.gz       # Source archive
├── SLSA attestation (GitHub)                # Level 3 provenance
├── OpenSSF Scorecard (weekly)               # Supply chain security
└── CodeQL results (per-commit)              # SAST findings

---

7️⃣ Security Testing Evidence

Automated Security Controls

🛡️ Control	🔧 Tool	📊 Frequency	✅ Status
SAST	CodeQL	Every push/PR
SCA	Dependabot	Daily	✅ Active
Dependency Review	GitHub dependency-review-action	Every PR	✅ Active
Linting	ESLint (security plugin) + HTMLHint	Every push/PR	✅ Active
SBOM	CycloneDX	Every release	✅ Active
Scorecard	OpenSSF Scorecard	Weekly
SLSA Provenance	SLSA Level 3	Every release	✅ Active
License Compliance	REUSE	Every push/PR

Testing Coverage

🧪 Test Type	🔧 Framework	📊 Coverage	📋 Reference
Unit Tests	Vitest + v8 coverage	82%+ code coverage	UnitTestPlan.md
E2E Tests	Playwright	14 language pages verified	E2ETestPlan.md
Accessibility	Playwright + axe-core	WCAG 2.1 AA compliance	E2ETestPlan.md
Performance	Lighthouse	Core Web Vitals benchmarks	performance-testing.md
HTML Validation	HTMLHint	All output HTML files	package.json scripts
Code Quality	ESLint + SonarCloud + jscpd	TypeScript source analysis	eslint.config.js

---

8️⃣ Comprehensive ISMS Policy Alignment

🏷️ ISMS Policy	📋 CRA Mapping	🔧 EU Parliament Monitor Implementation	✅ Status
🔐 Information Security Policy	Overall CRA governance	Security-by-design static site architecture; public data classification; comprehensive security documentation	✅ Aligned
🛠️ Secure Development Policy	Annex I Part I (1–13)	CodeQL SAST; ESLint security plugin; Vitest/Playwright testing; branch protection; PR reviews; automated CI/CD gates	✅ Aligned
🔍 Vulnerability Management	Annex I Part II (1–8)	Dependabot daily scanning; severity-based SLAs (Critical 7d, High 30d); GitHub Security Advisories; coordinated disclosure via SECURITY.md	✅ Aligned
📝 Change Management	Security updates (Annex I Part II §5)	Git-based change tracking; required PR reviews; automated testing gates; deployment via CI/CD; release workflow with SBOM	✅ Aligned
🏷️ Classification Framework	Risk assessment	CIA classification (Public/Moderate/Standard); impact analysis; classification-driven security controls	✅ Aligned
🔒 Cryptography Policy	Data confidentiality (Annex I Part I §4)	HTTPS-only delivery via GitHub Pages; TLS 1.2+ for all transport; no cryptographic key management needed (static site)	✅ Aligned
🔑 Access Control Policy	Unauthorized access (Annex I Part I §3)	GitHub repository access controls; branch protection; CODEOWNERS enforcement; no end-user authentication (public site)	✅ Aligned
🤝 Third Party Management	Supply chain security	Dependabot for dependency monitoring; SLSA Level 3 provenance; dependency-review on PRs; npm audit enforcement; pinned action versions	✅ Aligned
🔓 Open Source Policy	OSS governance	Apache-2.0 license; REUSE compliance; SBOM generation; public security policy; coordinated disclosure process	✅ Aligned
🚨 Incident Response Plan	Post-market surveillance	Security incident handling procedures; communication protocols; forensics capability; GitHub Security Advisories integration	✅ Aligned
🔄 Business Continuity Plan	Availability (Annex I Part I §7)	GitHub Pages CDN resilience; git-based disaster recovery; static site regeneration capability; documented BCP	✅ Aligned
💾 Backup Recovery Policy	Data integrity (Annex I Part I §5)	Git repository as immutable backup; GitHub Pages deployment history; full site regeneration from source	✅ Aligned
📊 Security Metrics	Monitoring & recording (Annex I Part I §11)	CodeQL scan results tracking; Dependabot alert metrics; test coverage reporting; OpenSSF Scorecard trending	✅ Aligned
📊 Risk Assessment Methodology	CRA risk evaluation	STRIDE threat model; risk categorization with likelihood/impact assessment; residual risk evaluation; evidence-linked controls	✅ Aligned
🏷️ Data Classification Policy	Data handling (Annex I Part I §6)	Public data only classification; no PII handling; data minimization by design; EU Parliament open data sourcing	✅ Aligned
🌐 ISMS Transparency Plan	Disclosure & transparency	Public security documentation; open-source CRA assessment; transparent vulnerability reporting; community engagement	✅ Aligned

ISMS Integration Benefits

• 🔄 Operational Continuity: CRA self-assessment integrated with existing ISMS security operations and review cycles
• 📊 Evidence Reuse: Security metrics, test results, and monitoring data serve dual ISMS/CRA documentation purposes
• 🎯 Minimal Overhead: Static site architecture naturally satisfies many CRA requirements through design simplicity
• 🤝 Stakeholder Confidence: Transparent assessment demonstrates professional security practices for open-source civic technology

🔀 ISO 27001:2022 ↔ EU CRA Cross-Reference

The table below maps ISO 27001:2022 controls directly to CRA Annex I references, demonstrating how Hack23 AB's existing ISMS controls satisfy CRA essential requirements — minimising compliance overhead through integrated governance.

🏛️ ISO 27001:2022 Control	📜 CRA Annex I Reference	📋 Description	✅ Status
A.5.1 Information security policies	Part I §1 (Security by default)	Security governance framework establishing security-by-design principles	✅ Aligned
A.8.8 Technical vulnerability management	Part I §2(2) (Vulnerability handling)	CVE tracking, Dependabot scanning, and severity-based remediation SLAs	✅ Aligned
A.8.25 Secure development lifecycle	Part II §1 (Secure development)	SDLC security integration via CodeQL SAST, PR reviews, and CI/CD gates	✅ Aligned
A.5.24 Information security incident management	Part I §2(5) (Incident reporting)	Security incident procedures via SECURITY.md and GitHub Security Advisories	✅ Aligned
A.8.13 Information backup	Part I §5 (Data integrity)	Git-based immutable backup strategy with full site regeneration capability	✅ Aligned
A.5.36 Compliance with policies and standards	Module A self-assessment	Ongoing conformity verification through quarterly CRA assessment review cycle	✅ Aligned
A.8.20 Network security	Part I §8 (Availability of other services)	Static site generates zero runtime outbound traffic; no network attack surface at runtime	✅ Aligned
A.8.29 Security testing in development	Part II §3 (Regular testing)	Vitest unit tests, Playwright E2E, axe-core accessibility, and Lighthouse performance	✅ Aligned
A.5.20 Addressing security in supplier agreements	Part I supply chain (§9)	SLSA Level 3 provenance, dependency-review workflow, pinned action versions	✅ Aligned

---

9️⃣ Post-Market Surveillance

Supports CRA Article 23 — Obligations of Economic Operators

📡 CRA Monitoring Obligation	🔧 Implementation	⏱️ Frequency	🎯 Action Trigger	📋 Evidence
🔍 Vulnerability Monitoring (Art. 23.1)	CVE feeds via Dependabot + GitHub Advisory Database	Continuous	Auto-create Dependabot PRs	Security Overview
🚨 Incident Reporting (Art. 23.2)	SECURITY.md coordinated disclosure process	Real-time	ENISA 24h notification readiness	SECURITY.md
📊 Security Posture Tracking (Art. 23.3)	OpenSSF Scorecard + CodeQL monitoring	Weekly	Score decline triggers investigation
🔄 Update Distribution (Art. 23.4)	GitHub Releases with SLSA attestation	As needed	Critical vulnerability patches	Releases

📋 CRA Reporting Readiness: Documentation and procedures prepared for ENISA incident reporting per Incident Response Plan

🔗 ISMS Monitoring Integration:

• 📊 Continuous Monitoring: Security posture tracking per Security Metrics
• 🌐 Transparency Framework: Public disclosure strategy via ISMS Transparency Plan
• 🤝 Third-Party Monitoring: Supplier surveillance per Third Party Management
• ✅ Compliance Tracking: Regulatory adherence via Compliance Checklist

---

🤖 AI Agent-Driven CRA Compliance

Supports CRA Article 16 — Quality Management System through Automated Evidence Generation

📋 Automated Compliance Workflow

Hack23 AB's curated agent ecosystem monitors and validates CRA evidence generated by automated workflows:

flowchart TD
    BUILD[🔨 Build Process<br/>GitHub Actions Workflow] --> SBOM_GEN[📦 SBOM Generation<br/>CycloneDX + Dependency Graph]
    SBOM_GEN --> AGENT_REVIEW[🤖 Task Agent<br/>SBOM Validation & Gap Detection]

    AGENT_REVIEW --> VULN_SCAN[🔍 Vulnerability Scanning<br/>Dependabot + CodeQL]
    VULN_SCAN --> AGENT_TRIAGE[🤖 Agent Triage<br/>CRA Disclosure Requirements]

    AGENT_TRIAGE --> SLSA[🎖️ SLSA Attestation<br/>Level 3 Provenance]
    SLSA --> EVIDENCE[📊 GitHub Actions<br/>Evidence Package]

    EVIDENCE --> CE{✅ CRA Conformity<br/>Ready?}
    CE -->|Yes| APPROVAL[👨‍💼 CEO Final Approval]
    CE -->|No| GAP[📋 Compliance Gap<br/>Issue Creation]

    GAP --> REMEDIATE[👷 Specialist Agent<br/>Gap Remediation]
    REMEDIATE --> SBOM_GEN
    APPROVAL --> PUBLISH[🌐 Assessment Published]

    style BUILD fill:#1565C0,color:#fff
    style SBOM_GEN fill:#4CAF50,color:#fff
    style AGENT_REVIEW fill:#FF9800,color:#fff
    style VULN_SCAN fill:#4CAF50,color:#fff
    style AGENT_TRIAGE fill:#FF9800,color:#fff
    style SLSA fill:#1565C0,color:#fff
    style EVIDENCE fill:#4CAF50,color:#fff
    style CE fill:#FFD600,color:#000
    style APPROVAL fill:#4CAF50,color:#fff
    style GAP fill:#D32F2F,color:#fff
    style REMEDIATE fill:#FF9800,color:#fff
    style PUBLISH fill:#4CAF50,color:#fff

🎯 Agent Responsibilities Matrix

🤖 Agent	📋 CRA Responsibility	⏱️ Frequency	📊 Output
Security Architect	Vulnerability scanning, SAST/SCA oversight	Per-commit	CodeQL results, dependency audit
DevOps Engineer	SBOM generation, SLSA attestation, CI/CD gates	Per-release	Release artifacts, provenance
Quality Engineer	Test coverage, E2E validation, accessibility	Per-PR	Test reports, coverage metrics
Product Task Agent	CRA gap detection, issue creation, tracking	Weekly	Compliance issues, gap reports
Documentation Architect	CRA assessment updates, evidence documentation	Quarterly	Updated CRA-ASSESSMENT.md

📊 Automated Compliance Evidence Generation

📋 CRA Section	🤖 Automated By	📊 Evidence Type	✅ Status
§1 Project Identification	Release workflow	Version, SBOM, attestation	✅ Automated
§3 Technical Documentation	TypeDoc + JSDoc	API documentation generation	✅ Automated
§5 Essential Requirements	CodeQL + Dependabot	SAST/SCA scan results	✅ Automated
§6 Conformity Evidence	CI/CD pipeline	Badges, test results, attestations	✅ Automated
§7 Security Testing	Vitest + Playwright	Coverage reports, E2E results	✅ Automated
§9 Post-Market Surveillance	Dependabot + Scorecard	Vulnerability monitoring	✅ Automated

---

🔟 EU Declaration of Conformity

Supports CRA Article 28 — EU Declaration of Conformity

🏢 Manufacturer: Hack23 AB, Stockholm, Sweden
📦 Product: EU Parliament Monitor v0.7.23
📋 CRA Compliance: Self-assessment documentation supporting CRA essential cybersecurity requirements evaluation
🔍 Assessment: Self-assessment documentation per CRA Article 24 (Module A — Internal Production Control)
📊 Standards: ISO/IEC 27001:2022 • NIST CSF 2.0 • CIS Controls v8.1 • OWASP ASVS

📝 Note: As an open-source project distributed under Apache-2.0 license with no commercial monetization, EU Parliament Monitor falls under the CRA open-source software exemption (Article 18). This declaration is maintained voluntarily to demonstrate security excellence and support downstream users' compliance needs.

📅 Date & Signature: 2026-03-19 — James Pether Sörling, CEO/Founder
📂 Technical Documentation: This assessment + evidence bundle supports CRA Annex V technical documentation requirements

---

1️⃣1️⃣ Assessment Completion & Approval

Supports CRA Article 16 — Quality Management System Documentation

📊 CRA Self-Assessment Summary

Overall CRA Documentation Status: ✅ Self-Assessment Documented

Key CRA Documentation Areas:

• ✅ Annex I essential requirements documented and assessed (Section 5)
• ✅ Annex V technical documentation structured (Section 3)
• ✅ Article 11 security measures documented (Section 7–8)
• ✅ Article 23 post-market surveillance procedures documented (Section 9)
• ✅ Article 28 declaration of conformity prepared (Section 10)

Outstanding Documentation: None — all CRA sections assessed and documented

✅ Formal Approval

👤 Role	📝 Name	📅 Date	✍️ Assessment Attestation
🔒 CRA Security Assessment	James Pether Sörling	2026-03-19	Essential requirements documented and assessed
🎯 Product Responsibility	James Pether Sörling	2026-03-19	Technical documentation complete and structured
⚖️ Legal Compliance Review	James Pether Sörling	2026-03-19	EU regulatory documentation requirements addressed

📊 CRA Assessment Status: Self-Assessment Documented

---

🎨 CRA Assessment Maintenance

📋 Update Triggers

Per CRA Article 15 — Substantial Modification

CRA assessment updated when changes constitute "substantial modification" under CRA:

1. 🏗️ Security Architecture Changes: New authentication methods, trust boundaries, or encryption
2. 🛡️ Essential Requirement Impact: Changes affecting Annex I compliance
3. 📦 Critical Dependencies: New supply chain components with security implications
4. 🔍 Risk Profile Changes: New threats or vulnerability classes
5. ⚖️ Regulatory Updates: CRA implementing acts or guidance changes

🎯 Maintenance Principle: Assessment stability preferred — avoid routine updates that don't impact CRA compliance

🔗 CRA Evidence Integration

🏷️ Product Version: v0.7.23
📊 Assessment Status: ✅ Self-Assessment Complete
🔍 OpenSSF Scorecard:
🎖️ SLSA Level: 3 (Build provenance attestation)
📦 SBOM: CycloneDX generated per release
🔒 Vulnerability Status: Zero known critical/high vulnerabilities
📅 Last Full Assessment: 2026-03-19
⏰ Next Scheduled Review: 2026-06-19

---

📚 CRA Regulatory Alignment

🔐 CRA Article Cross-References

📜 CRA Article	📋 Requirement	📊 Assessment Section	✅ Status
Article 6	Scope determination	Section 2 (CRA Scope & Classification)	✅ Assessed
Article 11	Essential cybersecurity requirements	Section 5 (Essential Requirements)	✅ Assessed
Article 15	Substantial modification	CRA Assessment Maintenance	✅ Documented
Article 16	Quality management system	Section 11 (Assessment Completion)	✅ Documented
Article 19	Conformity assessment	Section 6 (Conformity Assessment)	✅ Assessed
Article 23	Post-market obligations	Section 9 (Post-Market Surveillance)	✅ Documented
Article 24	Module A self-assessment	Section 6 (Self-Assessment Process)	✅ Complete
Article 28	EU Declaration of Conformity	Section 10 (Declaration)	✅ Prepared
Annex I	Essential requirements	Section 5 (Annex I Assessment)	✅ Assessed
Annex V	Technical documentation	Section 3 (Technical Documentation)	✅ Complete

🌐 ISMS Integration Benefits

• 🔄 Operational Continuity: CRA self-assessment integrated with existing ISMS security operations and review cycles
• 📊 Evidence Reuse: Security metrics, test results, and monitoring data serve dual ISMS/CRA documentation purposes
• 🎯 Minimal Overhead: Static site architecture naturally satisfies many CRA requirements through design simplicity
• 🤝 Stakeholder Confidence: Transparent assessment demonstrates professional security practices for open-source civic technology

📋 Complete ISMS Policy Framework

🔐 Core Security Governance

Policy	CRA Relevance	Link
Information Security Policy	Overall CRA governance	View
Secure Development Policy	Annex I Part I (secure development)	View
Open Source Policy	OSS governance & CRA exemption	View
Access Control Policy	Annex I Part I §3 (unauthorized access)	View

🛡️ Security Control Implementation

Policy	CRA Relevance	Link
Cryptography Policy	Annex I Part I §4 (data confidentiality)	View
Network Security Policy	Annex I Part I §8 (availability)	View
Vulnerability Management	Annex I Part II (vulnerability handling)	View
Third Party Management	Supply chain security	View

⚙️ Operational Excellence Framework

Policy	CRA Relevance	Link
Change Management	Security updates (Annex I Part II §5)	View
Incident Response Plan	Post-market surveillance (Art. 23)	View
Business Continuity Plan	Availability (Annex I Part I §7)	View
Backup Recovery Policy	Data integrity (Annex I Part I §5)	View

📊 Performance Management & Compliance

Policy	CRA Relevance	Link
Security Metrics	Monitoring (Annex I Part I §11)	View
Compliance Checklist	CRA conformity tracking	View
Classification Framework	Risk assessment (Annex I Part I §6)	View
Risk Assessment Methodology	CRA risk evaluation	View
CRA Conformity Assessment Process	Process framework	View

---

🔗 Related Documentation

🏛️ Project Documentation

• 🏛️ Architecture — C4 system architecture
• 🛡️ Security Architecture — Security controls and threat mitigations
• 🎯 Threat Model — STRIDE threat analysis
• 🏷️ Classification — CIA classification & business impact
• 🔒 Security Policy — Vulnerability reporting process
• 📦 End-of-Life Strategy — Technology lifecycle management
• 🔄 Business Continuity Plan — Disaster recovery planning
• 💰 Financial Security Plan — Cost & security analysis
• ⚙️ Workflows — CI/CD security controls
• 📊 Data Model — Data structures and relationships
• 🧪 Unit Test Plan — Unit testing strategy
• 🔍 E2E Test Plan — End-to-end testing
• ⚡ Performance Testing — Performance validation

🔗 Hack23 CRA Reference Implementations

• 🕵️ CIA — CRA Assessment — Political transparency platform (reference template)
• ⚫ Black Trigram — CRA Assessment — Game product assessment
• 🛡️ CIA Compliance Manager — CRA Assessment — Compliance automation tool

📋 ISMS Process References

• 🛡️ CRA Conformity Assessment Process — CRA assessment process template
• 🔓 Open Source Policy — Open source governance requirements
• 🛠️ Secure Development Policy — Secure SDLC requirements
• 🔍 Vulnerability Management — Vulnerability handling SLAs
• 🏷️ Classification Framework — CIA classification

---

📋 Document Control:
✅ Approved by: James Pether Sörling, CEO
📤 Distribution: Public
🏷️ Classification:
📅 Effective Date: 2026-05-03
🔄 CRA Alignment: Self-assessment per CRA Module A — supports CRA Annex V technical documentation and Annex I essential requirements
🏛️ ISMS Integration: Comprehensive alignment with Hack23 ISMS Public Framework
🏛️ Process Reference: CRA Conformity Assessment Process
🔓 Open Source Policy: Open Source Policy
🎯 Framework Compliance: