Evidence-Driven Conformity Through Systematic Assessment
Demonstrating CRA Compliance Excellence for Cybersecurity Consulting
Document Owner: CEO | Version: 1.1.59 | Last Updated: 2026-04-28 Review Cycle: Quarterly | Next Review: 2026-07-21
Hack23 AB's CRA conformity assessment process demonstrates how systematic regulatory compliance directly enables business growth rather than creating operational burden. Our comprehensive assessment framework serves as both operational tool and client demonstration of our cybersecurity consulting methodologies.
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.
Our commitment to transparency means our conformity assessment practices become a reference implementation, showing how comprehensive regulatory compliance enables business expansion while protecting organizational interests and maintaining stakeholder trust.
— James Pether Sörling, CEO/Founder
This process provides a concise, repeatable CRA Conformity Assessment format (pre‑market & ongoing) for the three initial products (CIA, Black Trigram, CIA Compliance Manager). Aligns with CRA Annex I & V, Hack23 classification, secure development, and transparency policies.
Scope: All products within Asset Register requiring EU market placement.
Copy this entire template into CRA-ASSESSMENT.md in your project root. Replace all {{PLACEHOLDERS}}, remove unused badge options, tick checkboxes, and commit with project changes when security posture materially changes.
Evidence Integration: All evidence (SBOM, provenance, test reports) stored in GitHub release artifacts and repository documentation. Assessment references current project state and links to immutable evidence.
CRA Regulation Alignment: This template supports CRA Annex V technical documentation requirements and Annex I essential requirements for cybersecurity through systematic self-assessment.
The following Hack23 AB projects demonstrate completed CRA assessments using this template:
| 🚀 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 atts game | Standard (Non-commercial OSS) | ✅ Complete | 📄 CRA Assessment |
| 🛡️ CIA Compliance Manager | Compliance automation tool | Standard (Non-commercial OSS) | ✅ Complete | 📄 CRA Assessment |
📝 Common Template Usage Patterns:
- 🔍 Classification: Each reference shows different market categories and CIA classification levels
- 🛡️ Security Controls: Demonstrates technical documentation across various product types
- 📊 Evidence Links: Examples of GitHub release attestations and ISMS policy integration
- ⚖️ Risk Assessment: Different risk profiles for transparency, security, and compliance tools
🔗 Evidence Repository Structure: All reference implementations follow the standardized evidence pattern:
- 📦 GitHub Releases: SBOM, SLSA attestations, and provenance documentation
- 🛡️ Security Policies: Direct links to ISMS framework policies and procedures
- 📊 Compliance Badges: OpenSSF Scorecard, CII Best Practices, and FOSSA license compliance
- 🚨 Vulnerability Disclosure: Standardized
SECURITY.mdand coordinated disclosure processes
💡 Usage Tips:
- Start with Classification: Use reference implementations with similar CIA levels as templates
- Evidence Alignment: Follow the GitHub attestations pattern from existing assessments
- Risk Context: Adapt risk assessments based on similar product complexity
- ISMS Integration: Reference implementations show policy linkage patterns for different product types
Supports CRA Annex V § 1 - Product Description Requirements
| Field | Value |
|---|---|
| 📦 Product | CIA Compliance Manager |
| 🏷️ Version Tag | {{CURRENT_VERSION}} |
| 🔗 Repository | https://github.com/Hack23/cia-compliance-manager |
| 📧 Security Contact | security@hack23.org |
| 🎯 Purpose (1–2 lines) | Open source toolkit to assess, map, and communicate security posture, business impact, and compliance alignment across the CIA triad. |
| 🏪 Market | Open Source (non‑commercial) |
| Aspect | Selected Value | Rationale |
|---|---|---|
| Market Category |  |
Public, collaborative development; no revenue generation currently. |
| Confidentiality |  |
All source and docs intentionally public. |
| Integrity |  |
Incorrect data impacts decisions but not safety‑critical. |
| Availability |  |
Outages acceptable; no real‑time obligations. |
| RTO |  |
Recovery can be scheduled without business loss. |
| RPO | -lightblue?style=flat-square>) | Daily backups / git history sufficient. |
Supports CRA Article 6 - Scope and Article 7 - Product Classification Assessment
| Applicability | Distribution | CRA Classification |
|---|---|---|
 |
 |
 |
