←
Eviworx
Eviworx

Technical Whitepaper

Eviworx Enterprise ITSM Platform

Version 1.0

As of September 2026

Eviworx Software UG (haftungsbeschränkt)

Executive Summary

Eviworx is an enterprise-grade ITSM platform with 50+ integrated modules, blockchain-like SHA-256 audit chain and zero-trust security architecture. FIPS 140-2 compatible algorithms (PBKDF2-SHA512, TOTP HMAC-SHA256; no FIPS certification). The system is fully on-premise deployable via 12 specialized Docker containers (incl. Traefik API gateway and report generator) and offers multi-instance capability with distributed locks. With features like MFA/TOTP, 4-eyes principle, Entra ID SSO, Microsoft Graph API, ClamAV integration and a workflow engine with 8 step types, Eviworx addresses the requirements of compliance-oriented mid-market and enterprise customers. Available in 5 languages (DE, EN, ES, FR, IT). Note: Eviworx supports you with architecture and processes in meeting GDPR and NIS2 requirements; this does not constitute a certification or a legally binding declaration of conformity.

Table of Contents

  1. 1. Introduction
  2. 2. System Architecture
  3. 3. Security & Compliance
  4. 4. Core Modules
  5. 5. Workflow Engine
  6. 6. SLA Management
  7. 7. Cost Management & Contracts/Licenses
  8. 8. Deployment & Scaling
  9. 9. Integrations
  10. 10. Use Cases
  11. 11. Technical Specifications
  12. 12. Roadmap

1. Introduction

1.1 Problem Statement

Modern IT service management solutions face growing challenges: Compliance requirements (ISO 27001, NIS2, GDPR), lack of traceability for changes, poor integration between ticketing, assets and workflows, and high costs for cloud-based SaaS solutions while data protection concerns increase.

Especially in the mid-market and regulated industries, there is demand for on-premise solutions with tamper-evident audit trails that are simultaneously modern, scalable and low-maintenance.

1.2 Solution Approach

Eviworx addresses these challenges through:

  • Blockchain-like audit chain: SHA-256 hash chaining makes post-factum manipulation mathematically provable
  • Zero-trust security: AV worker without file access, SSRF protection, automatic redaction of sensitive fields in audit logs
  • Container-based deployment: 12 specialized containers (incl. Traefik API gateway) for modular, scalable architecture
  • 50+ integrated modules: From tickets to assets to workflow automation – everything from one source
  • Multi-instance ready: Distributed locks enable active-active deployments

2. System Architecture

2.1 Container Overview

Eviworx consists of 12 specialized containers orchestrated via Docker Compose:

Traefik API Gateway
Reverse proxy, TLS termination, routing, rate limiting
Frontend
React SPA, served statically via NGINX
Backend
Node.js API, Prisma ORM, JWT auth
PostgreSQL
Persistence, separate database roles, audit triggers
Redis
Caching, queues (BullMQ), locks
Email Worker
Background email processing, BullMQ consumer
Job Worker
Scheduled jobs, cron, multi-instance support
Workflow Engine
BPM, 8 node types, SLA monitoring
Notification Worker
Multi-channel dispatch (email, Teams via Bot Framework, Webex)
Report Generator
Custom reports, PDF/XLSX generation, scheduled reports
Virus Scanner
Virus scanner daemon, automatic signature updates
AV Worker
Scan orchestrator (zero-trust, no file access)

12 containers for production deployment (incl. Traefik API gateway and report generator)

2.2 Data Model

The system is based on 153 database models, organized into 50+ domain modules:

  • Auth & Identity (13 models): User, Agent, Roles, AgentGroups, API keys
  • ITSM Core (36 models): Tickets, incidents, problems, changes, approvals, lifecycle configuration
  • Assets (23 models): Asset, type, category, relations, handover, inventory
  • Workflows (7 models): Templates, instances, steps, forms, timer jobs
  • Notifications (14 models): Templates, adapter configs, digest buffer, push subscriptions
  • Contracts & Licenses (9 models): Publishers, products, assignments
  • Audit & Compliance (5 models): Events, chain head, retention, legal hold, activity log
  • Knowledge Base (14 models): Articles, revisions, e-library, tags
  • CronJobs & Automation (6 models): Jobs, executions, worker instances, heartbeats
  • Others (26 models): SLA & business hours, mailboxes, attachments, reports, cost centers, settings, views

