Skip to main content

MiCA ICT

This document provides CRYMBO’s ICT documentation to support clients registered as Crypto Asset Service Providers (CASPs) under the Markets in Crypto-Assets Regulation (MiCA). It outlines the technical, operational, and security architecture of CRYMBO’s decentralized compliance infrastructure.

1. ICT Structure Description​

CRYMBO operates on a multi-layered, modular infrastructure purpose-built for MiCA-aligned compliance:

  • On-Chain Layer: Smart contracts written in Solidity and deployed on major blockchains including Polygon and Ethereum.
  • CRYMBO Oracle: A decentralized, privacy-preserving engine built in TypeScript and deployed as containerized services. It handles identity binding, policy enforcement, and real-time KYC/KYT checks.
  • CRYMBO Connect: Developed with Node.js and NestJS, this interface layer exposes APIs, SDKs, dashboards, and wallet plugins for onboarding, monitoring, and compliance workflows.

Technology Stack:

  • Cloud Infrastructure: AWS (EC2, S3, EKS, RDS, CloudWatch, Route53)
  • Infrastructure as Code: Terraform and Helm for declarative infra deployment
  • Container Orchestration: Kubernetes (EKS), managed by ArgoCD
  • CI/CD: Bitbucket Pipelines with Docker and ECR
  • Programming Languages: TypeScript, JavaScript, Solidity
  • Databases: PostgreSQL (core compliance data), Redis (session management)
  • Monitoring: Prometheus + Grafana, Alertmanager
  • Secrets & Security: HashiCorp Vault, AWS KMS, RBAC
  • API Gateway: Managed via API gateway with JWT + OAuth2
  • Static Code Analysis: Snyk

Security features include:

  • Role-Based Access Control (RBAC)
  • End-to-end encryption (TLS 1.3 and AES-256 at rest)
  • Wallet-specific key access and scoped token permissions
  • Daily encrypted backups to isolated AWS regions

2. ICT Risk Management Policy​

CRYMBO implements a structured risk framework aligned with MiCA and DORA standards:

  • Classification of infrastructure and data assets by criticality
  • Threat modeling sessions using STRIDE methodology: STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) is a security assessment framework developed by Microsoft. CRYMBO uses STRIDE to systematically identify and evaluate threats across our smart contracts, APIs, cloud infrastructure, and compliance workflows. Each component is analyzed against these six categories to ensure comprehensive threat coverage and appropriate mitigation controls.
  • Risk prioritization is based on impact vs. likelihood scoring. We categorize risks into critical, high, medium, and low using an internal severity matrix adapted from ISO 27005.
  • Risk measurement models combine quantitative scoring (e.g., incident frequency, potential financial/regulatory impact) and qualitative input from engineering and compliance leads.

Quarterly risk assessments cover smart contract logic, cloud configurations, validator networks, and third-party integrations.

ICT Risk Management Framework​

Our risk management lifecycle includes:

  1. Identification – Via threat modeling, code reviews, and monitoring signals.
  2. Assessment – Scored against impact, likelihood, exposure scope.
  3. Mitigation – Controls implemented via Terraform, ArgoCD policies, or contract upgrades.
  4. Documentation – Risks are logged, owners assigned, and reviewed monthly.
  5. Review & Audit – Independent review semi-annually and post-incident analysis updates framework.

3. Information Security Policy​

CRYMBO enforces enterprise-grade security measures:

  • All traffic encrypted in transit with TLS 1.3; all stored data encrypted via AES-256 using AWS KMS
  • API token lifecycles are short-lived and scoped
  • 2FA is enforced for admin operations via AWS IAM and CI/CD environments
  • Static code scanning with Snyk and CodeQL during CI/CD

Security documentation and procedures are internally audited and available to clients under NDA.

4. Critical ICT Services​

Defined as business-critical for regulatory compliance:

  • Oracle Layer: Validator coordination and real-time KYC/KYT policy enforcement
  • Smart Contract Settlement: Asset transfers and event anchoring on-chain
  • Wallet Key Management APIs: Secure wallet linking and whitelisting workflows

