Skip to content

CRA-ASSESSMENT.md

Latest commit

 

History

History
801 lines (615 loc) · 76.9 KB

CRA-ASSESSMENT.md

File metadata and controls

801 lines (615 loc) · 76.9 KB

Hack23 Logo

🛡️ EU Parliament Monitor — CRA Conformity Assessment

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

Owner Version Effective Date Review Cycle

📋 Document Owner: CEO | 📄 Version: 2.1 | 📅 Last Updated: 2026-04-20 (UTC)
🔄 Review Cycle: Quarterly | ⏰ Next Review: 2026-07-20
🏛️ Process Reference: CRA Conformity Assessment Process

📚 Architecture Documentation Map

Document Focus Description Documentation Link
Architecture 🏛️ Architecture C4 model showing current system structure View Source
Future Architecture 🏛️ Architecture C4 model showing future system structure View Source
Mindmaps 🧠 Concept Current system component relationships View Source
Future Mindmaps 🧠 Concept Future capability evolution View Source
SWOT Analysis 💼 Business Current strategic assessment View Source
Future SWOT Analysis 💼 Business Future strategic opportunities View Source
Data Model 📊 Data Current data structures and relationships View Source
Future Data Model 📊 Data Enhanced European Parliament data architecture View Source
Flowcharts 🔄 Process Current data processing workflows View Source
Future Flowcharts 🔄 Process Enhanced AI-driven workflows View Source
State Diagrams 🔄 Behavior Current system state transitions View Source
Future State Diagrams 🔄 Behavior Enhanced adaptive state transitions View Source
Security Architecture 🛡️ Security Current security implementation View Source
Future Security Architecture 🛡️ Security Security enhancement roadmap View Source
Threat Model 🎯 Security STRIDE threat analysis View Source
Classification 🏷️ Governance CIA classification & BCP View Source
CRA Assessment 🛡️ Compliance Cyber Resilience Act View Source
Workflows ⚙️ DevOps CI/CD documentation View Source
Future Workflows 🚀 DevOps Planned CI/CD enhancements View Source
Business Continuity Plan 🔄 Resilience Recovery planning View Source
Financial Security Plan 💰 Financial Cost & security analysis View Source
End-of-Life Strategy 📦 Lifecycle Technology EOL planning View Source
Unit Test Plan 🧪 Testing Unit testing strategy View Source
E2E Test Plan 🔍 Testing End-to-end testing View Source
Performance Testing ⚡ Performance Performance benchmarks View Source
Security Policy 🔒 Security Vulnerability reporting & security policy View Source

🎯 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.40 (2026-04-20)
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 / 8 article types / 10 gh-aw workflows / 3061+ tests / 52 test files
Technology Stack Node.js 25, 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.11 (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 Applicability Distribution 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
Loading

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 25/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 25 Current support timeline (upgrading to Node.js 26 LTS); 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> in every article (src/templates/article-template.ts:377-399)
  • No known exploitable vulns at release ← CodeQL + Dependabot + gh-advisory-database gate (blocks PRs with new advisories)
  • 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; canonical tool-list drift tests (IMF + WB asserted in test/integration/mcp/*); validator gate in scripts/utils/validate-analysis-completeness.js (compiled from src/utils/validate-analysis-completeness.ts)
  • 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); WB-OR-IMF OR-gate (articlePolicyHasEconomicContext)
  • Attack surface minimization ← static content only; AWF Squid firewall egress allowlist; Docker sandbox for agentic workflows
  • 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.69.0 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 25 Current tracked (Node.js 26 LTS upgrade planned Apr 2026); 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/templates/article-template.ts:377-399 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 Gap IMF + WB only — EP MCP client does not yet export EP_MCP_TOOLS Add EP_MCP_TOOLS export + integration test in test/integration/mcp/ 2026-Q3
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
Loading

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 CodeQL
📦 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 REUSE

🎖️ Security & Compliance Badges

OpenSSF Scorecard OpenSSF Best Practices SLSA 3 CodeQL REUSE Compliance License

📦 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 CodeQL
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 Scorecard
SLSA Provenance SLSA Level 3 Every release ✅ Active
License Compliance REUSE Every push/PR REUSE

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 Scorecard
🔄 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:

🤖 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
Loading

🎯 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: 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

🔗 Hack23 CRA Reference Implementations

📋 ISMS Process References

📋 Document Control:
✅ Approved by: James Pether Sörling, CEO
📤 Distribution: Public
🏷️ Classification: Confidentiality: Public Integrity: Moderate Availability: Standard
📅 Effective Date: 2026-04-20
🔄 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: ISO 27001 NIST CSF 2.0 CIS Controls