3. Security & Compliance

3.1 SHA-256 Audit Chain

The audit chain is the heart of compliance features:

How It Works

  1. Each audit event receives a SHA-256 hash over a canonical event object: actorId + actorType + occurredAt + domain + category + action + entityType + entityId + changes + metadata + outcome + orgId + sequence + prevHash
  2. The prevHash links the event with the previous event (blockchain principle)
  3. A DB trigger calculates the hash during insert (enforced server-side, not bypassable through the application); a second trigger rejects UPDATE and DELETE on the chain
  4. AuditChainHead stores lastHash and lastSequence per organization
  5. Manipulation of a historical event would break the entire chain
  6. A nightly system job walks the chains section by section (continuity, purge anchor) and summarizes the result per chain; if a guard against endless runs takes effect, the run reports that explicitly. On any deviation a critical alert is raised to the compliance owners — the chain monitors itself

Automatic PII Scrubbing

The AuditScrubber automatically processes:

  • Denylist (always redacted): password, token, apiKey, secret, jwt, credentials, privateKey, ssn
  • PII fields (detected/flagged): email, phone, iban, creditCard, passport, nationalId, address, gps
  • Pattern recognition (redacted): Bearer tokens, AWS keys, Base64 secrets, private keys (-----BEGIN)

Marking: containsPII: boolean and redactedFields: string[]

Redis Fallback

Events are buffered in memory (5s flush interval). On DB failure: fallback to Redis (7-day TTL). Automatic recovery on service start. CRITICAL events are flushed immediately.

3.2 Zero-Trust Virus Scanning

Scan orchestration and file access are separate processes:

Architecture Principle

  • AV worker has NO file access: Sends only paths to Virus Scanner via TCP
  • Virus Scanner reads from own volume: Read-only mount of upload directory
  • No file access in the worker: The worker container has no upload volume and cannot open infected files
  • Backend handles quarantine: Attachment status = INFECTED, 7-day retention

Scan Workflow

  1. Backend API delivers attachments with PENDING status
  2. Optimistic locking: PENDING → SCANNING (409 on conflict)
  3. AV worker sends path to Virus Scanner: zSCAN /app/uploads/...
  4. Virus Scanner scans (2-minute timeout), response: OK or FOUND
  5. Result reporting: CLEAN / INFECTED / ERROR back to backend
  6. Backend sets attachment status and handles quarantine

3.3 4-Eyes Principle

Multi-approver system with flexible strategies:

ALL (Default)
All approvers must approve. Strictest level. Default for changes.
ANY
Any approver can approve. Faster release.
MAJORITY
More than 50% of approvers must agree. Democratic decision-making.
QUORUM
Configurable minimum number of approvals. Flexibly scalable.
Approval Groups
Named groups with member management. Deadlines per approval.
Self-Approval Protection
For changes, requestor and assigned owner cannot approve themselves. Separation of duties. Approvers must hold the matching permission.

Auto-Approval

Approval logic via conditions:

  • Field-based: amount < 1000 → Auto-approve
  • Permission-based: User has tickets.delete → Auto-approve
  • Role-based: User is ADMIN → Auto-approve

3.4 Additional Security Features

  • SSRF protection: IP range blocking (127.*, 10.*, 172.16-31.*, 192.168.*, 169.254.*), DNS validation, cloud metadata blocking (AWS/Azure/GCP)
  • RBAC caching: Per-role permission matrix in Redis (5min TTL) on top of the database. Every modifying request and every critical action reads permissions fresh from the database.
  • Entra ID SSO: OAuth 2.0, group-to-role mapping with priority conflict resolution, auto-sync
  • Session management: 12h max duration (server-side), token blacklist (Redis), HttpOnly cookies
  • MFA/TOTP: Multi-factor authentication for all users. TOTP with HMAC-SHA256, 6 digits, 30-second window; the secret is stored AES-256-GCM encrypted. Configurable per user in security settings.
  • FIPS 140-2 compatible cryptography: Password hashing PBKDF2-SHA512 with 210,000 iterations, TOTP HMAC-SHA256, AES-256-GCM. A strict FIPS mode via a dedicated Docker image can be enabled optionally. (FIPS 140-2 compatible algorithms, no FIPS certification.)
  • GDPR Data Breach Flow: Integrated reporting process for incidents. Evidence checklists. Category management for incident types.
  • Redis Authentication: Password-protected Redis access for additional security of cache and queue layers.