📝 CRA Scope Justification: Distributed as non-commercial open source (no revenue). Provides decision support (assessment, visualization) only; no embedded privileged execution or safety-critical control. Standard CRA product self-assessment is appropriate.
🔍 Classification Impact:
- Standard: Self-assessment approach (this template supports documentation)
- Class I/II: Notified body assessment required + additional documentation
Supports CRA Annex V § 2 - Technical Documentation Requirements
| CRA Technical Area | Status | Implementation Summary | Evidence (Direct Links) |
|---|---|---|---|
| 🎨 Product Architecture (Annex V § 2.1) |  |
High‑level data & trust boundaries documented | ARCHITECTURE.md · SECURITY_ARCHITECTURE.md · WORKFLOWS.md |
| 📦 SBOM & Components (Annex I § 1.1) | |
Complete dependency enumeration per build | Latest Release (SBOM) (SPDX + signed) |
| 🔐 Cybersecurity Controls (Annex I § 1.2) | |
Authn, authz, encryption policies & control baseline | Access Control Policy · Cryptography Policy |
| 🛡️ Supply Chain Security (Annex I § 1.3) | |
Signed builds + provenance attestations | Attestations · Release SBOM assets |
| 🔄 Update Mechanism (Annex I § 1.4) | |
Controlled updates with provenance + rollback capability | Change Management · Latest Release |
| 📊 Security Monitoring (Annex I § 1.5) |  |
Logging & incident handling defined; expanded runtime telemetry planned | Incident Response Plan · Security Metrics |
| 🏷️ Data Protection (Annex I § 2.1) | |
Classification & handling controls (public data only) | Data Classification Policy |
| 📚 User Guidance (Annex I § 2.2) |  |
Security configuration guide to be published | (Planned) Will live in docs/USER_SECURITY_GUIDE.md (not yet committed) |
| 🔍 Vulnerability Disclosure (Annex I § 2.3) | |
Coordinated vulnerability disclosure process | SECURITY.md · Vulnerability Management |
| ♿ Accessibility (v1.1.0) | |
WCAG 2.1 AA compliance, ARIA, keyboard navigation, screen reader support | ACCESSIBILITY_COMPLIANCE.md · ACCESSIBILITY_REPORT.md |
| ⚡ Performance (v1.1.0) | |
Bundle optimization (85.6% reduction), lazy loading, Core Web Vitals | PERFORMANCE_COMPLIANCE.md · performance-testing.md |
| 🛡️ Error Handling (v1.1.0) | |
React Error Boundaries (11/11 widgets), graceful degradation | ERROR_HANDLING.md · WidgetErrorHandlingGuide.md |
| 🎨 Design System (v1.1.0) | |
Centralized design tokens, consistent UI patterns, TailwindCSS | DESIGN_SYSTEM.md · DESIGN_SYSTEM_IMPLEMENTATION_GUIDE.md |
| 📋 Compliance Evidence (v1.1.0) | |
Consolidated evidence catalog with 8 categories, 40+ artifacts | COMPLIANCE_EVIDENCE.md |
Legend:
Note: User Security Guide intentionally marked Planned; no USER_SECURITY_GUIDE.md exists yet (kept within current gap management without adding a new GAP item).
📋 ISMS Policy Integration:
- 🏗️ Architecture & Design: Implementation aligned with 🔐 Information Security Policy
- 📦 Asset Management: All components documented in 💻 Asset Register
- 🔒 Encryption Standards: Cryptographic requirements per 🔒 Cryptography Policy
- 🌐 Network Security: Infrastructure controls via 🌐 Network Security Policy
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 | M | H/H/M | SBOM + SLSA provenance + dependency pinning | L | GitHub attestations |
| Unauthorized Access (Art. 11) | Authentication | M | H/H/H | MFA + secret scanning + short-lived tokens | L | Access control logs |
| Data Breach (Art. 11) | Data storage | L | H/H/H | Encryption + IAM + least privilege | L | KMS configuration |
| Component Vulnerability (Art. 11) | Dependencies | M | M/H/M | SCA scanning + patch management | L | Vulnerability reports |
| Service Disruption (Art. 11) | Public services | M | L/M/H | WAF + DDoS protection + scaling | M | Infrastructure config |
⚖️ CRA Risk Statement: LOW - Assessment supports CRA essential cybersecurity requirements evaluation
✅ Risk Acceptance: James Pether Sörling (CEO) - 2025-08-22
📋 Risk Management Framework:
- 📊 Methodology: Risk assessment per 📊 Risk Assessment Methodology
⚠️ Risk Tracking: All risks documented in⚠️ Risk Register- 🔄 Business Impact: Continuity planning via 🔄 Business Continuity Plan
- 🆘 Recovery Planning: Technical recovery per 🆘 Disaster Recovery Plan
Supports CRA Annex I - Essential Requirements Self-Assessment
| CRA Annex I Requirement | Status | Evidence (Badges / Links) |
|---|---|---|
| 🛡️ § 1.1 - Secure by Design |  |
Architecture & trust boundaries (docs/architecture/), 🛠️ Secure Development Policy, minimal surface principles documented. Pending: Threat model appendix (GAP-01). |
| 🔒 § 1.2 - Secure by Default |  |
Baseline hardening checklist not yet published (GAP-02). Config defaults governed by 🛠️ Secure Development Policy. |
| 🏷️ § 2.1 - Personal Data Protection |  |
🏷️ Data Classification Policy + classification applied (public data only). |
| 🔍 § 2.2 - Vulnerability Disclosure | |
SECURITY.md + |
| 📦 § 2.3 - Software Bill of Materials | |
Automated SBOM (SPDX) in Latest Release (signed) + attested (*.spdx.json). |
| 🔐 § 2.4 - Secure Updates | |
Signed build + provenance attestations (SLSA) + 📝 Change Management. |
| 📊 § 2.5 - Security Monitoring | |
Detection & response via 🚨 Incident Response Plan + posture metrics (📊 Security Metrics). Planned: Expanded monitoring coverage baseline. |
| 📚 § 2.6 - Security Documentation | |
User/security guidance (docs/, portal) + public ISMS policies (listed below). |
Legend:
Open Gaps Referenced: GAP-01 (Threat model appendix), GAP-02 (Secure-by-default checklist) — see Section 9 for schedule.
🎯 CRA Self-Assessment Status: IN_PROGRESS
🔍 Standard Security Reporting Process:
Each project includes standardized security reporting via SECURITY.md following coordinated vulnerability disclosure:
- 📧 Private Reporting: GitHub Security Advisories for confidential disclosure
- ⏱️ Response Timeline: 48h acknowledgment, 7d validation, 30d resolution
- 🏆 Recognition Program: Public acknowledgment unless anonymity requested
- 🔄 Continuous Support: Latest version maintained with security updates
- 📋 Vulnerability Scope: Authentication bypass, injection attacks, remote code execution, data exposure
ISMS Integration: All vulnerability reports processed through
Supports CRA Article 19 - Conformity Assessment Documentation
Reference: 🛠️ Secure Development Policy
| Control | Requirement | Status | Evidence (Badges / Links) |
|---|---|---|---|
| 🧪 Unit Testing | ≥80% line, ≥70% branch | Active |   |
| 🌐 E2E Testing | Critical user journeys validated | Active | Included in same workflow: see CI Tests badge + E2E Plan |
| 🔍 SAST (CodeQL) | Zero critical/high vulns | Implemented |  Code Scanning Alerts |
| 📦 SCA (Dependencies) | Zero critical unresolved | Active |  Dependabot Alerts |
| 🔒 Secret Scanning | Zero exposed secrets | Active | Security Overview (GitHub native) |
| 🕷️ DAST (ZAP) | Zero exploitable high+ (on demand) | On-Demand |  |
| 📦 SBOM Generation | SPDX per release | Implemented |  (SBOM asset) |
| 🛡️ Provenance | SLSA Level 3 attestation | Implemented |  |
| 📊 Quality Gates | SonarCloud quality gate | Active | |
| 🚦 Performance Budgets | Budget file passes | Active |  budget.json |
| 🔍 Scorecards | Score >= industry baseline | Active |
Note: Some security pages (alerts, secret scanning) may require appropriate GitHub permissions to view detailed findings. All release artifacts (SBOM, attestations) are published with version {{CURRENT_VERSION}}.
Supply Chain Security
Best Practices & Governance
Quality
License Compliance
Release Integrity
SBOM + provenance attestations in release assets
| Category | Primary URL | Notes |
|---|---|---|
| SLSA Attestations | https://github.com/Hack23/cia-compliance-manager/attestations | Build & SBOM provenance |
| OpenSSF Scorecard | https://scorecard.dev/viewer/?uri=github.com/Hack23/cia-compliance-manager | Weekly automated scan |
| CII Best Practices | https://bestpractices.coreinfrastructure.org/projects/10365 | Open source maturity |
| SonarCloud (Planned) | https://sonarcloud.io/summary/new_code?id=cia-compliance-manager | Pending onboarding |
| FOSSA | https://app.fossa.io/projects/git%2Bgithub.com%2FHack23%2Fcia-compliance-manager | License & issue scan |
| Architecture Docs | ./docs/architecture/ | Design & component views |
| E2E Test Plan | ./docs/E2ETestPlan.md | Test coverage strategy |
| CI/CD Workflows | ./docs/architecture/WORKFLOWS.md | Automation overview |
🎯 Release Assets Structure:
cia-compliance-manager-{{CURRENT_VERSION}}.zip # Main application bundle
cia-compliance-manager-{{CURRENT_VERSION}}.zip.intoto.jsonl # SLSA provenance attestation
cia-compliance-manager-{{CURRENT_VERSION}}.spdx.json # SPDX SBOM
cia-compliance-manager-{{CURRENT_VERSION}}.spdx.json.intoto.jsonl # SBOM attestation
📋 Release Notes Format:
# Highlights
## 🏗️ Infrastructure & Performance
- build(deps): automated dependency updates via Dependabot
- ci: enhanced security scanning and compliance checks
- perf: performance optimizations and monitoring improvements
## 📦 Dependencies
- Complete list of dependency updates with version tracking
- Security vulnerability remediation
- License compliance verification
## 🔒 Security Compliance (Evidence Links)
- SLSA Level 3 attestations: https://github.com/Hack23/cia-compliance-manager/attestations/
- OpenSSF Scorecard: https://scorecard.dev/viewer/?uri=github.com/Hack23/cia-compliance-manager
- CII Best Practices: https://bestpractices.coreinfrastructure.org/projects/10365
- FOSSA License Scan: https://app.fossa.io/projects/git%2Bgithub.com%2FHack23%2Fcia-compliance-manager
## Contributors
Thanks to @dependabot[bot] for automated security updates!
**Full Changelog**: https://github.com/Hack23/cia-compliance-manager/compare/previous...{{CURRENT_VERSION}}🔍 Evidence Validation Commands:
# Verify SBOM in GitHub release
gh release view --repo Hack23/cia-compliance-manager --json assets
# Check SLSA attestations
gh attestation list --repo Hack23/cia-compliance-manager
# Validate security scorecard
curl -s https://api.securityscorecards.dev/projects/github.com/Hack23/cia-compliance-manager | jq '.score'
# Verify FOSSA compliance
curl -s https://app.fossa.io/api/projects/git%2Bgithub.com%2FHack23%2Fcia-compliance-manager/issues | jq '.issues | length'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) | CVE feeds + GitHub advisories | Continuous | Auto-create security issues | SCA reports |
| 🚨 Incident Reporting (Art. 23.2) | Security event detection | Real-time | ENISA 24h notification prep | Monitoring dashboards |
| 📊 Security Posture Tracking (Art. 23.3) | OpenSSF Scorecard monitoring | Weekly | Score decline investigation | Security metrics |
| 🔄 Update Distribution (Art. 23.4) | Automated security updates | As needed | Critical vulnerability patches | Release management |
📋 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
- 💾 Data Protection: Backup and recovery per 💾 Backup Recovery Policy
Supports CRA Article 28 - EU Declaration of Conformity
📝 Complete when placing product on EU market
🏢 Manufacturer: Hack23 AB, Stockholm, Sweden
📦 Product: CIA Compliance Manager {{CURRENT_VERSION}}
📋 CRA Compliance: Self-assessment documentation supporting CRA essential cybersecurity requirements evaluation
🔍 Assessment: Self-assessment documentation per Article 24 (Standard classification)
📊 Standards: Reference frameworks: OWASP ASVS, NIST SSDF, ISO/IEC 27001 (ISMS alignment)
📅 Date & Signature: 2025-08-22 - James Pether Sörling, CEO
📂 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: IN_PROGRESS
Key CRA Documentation Areas:
- ✅ Annex I essential requirements documented and assessed
- ✅ Annex V technical documentation structured
- ✅ Article 11 security measures documented
- ✅ Article 23 post-market surveillance procedures documented
Outstanding Documentation:
GAP-01: Threat model appendix → Target: 2025-09-15 (Owner: Security)
GAP-02: Secure-by-default hardening checklist → Target: 2025-09-30 (Owner: Engineering)
GAP-03: SonarCloud onboarding → Target: 2025-10-01 (Owner: Engineering)
| 👤 Role | 📝 Name | 📅 Date | ✍️ Assessment Attestation |
|---|---|---|---|
| 🔒 CRA Security Assessment | James Pether Sörling | 2025-08-22 | Essential requirements documented (gaps scheduled) |
| 🎯 Product Responsibility | James Pether Sörling | 2025-08-22 | Technical documentation baseline established |
| ⚖️ Legal Compliance Review | James Pether Sörling | 2025-08-22 | CRA scope & classification recorded |
📊 CRA Assessment Status: IN_PROGRESS
Per CRA Article 15 - Substantial Modification
CRA assessment updated only when changes constitute "substantial modification" under CRA:
- 🏗️ Security Architecture Changes: New authentication methods, trust boundaries, or encryption
- 🛡️ Essential Requirement Impact: Changes affecting Annex I compliance
- 📦 Critical Dependencies: New supply chain components with security implications
- 🔍 Risk Profile Changes: New threats or vulnerability classes
- ⚖️ Regulatory Updates: CRA implementing acts or guidance changes
🎯 Maintenance Principle: Assessment stability preferred - avoid routine updates that don't impact CRA compliance
## Current CRA Self-Assessment Evidence
**🏷️ Product Version:** {{CURRENT_VERSION}}
**📦 CRA Technical Documentation:** This assessment + [Latest Release](https://github.com/Hack23/cia-compliance-manager/releases/latest)
**🛡️ Security Attestations:** https://github.com/Hack23/cia-compliance-manager/attestations
**📊 Assessment Status:** - 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 through systematic documentation
- 🤝 Client Confidence: Transparent self-assessment approach showcases professional implementation methodology
- 🔐 Information Security Policy — Overall security governance and business value framework
- 🏷️ Classification Framework — Data and asset classification methodology with business impact analysis
- 🌐 ISMS Transparency Plan — Public disclosure strategy and stakeholder communication
- 🔒 Cryptography Policy — Encryption standards, key management, and post-quantum readiness
- 🔑 Access Control Policy — Identity management, MFA requirements, and privilege management
- 🌐 Network Security Policy — Network segmentation, firewall rules, and perimeter security
- 🏷️ Data Classification Policy — Information handling, protection levels, and retention requirements
- 🛠️ Secure Development Policy — SDLC security, testing requirements, and automation gates
- 📝 Change Management — Controlled modification procedures and release management
- 🔍 Vulnerability Management — Security testing, coordinated disclosure, and remediation
- 🤝 Third Party Management — Supplier risk assessment and ongoing monitoring
- 🔓 Open Source Policy — OSS governance, license compliance, and contribution management
- 🚨 Incident Response Plan — Security event handling, communication, and forensics
- 🔄 Business Continuity Plan — Business resilience, recovery objectives, and continuity strategies
- 🆘 Disaster Recovery Plan — Technical recovery procedures and system restoration
- 💾 Backup Recovery Policy — Data protection, backup validation, and restore procedures
- 📊 Security Metrics — KPI tracking, performance measurement, and continuous improvement
- 💻 Asset Register — Comprehensive asset inventory with risk classifications
- 📉 Risk Register — Risk identification, assessment, treatment, and monitoring
- 📊 Risk Assessment Methodology — Systematic risk evaluation framework
- ✅ Compliance Checklist — Regulatory requirement tracking and attestation
🎯 Framework Benefits for CRA Compliance:
- 🔄 Process Maturity: Established ISMS demonstrates systematic security management capabilities
- 📋 Evidence Repository: Comprehensive documentation supports CRA technical file requirements
- 🛡️ Control Effectiveness: Implemented security measures provide concrete evidence of essential requirements
- 📊 Continuous Improvement: Metrics and review cycles demonstrate ongoing security posture management
- 🤝 Stakeholder Confidence: Transparent practices showcase professional cybersecurity consulting expertise
📋 Document Control:
✅ Approved by: James Pether Sörling, CEO
📤 Distribution: Public
🏷️ Classification:
📅 Effective Date: 2025-08-23
⏰ Next Review: 2026-07-28
🎯 Framework Compliance: 
🛡️ CRA Alignment: Template supports CRA Annex V technical documentation and self-assessment requirements
📊 ISMS Integration: Comprehensive alignment with public ISMS framework for operational excellence
🌐 Documentation Portal: https://www.hack23.com/cia-compliance-manager-docs.html
⚖️ Non-Commercial Status: Open source project, currently non-commercial (subject to reassessment if classification changes)
