Eviworx
Eviworx

Technical Whitepaper

Eviworx Enterprise ITSM Platform

Version 1.0

September 2026

Eviworx Software UG

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 ready (PBKDF2-SHA512, TOTP SHA-256). 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 complete workflow engine, Eviworx addresses the requirements of compliance-oriented mid-market and enterprise customers. Available in 5 languages (DE, EN, ES, FR, IT).

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, row-level security
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 150+ database models, organized into 50+ domain modules:

  • Auth & Identity (8 models): User, Agent, Roles, AgentGroups, MFA/TOTP
  • ITSM Core (19 models): Tickets, Incidents, Problems, Changes
  • Assets (18 models): Asset, Type, Category, Relations, Handover
  • Workflows (11 models): Templates, Instances, Steps, Timer jobs
  • Notifications (12 models): Templates, adapter configs, digest buffer
  • Contracts & Licenses (12 models): Publishers, products, assignments
  • Audit & Compliance (6 models): Events, chain head, legal hold
  • Knowledge Base (10 models): Articles, e-library, tags
  • CronJobs & Automation (5 models): Jobs, executions, worker instances, heartbeats
  • Others: SLA, settings, analytics, forms, search, etc.

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: userId + timestamp + domain + action + oldData + newData + prevHash
  2. The prevHash links the event with the previous event (blockchain principle)
  3. A DB trigger calculates the hash during insert (server-side, not manipulable)
  4. AuditChainHead stores lastHash and lastSequence per organization
  5. Manipulation of a historical event would break the entire chain
  6. A nightly system job automatically verifies every chain in full (continuity, purge anchor); 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

Security architecture without compromises:

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
  • Prevents malware execution: Worker process 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
Creators cannot approve their own requests. Separation of duties. Configurable rejection handling.

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)
  • 3-layer RBAC caching: Token → Redis (5min TTL) → Database. Critical actions enforce DB revalidation.
  • 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 SHA-256 following FIPS standards. Configurable per user in security settings.
  • FIPS 140-2 Ready: Cryptography migration from bcrypt to PBKDF2-SHA512. TOTP SHA-256. FIPS-compatible Docker images available. (No official FIPS certification, but adherence to cryptographic standards.)
  • 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: immutable audit chain (SHA-256) 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, 26+ action types, 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
Multi-channel (email, Teams, Webex). Immediately COMPLETED.
DATA_COLLECTION
Form capture. Awaits user submit.
TIMER_EVENT
Time delay (fixed or scheduled). TimerChecker triggers.
PARALLEL_GATEWAY
Parallel branch execution. Waits for all branches.
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 → €216/month → €2,592/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: 30/60/90 day forecast for expiring contracts
  • 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
  • Networks: Traefik-managed with automatic service discovery
  • Health checks: Backend, Virus Scanner, worker services (/settings?section=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 Bot Framework (migrated from webhook)
  • Webex: Notification adapter for Cisco Webex Teams
  • IMAP/SMTP: Multi-mailbox support for mailbox polling and sending via BullMQ queue. Individual email signatures per mailbox. Visibility control: tickets from specific mailboxes only visible to authorized teams/agents.
  • Microsoft Graph API: Native email integration without IMAP/SMTP. ProcessReply + dismiss support. Email signatures. Multi-mailbox with VerifyTLS option (yes/no configurable).
  • Webhooks: External HTTP requests with SSRF protection (IP range blocking, DNS validation)
  • REST API: API keys for programmatic access, template permission checks

In Development (Roadmap)

  • 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 proves integrity. PII scrubbing supports GDPR compliance.

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. All data stays in own data center. Zero-trust virus scan prevents malware upload without external services.

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 20+
  • Framework: Express.js
  • ORM: Prisma (PostgreSQL)
  • Auth: JWT (RS256)
  • 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: 202
  • RLS: Row-level security
  • 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 ready)
  • Passwords: PBKDF2-SHA512
  • MFA: TOTP SHA-256
  • Encryption: AES-256-GCM
  • SSO: Entra ID OAuth 2.0

Deployment

  • Container: Docker
  • Orchestration: Docker Compose
  • Volumes: 5 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 • Schillerstraße 96, 63263 Neu-Isenburg

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