3.1 Data Protection & Data-Subject Rights (GDPR)

The system technically supports the exercise of GDPR data-subject rights — the legal assessment remains with the operator:

  • • Access & portability (Art. 15/20): machine-readable JSON export of all of a person's data — as self-service (rate-limited) and for admins/data protection officers.
  • • Erasure (Art. 17): implemented as anonymization — personal data is irreversibly overwritten, the skeleton remains for the factual case history. A preflight check resolves active involvements in an orderly way instead of tearing processes apart; an erasure hold (legal hold) guards against premature deletion under retention obligations.
  • • Retention & data minimization: one central nightly job enforces configurable retention periods for logs, audit events, telemetry and report exports; telemetry IPs are stored truncated.
  • • Tamper-evident logging: hash-chained audit history (SHA-256) in which later changes become detectable, with automatic redaction of personal fields; retention runs via a hash-preserving two-stage purge.
  • • Encryption at rest: all credentials (SMTP, Microsoft 365, Entra ID, messaging adapters), license keys and MFA secrets are stored encrypted with AES-256-GCM.
  • • Special categories (Art. 9): health-related data such as sick-leave reasons is masked without a special permission.
  • • Transparency: publicly reachable privacy policy and imprint with live-maintained retention periods.

Note: the listed capabilities support privacy-compliant operation; they do not constitute legal advice or a certification. Configuring periods, responsibilities and the privacy policy is the operator's task.

4. Core Modules

50+ domain modules cover all aspects of modern ITSM. Highlights:

ITSM Core
Tickets (incl. sub-tickets), incidents, problems, changes with state machines & reopen/lifecycle governance
Asset Management
Clustering, relations, QR/PDF handover, policies
Workflow Engine
8 node types, auto-approval, SLA, timer events
Contracts & Licenses
Software publishers, compliance tracking
CronJobs & Automation
Scheduled jobs with UI, 29 action types, 24 built-in templates, multi-instance ready
Knowledge Base
KB articles, e-library, tag system

5. Workflow Engine

5.1 Node Types (8 Total)

MANUAL_TASK
Manual task for user. Status: ASSIGNED → awaits completion.
APPROVAL
Approval step. Auto-approval/reject possible.
AUTOMATED_ACTION
Email, webhook, ticket ops. Immediately COMPLETED.
NOTIFICATION
Sends by email; further channels are handled by the central notification system. Immediately COMPLETED.
DATA_COLLECTION
Form capture. Awaits user submit.
TIMER_EVENT
Time delay (fixed or scheduled). TimerChecker triggers.
PARALLEL_GATEWAY
Forks into parallel branches; the step itself is immediately COMPLETED (no join node).
CONDITIONAL_BRANCH
Conditional routing logic with condition evaluator.

5.2 SLA Monitoring

A background job continuously checks every open target time:

  • Status: OK → WARNING (from 80% of target time used) → BREACH (deadline exceeded) → CRITICAL (more than an hour past it)
  • Escalation: freely defined levels per policy — triggered by percentage, on breach, or by time since the breach
  • Actions: notify, reassign, raise priority, webhook — plus an optional reminder at intervals while the breach persists

Check interval: 2 minutes (adjustable via cronjob administration). Business hours calculation; absent agents drop out of assignment selection.

6. SLA Management

6.1 Entity-Specific SLAs

The system supports SLAs for 3 entity types: Tickets, Incidents, Problems. Target times are maintained per priority in a policy — configurable, not hardcoded. The shipped default policies start with:

