Evidence-Driven Conformity Through Systematic Assessment
Demonstrating CRA Compliance for Swedish Parliament Intelligence Platform
📋 Document Owner: CEO | 📄 Version: 1.1 | 📅 Last Updated: 2026-03-19 (UTC) 🔄 Review Cycle: Quarterly | ⏰ Next Review: 2026-06-19 🏢 Owner: Hack23 AB (Org.nr 5595347807) | 🏷️ Classification: Public
Hack23 AB's CRA conformity assessment process demonstrates how systematic regulatory compliance directly enables business growth rather than creating operational burden. This assessment documents Riksdagsmonitor's compliance with the EU Cyber Resilience Act (CRA), providing evidence-based self-assessment of cybersecurity requirements for our Swedish Parliament intelligence platform.
As a cybersecurity consulting company, our approach to CRA compliance becomes a showcase of professional implementation, demonstrating to potential clients how systematic regulatory adherence creates competitive advantages through robust security foundations while enabling EU market access.
— James Pether Sörling, CEO/Founder
This process provides a concise, repeatable CRA Conformity Assessment for Riksdagsmonitor. Aligns with CRA Annex I & V, Hack23 classification, secure development, and transparency policies.
Scope: Riksdagsmonitor platform within Asset Register requiring EU market placement.
Process Alignment: This assessment follows the CRA Conformity Assessment Process template and is governed by the Open Source Policy for open source compliance requirements.
| Document | Focus | Description |
|---|---|---|
| 🏛️ Architecture | 🏗️ C4 Models | System context, containers, components |
| 📊 Data Model | 📊 Data | Entity relationships and data dictionary |
| 🔄 Flowchart | 🔄 Processes | Business process and data flows |
| 📈 State Diagram | 📈 States | System state transitions and lifecycles |
| 🧠 Mindmap | 🧠 Concepts | System conceptual relationships |
| 💼 SWOT | 💼 Strategy | Strategic analysis and positioning |
| 🔧 Workflows | 🔧 DevOps | CI/CD automation and pipelines |
| 🛡️ Security Architecture | 🔒 Security | Current security controls and design |
| 🎯 Threat Model | 🎯 Threats | STRIDE/MITRE ATT&CK analysis |
| 🛡️ CRA Assessment ⭐ | ⚖️ Compliance | EU Cyber Resilience Act conformity |
The following Hack23 AB projects demonstrate completed CRA assessments:
| 🚀 Project | 📦 Product Type | 🏷️ CRA Classification | 📋 Assessment Status | 🔗 Reference Link |
|---|---|---|---|---|
| 🕵️ CIA (Citizen Intelligence Agency) | Political transparency platform | Standard (Non-commercial OSS) | ✅ Complete | 📄 CRA Assessment |
| ⚫ Black Trigram | Korean martial arts game | Standard (Non-commercial OSS) | ✅ Complete | 📄 CRA Assessment |
| 🛡️ CIA Compliance Manager | Compliance automation tool | Standard (Non-commercial OSS) | ✅ Complete | 📄 CRA Assessment |
| 🗳️ Riksdagsmonitor | Parliament intelligence platform | Standard (Non-commercial OSS) | ✅ This Document | 📄 CRA Assessment |
Supports CRA Annex V § 1 - Product Description Requirements
| Field | Value |
|---|---|
| 📦 Product | Riksdagsmonitor |
| 🏷️ Version Tag | 0.4.1 (reflects current project state) |
| 🔗 Repository | https://github.com/Hack23/riksdagsmonitor |
| 📧 Security Contact | security@hack23.org |
| 🌐 Website | https://riksdagsmonitor.com |
| 🎯 Purpose (1–2 lines) | Static HTML/CSS intelligence platform monitoring Swedish Parliament (Riksdag) activity, providing 14-language dashboards with 50+ years of political data through CIA platform integration and automated news generation |
📋 Evidence Links:
- 🏗️ System Architecture: ARCHITECTURE.md — Complete C4 model architecture
- 🔐 Security Architecture: SECURITY_ARCHITECTURE.md — Defense-in-depth security controls
- 🛡️ Future Security Vision: FUTURE_SECURITY_ARCHITECTURE.md — Security roadmap
- 📊 Data Architecture: DATA_MODEL.md — Data structures, schemas, relationships
- 🔄 Process Workflows: FLOWCHART.md — Data processing and CI/CD workflows
- 🧠 System Overview: MINDMAP.md — Conceptual system relationships
- 🎯 Strategic Analysis: SWOT.md — Strategic assessment
- 🎯 Threat Analysis: THREAT_MODEL.md — STRIDE and MITRE ATT&CK mapping
- 🔧 CI/CD Pipelines: WORKFLOWS.md — 43 workflow automation documentation
📊 Project Status & Quality Badges:
📋 Data Sources Evidence:
- 🏛️ Swedish Parliament: data.riksdagen.se — Parliamentary members, committees, documents, votes
- 🗳️ Election Authority: val.se — Election data, parties, voting results
- 🕵️ CIA Platform: Citizen Intelligence Agency — 19 intelligence products, risk assessments, analytics
Supports CRA Article 6 - Scope and Article 7 - Product Classification Assessment
📝 CRA Scope Justification: Riksdagsmonitor is a non-commercial open-source static website providing Swedish Parliament transparency services through data visualization and news generation. As a volunteer-driven initiative with community distribution via GitHub under Apache 2.0 license, it falls under non-commercial OSS with Standard CRA classification enabling self-assessment approach. The static site architecture (HTML/CSS/JS with no server-side execution) significantly reduces the attack surface compared to traditional web applications.
📋 Classification Evidence:
- 📜 Open Source License: Apache 2.0 License
- 🏛️ Classification Framework: ISMS Classification Policy
- 📊 Public Repository: GitHub Repository
🔍 Classification Impact:
- Standard: Self-assessment approach (this document provides evidence)
- Class I/II: Would require notified body assessment + additional documentation
Supports CRA Annex V § 2 - Technical Documentation Requirements
| 🏗️ CRA Technical Area | 📝 Implementation Summary | 📋 Evidence Location |
|---|---|---|
| 🎨 Product Architecture (Annex V § 2.1) | Static HTML/CSS website with C4 architecture model. Deployed on AWS CloudFront (us-east-1 primary, eu-west-1 replica) with GitHub Pages DR. 14-language support, Chart.js/D3.js dashboards | ARCHITECTURE.md + SECURITY_ARCHITECTURE.md + MINDMAP.md |
| 📦 SBOM & Components (Annex I § 1.1) | npm package management with package-lock.json. Dependabot automated dependency scanning. OpenSSF Scorecard monitoring | package.json + Dependabot Config + OpenSSF Scorecard |
| 🔐 Cybersecurity Controls (Annex I § 1.2) | Static site architecture (no server-side execution), HTTPS-only via CloudFront/GitHub Pages, CSP headers, SRI for CDN assets, SHA-pinned GitHub Actions, step-security/harden-runner | SECURITY_ARCHITECTURE.md + THREAT_MODEL.md |
| 🛡️ Supply Chain Security (Annex I § 1.3) | SHA-pinned GitHub Actions, Dependabot automation, OpenSSF Scorecard monitoring, CodeQL analysis, dependency review workflow, step-security/harden-runner egress auditing | WORKFLOWS.md + OpenSSF Scorecard |
| 🔄 Update Mechanism (Annex I § 1.4) | Automated CI/CD pipeline via GitHub Actions with security scanning (CodeQL, dependency review), dual deployment (S3 + GitHub Pages), version management via release workflow | WORKFLOWS.md + Release Workflow |
| 📊 Security Monitoring (Annex I § 1.5) | GitHub Security Dashboard (code scanning, secret scanning, Dependabot alerts), Lighthouse CI performance monitoring, uptime monitoring, AWS CloudWatch/CloudFront metrics | SECURITY_ARCHITECTURE.md + WORKFLOWS.md |
| 🏷️ Data Protection (Annex I § 2.1) | No personal data collection. Public political data only. GDPR compliant by design — static site with no user accounts, no cookies, no tracking. All data sourced from public government APIs | DATA_MODEL.md + THREAT_MODEL.md |
| 📚 User Guidance (Annex I § 2.2) | Comprehensive README with deployment instructions, architecture documentation, security configuration guides | README.md + ARCHITECTURE.md + SECURITY_ARCHITECTURE.md |
| 🔍 Vulnerability Disclosure (Annex I § 2.3) | Public vulnerability disclosure policy via GitHub Security Advisories, coordinated disclosure process, 48h acknowledgment timeline | SECURITY.md + Security Advisories |
📋 Comprehensive ISMS Integration:
- 🏗️ Architecture & Design: Complete Architecture + Security Architecture + Future Vision + Future Security
- 📊 Asset Management: Asset Register
- 🔒 Security Controls: Information Security Policy + Network Security Policy
- 🔧 Development Process: Secure Development Policy + CI/CD Evidence
Supports CRA Annex V § 3 - Risk Assessment Documentation
Reference: 📊 Risk Assessment Methodology and
| 🚨 CRA Risk Category | 🎯 Asset | 📊 Likelihood | 💥 Impact (C/I/A) | 🛡️ CRA Control Implementation | ⚖️ Residual | 📋 Evidence |
|---|---|---|---|---|---|---|
| Supply Chain Attack (Art. 11) | Build pipeline & npm dependencies | M | H/H/M | SHA-pinned GitHub Actions + Dependabot automation + step-security/harden-runner egress audit + OpenSSF Scorecard monitoring + dependency review workflow | L | WORKFLOWS.md + OpenSSF Scorecard |
| Website Defacement (Art. 11) | Static website content & dashboards | M | M/H/M | Branch protection rules + required PR reviews + CodeQL scanning + dual deployment (S3 + GitHub Pages) for DR | L | SECURITY_ARCHITECTURE.md + THREAT_MODEL.md |
| Data Integrity Attack (Art. 11) | Political data & news content | M | L/H/M | CIA data validation schemas + automated translation validation + multi-source data verification + git-based audit trail | L | DATA_MODEL.md + WORKFLOWS.md |
| AI Content Manipulation (Art. 11) | AI-generated news articles | M | M/H/L | LLM output validation + editorial quality checks + translation verification + content provenance tracking | M | THREAT_MODEL.md + WORKFLOWS.md |
| CDN/Infrastructure Compromise (Art. 11) | CloudFront distribution & S3 storage | L | M/H/H | AWS multi-region deployment + SRI for CDN assets + GitHub Pages DR failover + HTTPS-only + TLS 1.3 | L | SECURITY_ARCHITECTURE.md + ARCHITECTURE.md |
| Component Vulnerability (Art. 11) | npm dependencies (Chart.js, D3.js, Vite) | M | M/H/M | Dependabot updates + CodeQL scanning + dependency review workflow + SRI hashes for CDN assets | L | Security Scanning + Dependabot |
⚖️ CRA Risk Statement: LOW — Static site architecture eliminates entire categories of server-side vulnerabilities. Comprehensive security controls and evidence-based monitoring support CRA essential cybersecurity requirements. ✅ Risk Acceptance: James Sörling, CEO Hack23 AB — February 2026
📋 Risk Management Framework Evidence:
- 📊 Methodology: Risk Assessment Framework
⚠️ Risk Tracking: Active Risk Register- 🔄 Business Continuity: Continuity Planning
- 🆘 Disaster Recovery: Recovery Procedures
- 📈 Risk Monitoring: Security Metrics
Supports CRA Annex I - Essential Requirements Self-Assessment
| 📋 CRA Annex I Requirement | ✅ Status | 📋 Implementation Evidence |
|---|---|---|
| 🛡️ § 1.1 - Secure by Design | [x] | Defense-in-depth Architecture — Static site architecture eliminates server-side attack vectors. CSP headers, SRI hashes, HTTPS-only, multi-region deployment |
| 🔒 § 1.2 - Secure by Default | [x] | Static HTML/CSS with no server-side execution. No user accounts, no cookies, no tracking. Security Architecture documents secure defaults |
| 🏷️ § 2.1 - Personal Data Protection | [x] | No personal data collection — GDPR compliant by design. Public political data only. Data Model documents data handling |
| 🔍 § 2.2 - Vulnerability Disclosure | [x] | SECURITY.md with GitHub Security Advisories, coordinated disclosure, 48h acknowledgment. Vulnerability Management |
| 📦 § 2.3 - Software Bill of Materials | [x] | package.json + package-lock.json provide complete dependency inventory. Dependabot provides continuous SCA |
| 🔐 § 2.4 - Secure Updates | [x] | Automated CI/CD pipeline with CodeQL, dependency review, SHA-pinned actions. WORKFLOWS.md documents 43 workflows |
| 📊 § 2.5 - Security Monitoring | [x] | GitHub Security Dashboard (code scanning, secret scanning, Dependabot), Lighthouse CI, uptime monitoring. SECURITY_ARCHITECTURE.md |
| 📚 § 2.6 - Security Documentation | [x] | Complete architecture documentation portfolio: ARCHITECTURE.md, SECURITY_ARCHITECTURE.md, THREAT_MODEL.md, DATA_MODEL.md + 6 future-state documents |
🎯 CRA Self-Assessment Status: EVIDENCE_DOCUMENTED
🔍 Security Implementation Evidence:
- 🛡️ Static Site Security: No server-side code execution eliminates SQL injection, RCE, SSRF, and authentication bypass vulnerabilities
- 🔒 Transport Security: HTTPS-only via AWS CloudFront (TLS 1.3) and GitHub Pages
- 📊 Supply Chain: SHA-pinned GitHub Actions, Dependabot, CodeQL, step-security/harden-runner
- 🔐 Content Integrity: Subresource Integrity (SRI) for CDN-loaded Chart.js and D3.js libraries
Supports CRA Article 19 - Conformity Assessment Documentation
Reference: 🛠️ Secure Development Policy
| 🧪 Control | 🎯 Requirement | ✅ Implementation | 📋 Evidence |
|---|---|---|---|
| 🧪 Unit Testing | Comprehensive test coverage | ✅ Implemented | Vitest — 1700+ tests across 43 test files |
| 🌐 E2E Testing | Critical user journeys validated | ✅ Implemented | Cypress E2E — Multi-language homepage, dashboard, accessibility |
| 🔍 SAST Scanning | Zero critical/high vulnerabilities | ✅ Implemented | CodeQL Analysis |
| 📦 SCA Scanning | Zero critical unresolved dependencies | ✅ Implemented | Dependabot Alerts + Dependency Review |
| 🔒 Secret Scanning | Zero exposed secrets/credentials | ✅ Implemented | GitHub Secret Scanning + Push protection enabled |
| 📊 Quality Gates | HTML validation + link checking | ✅ Implemented | Quality Checks — HTMLHint + linkinator |
| 🔐 Supply Chain | SHA-pinned actions + egress audit | ✅ Implemented | OpenSSF Scorecard + step-security/harden-runner |
| 📈 Performance | Lighthouse CI monitoring | ✅ Implemented | Lighthouse CI — Core Web Vitals tracking |
🔍 Supply Chain Security:
🛡️ Security Scanning:
📊 Quality & Testing:
⚖️ License:
Supports CRA Article 23 - Obligations of Economic Operators
Reference: 🌐 ISMS Transparency Plan and 📊 Security Metrics
| 📡 CRA Monitoring Obligation | 🔧 Implementation | ⏱️ Frequency | 🎯 Action Trigger | 📋 Evidence |
|---|---|---|---|---|
| 🔍 Vulnerability Monitoring (Art. 23.1) | Dependabot + GitHub advisories + CodeQL scanning + dependency review | Continuous | Auto-create security issues and PRs | Dependabot Alerts + Security Advisories |
| 🚨 Incident Reporting (Art. 23.2) | GitHub Security Dashboard + AWS CloudWatch + CloudFront access logs | Real-time | ENISA 24h notification prep via ISMS incident response | SECURITY.md + Incident Response Plan |
| 📊 Security Posture Tracking (Art. 23.3) | OpenSSF Scorecard + Lighthouse CI + uptime monitoring | Weekly/Daily | Score decline investigation via automated alerts | OpenSSF Scorecard |
| 🔄 Update Distribution (Art. 23.4) | Automated GitHub releases + dual deployment (S3 + GitHub Pages) + CI/CD pipeline | As needed | Critical vulnerability patches via secure CI/CD pipeline | Release Management + WORKFLOWS.md |
📋 CRA Reporting Readiness: Documentation and procedures prepared for ENISA incident reporting per 🚨 Incident Response Plan
🔗 ISMS Monitoring Integration:
- 📊 Continuous Monitoring: Security Metrics Framework
- 🌐 Transparency Strategy: ISMS Transparency Plan
- 🤝 Third-Party Management: Supplier Monitoring
- ✅ Compliance Tracking: Regulatory Adherence
- 💾 Data Protection: Backup and Recovery
Supports CRA Article 28 - EU Declaration of Conformity
🏢 Manufacturer: Hack23 AB, Gothenburg, Sweden 📦 Product: Riksdagsmonitor v0.4.1 📋 CRA Compliance: Self-assessment documentation supporting CRA essential cybersecurity requirements evaluation 🔍 Assessment: Self-assessment documentation per Article 24 (non-commercial OSS with standard classification) 📊 Standards: ISO/IEC 27001 security framework + OWASP web security guidelines + NIST SSDF secure development
📅 Date & Signature: 2026-02-24 — James Sörling, CEO Hack23 AB
📂 Technical Documentation: This assessment + evidence bundle supports CRA Annex V technical documentation requirements
Supports CRA Article 16 - Quality Management System Documentation
Overall CRA Documentation Status: EVIDENCE_DOCUMENTED
Key CRA Documentation Areas:
- ✅ Annex I essential requirements documented with comprehensive evidence links
- ✅ Annex V technical documentation comprehensively structured
- ✅ Article 11 security measures implemented and documented
- ✅ Article 23 post-market surveillance procedures operational
Static Site Security Advantage: Riksdagsmonitor's static site architecture provides inherent security benefits:
- No server-side code execution (eliminates SQL injection, RCE, SSRF)
- No user authentication/session management (eliminates authentication bypass, session hijacking)
- No database (eliminates data breach risks)
- No cookies/tracking (GDPR compliant by design)
- CDN-distributed content (inherent DDoS resilience)
| 👤 Role | 📝 Name | 📅 Date | ✍️ Assessment Attestation |
|---|---|---|---|
| 🔒 CRA Security Assessment | James Sörling | 2026-02-24 | Essential requirements documented with comprehensive evidence |
| 🎯 Product Responsibility | James Sörling | 2026-02-24 | Technical documentation complete and publicly accessible |
| ⚖️ Legal Compliance Review | James Sörling | 2026-02-24 | EU regulatory documentation requirements satisfied |
📊 CRA Assessment Status: SELF_ASSESSMENT_DOCUMENTED
Per CRA Article 15 - Substantial Modification
CRA assessment updated only when changes constitute "substantial modification" under CRA:
- 🏗️ Security Architecture Changes: New trust boundaries, encryption, or deployment topology
- 🛡️ Essential Requirement Impact: Changes affecting Annex I compliance
- 📦 Critical Dependencies: New supply chain components with security implications (e.g., new CDN libraries)
- 🔍 Risk Profile Changes: New threats or vulnerability classes affecting political data integrity
- ⚖️ Regulatory Updates: CRA implementing acts or guidance changes
🎯 Maintenance Principle: Assessment stability preferred — avoid routine updates that don't impact CRA compliance
- Article 6: Scope determination → Section 2 (CRA Classification)
- Article 11: Essential cybersecurity requirements → Section 5 (Requirements Assessment)
- Article 19: Conformity assessment → Section 6 (Evidence Documentation)
- Article 23: Post-market obligations → Section 7 (Surveillance Documentation)
- Article 28: Declaration of conformity → Section 8 (DoC Template)
- Annex I: Technical requirements → Section 5 (Requirements self-assessment mapping)
- Annex V: Technical documentation → Complete template structure
- 🔄 Operational Continuity: CRA self-assessment integrated with existing security operations
- 📊 Evidence Reuse: Security metrics and monitoring serve dual ISMS/CRA documentation purposes
- 🎯 Business Value: CRA readiness demonstrates cybersecurity consulting expertise
- 🤝 Client Confidence: Transparent self-assessment showcases professional implementation methodology
- 🔐 Information Security Policy — Overall security governance
- 🏷️ Classification Framework — Data and asset classification
- 🌐 ISMS Transparency Plan — Public disclosure strategy
- 🔒 Cryptography Policy — Encryption standards, TLS configuration
- 🔑 Access Control Policy — Identity management, repository access
- 🌐 Network Security Policy — HTTPS-only, CDN security
- 🏷️ Data Classification Policy — Public political data handling
- 🛠️ Secure Development Policy — SDLC security, testing requirements
- 📝 Change Management — Controlled modification procedures
- 🔍 Vulnerability Management — Security testing, coordinated disclosure
- 🤝 Third Party Management — Supplier risk assessment
- 🔓 Open Source Policy — OSS governance, license compliance
- 🛡️ CRA Conformity Assessment Process — CRA self-assessment template and methodology
- 🚨 Incident Response Plan — Security event handling
- 🔄 Business Continuity Plan — Business resilience
- 🆘 Disaster Recovery Plan — Technical recovery procedures
- 💾 Backup Recovery Policy — Data protection and backup
- 📊 Security Metrics — KPI tracking, continuous improvement
- 💻 Asset Register — Asset inventory with risk classifications
- 📉 Risk Register — Risk identification, assessment, treatment
- 📊 Risk Assessment Methodology — Systematic risk evaluation
- ✅ Compliance Checklist — Regulatory requirement tracking
Demonstrating compliance with Hack23 AB Open Source Policy
| Requirement | Status | Evidence |
|---|---|---|
| OpenSSF Scorecard ≥7.0 | ✅ Active | |
| Quality Gate Passed | ✅ Active | Quality Checks Workflow |
| License Badge | ✅ Active |  |
| Threat Model Published | ✅ Active |  |
| STRIDE Analysis Complete | ✅ Active |  |
| Required Artifact | Status | Evidence |
|---|---|---|
| SECURITY_ARCHITECTURE.md | ✅ Present | SECURITY_ARCHITECTURE.md — Defense-in-depth with Mermaid diagrams |
| FUTURE_SECURITY_ARCHITECTURE.md | ✅ Present | FUTURE_SECURITY_ARCHITECTURE.md — Security roadmap |
| SECURITY.md | ✅ Present | SECURITY.md — Coordinated vulnerability disclosure |
| WORKFLOWS.md | ✅ Present | WORKFLOWS.md — CI/CD pipeline with security gates |
| LICENSE | ✅ Apache 2.0 | LICENSE — OSI-approved |
| CRA-ASSESSMENT.md | ✅ Present | This document |
| CODE_OF_CONDUCT.md | ✅ Present | CODE_OF_CONDUCT.md — Community standards |
| CONTRIBUTING.md | ✅ Present | CONTRIBUTING.md — Contribution guidelines |
| README.md | ✅ Present | README.md — Includes project classification section |
| Requirement | Status | Evidence |
|---|---|---|
| Supply Chain: Dependency Scanning | ✅ Automated | Dependabot Config |
| Supply Chain: SHA-pinned Actions | ✅ Enforced | WORKFLOWS.md — All Actions pinned to SHA |
| Supply Chain: step-security/harden-runner | ✅ Active | Egress auditing on all workflows |
| Vulnerability Management SLA | ✅ Active | SECURITY.md — Coordinated disclosure + Dependabot auto-remediation |
| SAST: CodeQL | ✅ Active | CodeQL Workflow |
| SCA: Dependency Review | ✅ Active | Dependency Review Workflow |
| Secret Scanning | ✅ Active | Security Overview |
| Requirement | Status | Evidence |
|---|---|---|
| Primary License: Apache 2.0 | ✅ Approved (Permissive) | LICENSE |
| Dependencies: Permissive Licenses | ✅ All permissive | npm dependencies under MIT/ISC/Apache 2.0/BSD |
| No Prohibited Licenses | ✅ Verified | No AGPL/GPL/advertising-clause licenses in dependency tree |
| Requirement | Status | Evidence |
|---|---|---|
| CIA Triad Classification | ✅ Declared | Public / High Integrity / High Availability |
| Business Impact Assessment | ✅ Documented | SWOT.md + CRA Risk Assessment |
| RTO/RPO Objectives | ✅ Defined | RTO: <24h (Medium) / RPO: <24h (Daily) |
| Requirement | Status | Evidence |
|---|---|---|
| No PII/GDPR data | ✅ Compliant | No personal data collection — static site, no user accounts |
| No production credentials | ✅ Compliant | GitHub secret scanning active |
| Public data only | ✅ Compliant | All data sourced from public government APIs |
| Requirement | Status | Evidence |
|---|---|---|
| Contribution guidelines | ✅ Published | CONTRIBUTING.md |
| Code of Conduct | ✅ Published | CODE_OF_CONDUCT.md |
| PR review process | ✅ Active | Branch protection + required reviews |
Demonstrating compliance with Hack23 AB CRA Conformity Assessment Process
| Process Step | Template Section | Status | Riksdagsmonitor Evidence |
|---|---|---|---|
| 1️⃣ Project Identification | CRA Annex V §1 | ✅ Complete | Section 1 — Product description, badges, data sources |
| 2️⃣ CRA Scope & Classification | CRA Art. 6-7 | ✅ Complete | Section 2 — Non-commercial OSS, Standard, Community distribution |
| 3️⃣ Technical Documentation | CRA Annex V §2 | ✅ Complete | Section 3 — 9 CRA technical areas documented with evidence links |
| 4️⃣ Risk Assessment | CRA Annex V §3 | ✅ Complete | Section 4 — 6 risk categories assessed with residual risk |
| 5️⃣ Essential Requirements | CRA Annex I | ✅ Complete | Section 5 — 13 essential requirements mapped |
| 6️⃣ Conformity Evidence | CRA Art. 19 | ✅ Complete | Section 6 — Badges, CI/CD evidence, release artifacts |
| 7️⃣ Post-Market Surveillance | CRA Art. 23 | ✅ Complete | Section 7 — Monitoring, reporting, update mechanisms |
| 8️⃣ Declaration of Conformity | CRA Art. 28 | ✅ Draft | Section 8 — DoC template ready for formal placement |
| 9️⃣ Assessment Approval | Internal | ✅ Complete | Section 9 — CEO approval documented |
| Classification Dimension | Selected Value | Justification |
|---|---|---|
| 🏪 Market Category |  |
Apache 2.0 licensed, freely available on GitHub |
| 🛡️ Confidentiality |  |
All data from public government sources |
| ✅ Integrity |  |
Political data accuracy is essential for democratic trust |
| ⏱️ Availability |  |
99.998% design availability (AWS CloudFront multi-region + GitHub Pages DR), automated failover |
| 🕐 RTO | -lightgreen?style=flat-square){kind=icon} |
GitHub Pages DR available within hours |
| 🔄 RPO | -lightblue?style=flat-square){kind=icon} |
Git-based continuous backup, daily content generation |
| 🏢 CRA Applicability |  |
Volunteer-driven, no revenue model |
| 🌐 Distribution |  |
GitHub public repository |
| 📋 CRA Classification |  |
Not in Annex III/IV critical categories |
This section provides a systematic mapping of all 13 essential cybersecurity requirements from CRA Annex I, Part I to Riksdagsmonitor implementations.
| Req # | Annex I Requirement | Riksdagsmonitor Implementation | Evidence | Compliance Status |
|---|---|---|---|---|
| 1 | Products with digital elements shall be designed, developed and produced with appropriate security, considering the risks during development | Static HTML/CSS/JS architecture eliminates server-side attack surface. Secure development lifecycle with threat modeling (THREAT_MODEL.md), security architecture (SECURITY_ARCHITECTURE.md), and annual security reviews | THREAT_MODEL.md, SECURITY_ARCHITECTURE.md, GitHub CodeQL scan results | COMPLIANT |
| 2 | Products shall be delivered without known exploitable vulnerabilities | Dependabot automated vulnerability scanning, npm audit in CI/CD, CodeQL SAST analysis, no known CVEs in production dependencies. Pre-deployment security gate in GitHub Actions | GitHub Security tab - 0 open critical/high alerts, npm audit reports in CI logs | COMPLIANT |
| 3 | Products shall have secure by default configurations, including possibility to reset to factory settings | No configuration required by end users. Static site has no user-configurable settings. TLS 1.3 enforced by GitHub Pages/CloudFront. CSP headers set by default | GitHub Pages HTTPS enforcement, CloudFront TLS policy, HTTP response headers | COMPLIANT |
| 4 | Products shall protect against unauthorized access through appropriate access control mechanisms | Repository protected by GitHub authentication and branch protection rules. No public write access. Least privilege permissions in GitHub Actions workflows. GitHub Secrets for credential storage | GitHub branch protection settings, workflow permissions YAML, GitHub Actions audit log | COMPLIANT |
| 5 | Products shall protect the confidentiality of data by appropriate means including encryption of data at rest and in transit | All data in transit protected by TLS 1.3 enforced via GitHub Pages and CloudFront. No sensitive data at rest (all content is public political data). No PII collected or processed | CloudFront TLS 1.3 configuration, HSTS headers, no-cookie policy | COMPLIANT |
| 6 | Products shall protect the integrity of data in transit and stored data against manipulation | SLSA provenance attestation (Level 2+), Sigstore signing, Git commit signatures, GitHub content integrity guarantees. Article-level SHA-256 planned Q3 2026 | SLSA attestation in GitHub Actions, Sigstore transparency log, Git commit signature verification, GitHub repository content integrity documentation | COMPLIANT |
| 7 | Products shall process only data, both personal and other, that is adequate, relevant and limited to what is necessary | Zero PII collected. Platform processes only publicly available Riksdag political data. No analytics cookies. No user tracking. Data minimization by design | Privacy policy (no-cookie design), source code review showing no PII collection | COMPLIANT |
| 8 | Products shall protect the availability of essential functions including protection against denial of service attacks | AWS CloudFront CDN with DDoS protection at edge. GitHub Pages provides secondary availability. Route 53 health-check-based failover. 99.998% availability target | CloudFront Shield Standard coverage, BCPPlan.md, dual-deployment architecture | COMPLIANT |
| 9 | Products shall minimize the negative impact on the availability of services provided by other devices or networks | Static site generates no outbound network calls from user browsers beyond CDN. MCP pipeline calls are server-side in GitHub Actions (controlled, rate-limited) | Source code showing no user-browser-initiated external calls, rate limiting in MCP client | COMPLIANT |
| 10 | Products shall be designed, developed and produced to limit attack surfaces, including external interfaces | Attack surface minimized: no database, no server-side code, no user input forms, no cookies. Only surfaces: HTTPS static file serving, GitHub API (authenticated). No exposed ports | Architecture.md showing static-only design, no open ports analysis | COMPLIANT |
| 11 | Products shall be designed, developed and produced to reduce the impact of an incident including through appropriate mechanisms for resilience | Automatic failover (CloudFront origin failover <30s, DNS failover <15min). Complete Git history for rollback. Incident response procedures in BCPPlan.md and ISMS. No persistent state to lose | BCPPlan.md dual-deployment, RTO metrics, Git rollback capability | COMPLIANT |
| 12 | Products shall record and/or monitor relevant internal activities in order to detect and investigate cybersecurity incidents | GitHub Actions audit logs, CloudFront access logs, GitHub Security alerts, OpenSSF Scorecard monitoring, automated Dependabot alerts. step-security/harden-runner egress monitoring | GitHub Audit Log API, CloudFront log groups, Security tab alert history | COMPLIANT |
| 13 | Products shall ensure that vulnerabilities can be addressed through security updates including, where technically possible, automatic updates | Dependabot automated PRs for dependency updates. GitHub Actions automated vulnerability notifications. Security contact (security@hack23.com) for coordinated disclosure. SECURITY.md outlines update process | Dependabot configuration, SECURITY.md, coordinated disclosure policy | COMPLIANT |
| Req # | Annex I Part II Requirement | Riksdagsmonitor Implementation | Evidence | Compliance Status |
|---|---|---|---|---|
| 1 | Identify and document vulnerabilities and components contained in the product, including by drawing up a software bill of materials | npm package-lock.json provides complete dependency graph. Dependabot monitors all dependencies. SBOM generation planned for 2027 via GitHub SBOM feature | package-lock.json, npm audit output, Dependabot alerts | PARTIAL — SBOM automation planned 2027 |
| 2 | Address vulnerabilities without delay including by providing security updates | Critical: <7 days. High: <30 days. Medium: <90 days. Dependabot auto-PRs for patch releases. Manual review for major version upgrades | Dependabot configuration, vulnerability management in ISMS, MTTP metrics | COMPLIANT |
| 3 | Apply effective and regular testing and reviews of the security of products with digital elements | CodeQL SAST on every PR and commit. Dependabot daily scans. Quarterly threat model review. Annual security architecture review. OpenSSF Scorecard monthly | GitHub Actions security scan results, CodeQL alerts, Scorecard history | COMPLIANT |
| 4 | After becoming aware of a vulnerability, share information about it with ENISA without undue delay | ENISA reporting procedure: notify via security@hack23.com internal triage, then report to ENISA vulnerability database within 72 hours for critical issues | ISMS Incident Response Plan, coordinated disclosure procedure | COMPLIANT — procedure documented |
| 5 | Establish and document a coordinated vulnerability disclosure policy | SECURITY.md contains full coordinated vulnerability disclosure policy. security@hack23.com for reporting. 90-day disclosure timeline. Response SLA: acknowledge within 5 business days | SECURITY.md public policy | COMPLIANT |
| 6 | Take measures to facilitate the sharing of information about vulnerabilities in the product | Public GitHub Security Advisories for all confirmed vulnerabilities. SECURITY.md disclosure policy. GitHub private vulnerability reporting enabled | GitHub Security Advisories tab, SECURITY.md | COMPLIANT |
| 7 | Provide for a mechanism for coordinating the vulnerability disclosure process with other manufacturers or security researchers | security@hack23.com receives all vulnerability reports. GitHub private vulnerability reporting. Coordinated disclosure gives reporters credit. No retaliation policy | SECURITY.md safe harbor clause | COMPLIANT |
| 8 | As long as products are supported, make available without delay security updates to address vulnerabilities | Immediate security updates for critical vulnerabilities. Automated Dependabot PRs for all vulnerable dependencies. Auto-merge configured for patch-level security updates | Dependabot auto-merge configuration, security update history | COMPLIANT |
Assessment Method: Self-Assessment (Module A - Internal Production Control)
Riksdagsmonitor qualifies for self-assessment under CRA Article 32(1) as it is:
- A standard product with digital elements (not critical or important category per Annex III/IV)
- Non-commercial open-source software distributed publicly without charge
- A civic transparency tool with low risk profile (no safety functions, no critical infrastructure)
Self-Assessment Process:
- Technical Documentation (CRA Annex V): Complete — this document and linked ISMS documents
- Design and Development Assessment: Complete — THREAT_MODEL.md, SECURITY_ARCHITECTURE.md
- Production Controls: Complete — CI/CD pipeline with security gates documented in WORKFLOWS.md
- Conformity Declaration: Template in Section 8 of this document
- CE Marking: Applicable upon formal EU market placement (currently pre-commercial)
Assessment Conclusion:
| CRA Area | Requirements | Compliant | Partial | Non-Compliant |
|---|---|---|---|---|
| Annex I Part I | 13 | 13 | 0 | 0 |
| Annex I Part II | 8 | 7 | 1 | 0 |
| Annex V Documentation | Complete | Yes | — | — |
| Vulnerability Handling | Policy exists | Yes | — | — |
| Overall | 21 | 20 | 1 | 0 |
Open Item: SBOM automation (Annex I Part II Req 1) — planned Q1 2027 via GitHub SBOM generation feature.
This section provides a forward-looking readiness checklist for when Riksdagsmonitor formally enters EU market distribution as a commercial product.
| Area | Requirement | Current Readiness | Action Required | Target Date |
|---|---|---|---|---|
| Technical Documentation | CRA Annex V complete documentation | 95% complete | Finalize SBOM generation | Q1 2027 |
| Conformity Assessment | Self-assessment completed and documented | 90% complete | Formal declaration of conformity | Q2 2027 |
| Vulnerability Handling Policy | Published and accessible | 100% | None - SECURITY.md complete | Done |
| Security Update Process | Documented and operational | 100% | None - Dependabot + MTTP policy | Done |
| Coordinated Disclosure | Policy and contact established | 100% | None - security@hack23.com | Done |
| CE Marking | Required for EU market products | Not yet | Apply after conformity assessment | 2027 |
| ENISA Reporting | Incident reporting procedure | 85% | Document ENISA contact and timeline | Q2 2026 |
| SBOM | Software Bill of Materials | Partial | Implement GitHub SBOM generation | Q1 2027 |
| Post-Market Surveillance | Ongoing monitoring plan | 80% | Formalize surveillance process doc | Q3 2026 |
flowchart LR
VULN_DISCOVERED[Vulnerability Discovered] --> ASSESS[Severity Assessment]
ASSESS --> CRITICAL{Critical CVSS 9+?}
CRITICAL -->|Yes| PATCH_7[Patch within 7 days]
CRITICAL -->|No| HIGH{High CVSS 7-8.9?}
HIGH -->|Yes| PATCH_30[Patch within 30 days]
HIGH -->|No| MED{Medium CVSS 4-6.9?}
MED -->|Yes| PATCH_90[Patch within 90 days]
MED -->|No| PATCH_SCHED[Patch in next release]
PATCH_7 --> DEPLOY[Deploy Security Update]
PATCH_30 --> DEPLOY
PATCH_90 --> DEPLOY
PATCH_SCHED --> DEPLOY
DEPLOY --> NOTIFY[Notify via SECURITY.md Advisory]
NOTIFY --> ENISA_CHECK{Significant incident?}
ENISA_CHECK -->|Yes| ENISA_REPORT[Report to ENISA within 24h]
ENISA_CHECK -->|No| CLOSE[Close Vulnerability Record]
ENISA_REPORT --> CLOSE
| Obligation | Article | Implementation | Status |
|---|---|---|---|
| Design and produce with appropriate cybersecurity | 13(1) | Secure SDLC, STRIDE threat modeling | Done |
| Deliver without known exploitable vulnerabilities | 13(2) | Dependabot, npm audit, CodeQL pre-deploy | Done |
| Perform vulnerability assessment | 13(3) | Quarterly threat model review | Done |
| Apply security updates without undue delay | 13(4) | Dependabot auto-merge, MTTP policy | Done |
| Ensure security for expected lifetime | 13(5) | Lifecycle support policy documented | Done |
| Set support period in declaration of conformity | 13(6) | Support period: 5 years from last release | Planned |
| Provide security updates for support period | 13(7) | Dependabot + manual review ongoing | Done |
| Notify ENISA of actively exploited vulnerabilities | 13(8) | ENISA procedure in IR Plan | Done |
| Provide technical documentation | 13(14) | CRA-ASSESSMENT.md + SECURITY_ARCHITECTURE.md | Done |
| Affix CE marking | 13(15) | Not yet - required for market placement | Planned |
| Draw up EU declaration of conformity | 13(16) | Template exists - formal sign-off pending | Planned |
Active Exploitation Reporting (Article 14(2)):
- Notification timeline: Within 24 hours of becoming aware
- Recipient: ENISA Early Warning notification system
- Content: Product identification, vulnerability description, known exploited instances
- Contact: security@hack23.com (internal) → ENISA online notification form
Severe Incident Reporting (Article 14(3)):
- Notification timeline: Within 72 hours of detection
- Recipient: Competent market surveillance authority (MSA) and ENISA
- For Sweden: Swedish Post and Telecom Authority (PTS) as likely MSA
- Content: Detailed incident report including impact, affected versions, remediation
User Notification (Article 14(8)):
- If security update available: Notify users via GitHub Security Advisories
- If vulnerability affects user security: Post advisory on riksdagsmonitor.com
- Update README.md security section for significant vulnerabilities
Riksdagsmonitor must be evaluated against CRA's product classification system to determine the applicable conformity assessment route:
CRA Annex III — Important Products with Digital Elements (Class I):
| Category | Riksdagsmonitor Assessment |
|---|---|
| Identity management software | Not applicable |
| Password managers | Not applicable |
| Browsers | Not applicable |
| Operating systems | Not applicable |
| VPNs | Not applicable |
| Network management software | Not applicable |
| Firewalls | Not applicable |
| Intrusion detection systems | Not applicable |
| Microcontrollers | Not applicable |
| Consumer IoT | Not applicable |
Conclusion: Riksdagsmonitor does not qualify as a Class I Important Product under Annex III.
CRA Annex IV — Critical Products with Digital Elements (Class II):
| Category | Riksdagsmonitor Assessment |
|---|---|
| Critical infrastructure software | Not applicable - civic transparency platform |
| HSMs / Secure elements | Not applicable |
| Smart meters | Not applicable |
| Industrial control systems | Not applicable |
Conclusion: Riksdagsmonitor does not qualify as a Class II Critical Product under Annex IV.
Final Classification: Standard Product with Digital Elements — eligible for Module A Self-Assessment
Riksdagsmonitor benefits from the CRA open source carve-out provisions:
| CRA Provision | Application to Riksdagsmonitor |
|---|---|
| Non-commercial OSS exemption (Recital 18) | Riksdagsmonitor is freely available, non-commercial, no revenue model |
| Commercial distribution triggers CRA (Art. 16(1)) | If Riksdagsmonitor is commercialized (API subscriptions), CRA obligations apply in full |
| Steward provisions | Hack23 AB acts as open source steward |
| Vulnerability handling (Art. 16(2)) | Security policy (SECURITY.md) and coordinated disclosure required even for OSS |
| Security advisories | Public security advisories for known vulnerabilities |
Compliance Strategy: Maintain full CRA technical documentation now, enabling smooth transition to formal commercial compliance when API tier launches in 2027.
The following template will be formalized upon entry into EU commercial distribution:
EU DECLARATION OF CONFORMITY
Riksdagsmonitor - Version [X.Y]
Hack23 AB (Org.nr 5595347807)
Sweden
This declaration of conformity is issued under the sole responsibility
of the manufacturer.
Product: Riksdagsmonitor - Swedish Parliamentary Transparency Platform
Version: [X.Y]
Description: Web-based civic technology platform providing access to
Swedish Riksdag parliamentary data, voting records, and AI-generated
political news in 14 languages.
Conformity Assessment Method: Module A (Self-Assessment)
Product Category: Standard product with digital elements
Annex III/IV Category: Not applicable
The object of the declaration described above is in conformity with
the relevant Union harmonisation legislation:
Regulation (EU) 2024/2847 - Cyber Resilience Act
- Annex I Part I: Essential cybersecurity requirements (13/13 compliant)
- Annex I Part II: Vulnerability handling requirements (7/8 compliant)
- Annex V: Technical documentation available at:
github.com/Hack23/riksdagsmonitor/blob/main/CRA-ASSESSMENT.md
Signed for and on behalf of: James Pether Sorling, CEO
Date: [To be completed upon formal market placement]
Place: Sweden
📋 Document Control:
✅ Approved by: James Pether Sörling, CEO
📤 Distribution: Public
🏷️ Classification: 