Third-Party Vendors:

  • AWS (cloud), Cloudflare (DNS, WAF), Nominis (KYT), Bitbucket (repo + CI/CD)

All vendors are reviewed annually and governed via NDAs and data protection agreements.

5. Incident Management Procedure​

CRYMBO classifies and handles incidents via an automated system:

  • Real-time alerts via Prometheus + Alertmanager to Jira ticketing system and Slack
  • Containment protocols based on severity tiers
  • Root cause analysis and client communication within 24 hours

Detection & Response Procedures:

  • All alerts are triaged through an incident management system.
  • Severity 1 (S1) issues trigger immediate escalation to engineering leads and compliance stakeholders.
  • Affected systems are isolated or failed over depending on the blast radius.
  • Post-incident reports are completed within 48 hours with assigned action items.

Playbooks:

  • Predefined runbooks exist for: Oracle failure, validator downtime, API attack, KMS/secrets exposure, PII data risk.
  • Each includes responsible roles, tools used (Slack, internal dashboards), and fallback protocols.

SLA Handling & Regulatory Notifications:

  • SLAs are defined per client tier. Any breach triggers client alert via dashboard + email.
  • If regulated data is affected, notifications are sent within 72 hours as per GDPR/MiCA guidelines.
  • A record of all communications and response timelines is maintained for audit purposes.

Simulations are conducted quarterly and documented in our internal tracker.

6. Access Management​

Access to infrastructure and apps is strictly governed:

  • Role-based policies defined in Terraform with AWS IAM + Kubernetes RBAC
  • All admin access requires MFA and hardware token authentication
  • Logs are stored in CloudWatch and reviewed monthly
  • Immediate revocation upon termination or privilege change

7. Change and Secure Development​

CRYMBO applies DevSecOps across all environments:

  • All deployments pass through Bitbucket Pipelines -> Docker -> EKS via ArgoCD
  • Peer reviews and branch protections enforced for production code
  • Staging mirrors production and includes synthetic test flows
  • CI runs CodeQL and Snyk checks on every commit

8. Security Awareness​

Internal security program includes:

  • Quarterly training sessions on MiCA compliance, data protection, and phishing
  • Phishing simulations and red-team challenges
  • Secure development bootcamps for engineers

9. Outsourcing​

All third-party providers are:

  • Reviewed by Engineering + Legal
  • Governed by NDAs and DPAs
  • Assigned a vendor risk rating updated annually

No core infrastructure or identity data is outsourced to unvetted vendors.

10. Business Continuity Plan (BCP)​

CRYMBO’s BCP ensures rapid failover and system availability:

  • RTO: < 2 hours / RPO: < 15 minutes
  • Oracle and Connect services are deployed with cross-region failover
  • Snapshots and logs are replicated daily to a secondary AWS region

11. Audit Procedures​

Auditing includes:

  • Internal biannual policy and infra reviews
  • External penetration testing (latest: Q1 2025)
  • Access logs and anomaly reports reviewed with compliance team monthly

12. Third-Party Cybersecurity Audits​

We commission annual third-party audits that cover:

  • Smart contract audits (latest by OpenZeppelin audit partner)
  • Infrastructure scans on cloud and Kubernetes clusters
  • Validator protocol security and key management

13. Monitoring & Incident Detection​

  • Prometheus for system metrics
  • CloudWatch and Loki for log aggregation
  • Alertmanager + Slack for anomaly alerts
  • Custom dashboards for transaction flow and Oracle uptime

14. Business Disruption Scenarios​

Prepared scenarios include:

  • Smart contract exploits
  • Oracle validator key leaks or DDOS
  • AWS region outage or availability zone loss
  • Cloudflare DNS or certificate failure

Each scenario has a playbook with roles and escalation paths.

15. BCP Testing Frequency​

We conduct BCP and DR testing twice annually:

  • Playbooks are executed in staging with realistic incident injections
  • Results and gaps are documented in our risk register
  • Each test informs updates to Terraform policies, alerts, and SOPs