Tickets
CRITICAL: 10min response, 1h resolution. URGENT: 15min/2h. HIGH: 1h/8h. MEDIUM: 4h/24h. LOW: 8h/48h.
Incidents
P1: 15min response, 1h resolution. P2: 30min/4h. P3: 2h/24h. P4: 8h/48h.

Response target: for tickets the first public agent reply counts; for incidents and problems it is taking ownership (ITIL acknowledge).

6.2 Business Hours Intelligence

  • • Automatic holiday consideration: Country + region (e.g. Bavaria)
  • • Timezone-aware: Europe/Berlin, UTC, etc.
  • • Pause/resume: SLA pauses on ON_HOLD (configurable), while the ticket hangs on an open incident, and on the parent ticket while a sub-ticket is open (switchable per SLA policy)
  • • Only business minutes count: 4h SLA Mon 4pm → Tue 11am (not Mon 8pm!)

6.3 Escalation (freely configurable)

Levels, triggers and actions are defined by each organization. A typical pattern:

Level 1: 80% used
Notification to assignee + group lead
Level 2: deadline exceeded
Reassign to an escalation group or person + manager chain
Level 3: time after breach
Raise priority (which resets target times) or webhook

On top: a recurring reminder at a fixed interval while the breach remains unresolved (with a cap). Which channel delivers is controlled centrally by notification settings and user preferences.

7. Cost Management & Contracts/Licenses

7.1 Automatic Cost Calculation

Any billing cycles are automatically normalized:

Examples

  • €100 every 2 weeks (license with a weekly interval) → €216.67/month → €2,600/year
  • €150 quarterly → €50/month → €600/year
  • €1000 annually → €83.33/month → €1,000/year
  • €15/seat × 50 seats = €750/month for seat-based license

7.2 Contract Types & License Models

7 Contract Types

  • • LICENSE_SUBSCRIPTION
  • • LICENSE_VOLUME
  • • MAINTENANCE
  • • SUPPORT / SLA
  • • LEASE
  • • OTHER

12 License Types

  • • PERPETUAL, SUBSCRIPTION
  • • VOLUME, OEM, SITE
  • • USER, DEVICE, CONCURRENT
  • • TRIAL, FREEWARE
  • • OPEN_SOURCE, OTHER

7.3 TCO Forecasting & Compliance

  • • Upcoming renewals: renewal calendar over a freely chosen period (default 12 months); expiry reminders at configurable milestones (default 30, 7, 3 and 0 days)
  • • Seat tracking: Purchased vs. used. Over-assignment detection.
  • • Encrypted keys: AES-256-GCM with IP logging on retrieval
  • • Bulk ops: Mass link/unlink, status changes, assignments
  • • Exports: CSV/XLSX/PDF with complete audit trail

8. Deployment & Scaling

Docker Compose Deployment

Single-command start: docker compose up -d --build

  • Volumes: postgres_data, redis_data, uploads, quarantine, clamav_data, sourcemaps
  • Networks: shared Compose network; Traefik routes via a file-based configuration (file provider)
  • Health checks: all 12 containers; the live state is shown in Admin Center → System → System-Status (/admin/system-status)
  • Structured JSON logging: All custom containers log in structured JSON format with traceId, spanId, correlationId, requestId and service identifier. Compatible with Elastic Stack, Datadog, Grafana Loki etc.
  • Restart policy: unless-stopped

Multi-Instance Support

Distributed locks (Redis-based) enable active-active deployments. Job worker, workflow engine and timer checker use global locks for coordination.

9. Integrations

Available

  • Traefik API Gateway: Reverse proxy with TLS termination, automatic routing and rate limiting
  • Entra ID SSO: OAuth 2.0, group-to-role mapping with priority conflict resolution, auto-sync
  • Microsoft Teams (Bot Framework): Notification adapter via the Bot Framework with OAuth 2.0 client credentials
  • Webex: Notification adapter for Cisco Webex Teams
  • IMAP/SMTP: Multi-mailbox support for mailbox polling and sending via BullMQ queue, TLS verification configurable per mailbox. Individual email signatures per mailbox. Visibility control: tickets from specific mailboxes only visible to authorized users, roles and groups.
  • Microsoft Graph API: Native email integration without IMAP/SMTP, for receiving and sending. ProcessReply + dismiss support. Email signatures. Multi-mailbox operation.
  • Webhooks: External HTTP requests with SSRF protection (IP range blocking, DNS validation)
  • REST API: API keys for programmatic access, template permission checks

Planned

  • Slack: Notification adapter for Slack channels and direct messages

10. Use Cases

Use Case 1: Compliance-Oriented Mid-Market

Scenario: Company with ISO 27001 certification needs tamper-evident proof for all IT changes.
Solution: SHA-256 audit chain logs all changes, problems and incidents. Chain verification evidences the integrity of the chain. PII scrubbing supports the implementation of GDPR requirements.

Use Case 2: On-Prem Requirement (Data Protection)

Scenario: Healthcare provider cannot store sensitive data in cloud SaaS.
Solution: Complete on-prem deployment via Docker Compose. Application and data run in the customer's own environment; only explicitly enabled connections (Entra ID, Teams, Webex, Microsoft Graph) talk to third-party services. The zero-trust virus scan checks every upload locally without external services; infected files are quarantined and cannot be downloaded.

Use Case 3: Automated Workflows (Employee Onboarding)

Scenario: HR onboarding with approvals, asset handover, account provisioning.
Solution: Workflow engine with 8 node types orchestrates: 1) APPROVAL (manager approves), 2) AUTOMATED_ACTION (create account via webhook), 3) MANUAL_TASK (IT hands over laptop), 4) NOTIFICATION (welcome email). SLA monitoring tracks delays.

11. Technical Specifications

Backend

  • Runtime: Node.js 24
  • Framework: Express.js
  • ORM: Prisma (PostgreSQL)
  • Auth: JWT (HS256) in an HttpOnly cookie
  • API: RESTful

Frontend

  • Framework: React 19+
  • Build: Vite
  • UI: Tailwind CSS
  • Web server: NGINX (static SPA)
  • HTTPS: Let's Encrypt ready

Database

  • DBMS: PostgreSQL 17+
  • Models: 153
  • Access: separate DB roles (backend, job worker, read-only)
  • Trigger: Audit hash calculation

Cache & Queues

  • Cache: Redis 8+
  • Queues: BullMQ
  • Locks: Redis distributed locks
  • Pub/Sub: Redis channels

Security

  • Virus scan: Virus Scanner
  • Hash: SHA-256 (FIPS 140-2 compatible, no certification)
  • Passwords: PBKDF2-SHA512 (210,000 iterations)
  • MFA: TOTP HMAC-SHA256
  • Encryption: AES-256-GCM
  • SSO: Entra ID OAuth 2.0

Deployment

  • Container: Docker
  • Orchestration: Docker Compose
  • Volumes: 6 named volumes
  • Standard ports for HTTP/HTTPS, API, database

12. Roadmap

Recently Implemented

  • ✅ Reopen/lifecycle governance: ticket, incident & problem — reopen window/reason/limit with a dedicated permission axis
  • ✅ Auto-close & WC-auto-resolve: time-based closing of resolved tickets + resolving unanswered waiting-customer tickets
  • ✅ Stale reminders & reopen escalation: inactivity reminders across all three domains, escalation on too-frequent reopen
  • ✅ Lifecycle/reopen analytics: reopen rate & trends in a dedicated dashboard
  • ✅ Unified Workplace & NOC dashboard: configurable widgets & real-time monitoring
  • ✅ Attachment system hardening: isolated quarantine volume, precise file-type detection
  • ✅ Notification refactor: consolidated preferences, real queue-based retry (Teams/Webex)
  • ✅ GDPR data-breach flow · MFA/TOTP · Entra ID SSO

Planned Features (2026)

  • ⏳ Slack integration: Notification adapter for Slack channels and direct messages
  • ⏳ Mobile app (iOS/Android): Native apps for agents with offline support and push notifications (React Native)
  • ⏳ Advanced analytics: ML-based ticket classification, predictive SLA breach detection, cost forecasting with historical data

© 2026 Eviworx Software UG (haftungsbeschränkt) • Schillerstraße 96, 63263 Neu-Isenburg

info@eviworx.com • https://eviworx.com

Imprint · Privacy