Security & architecture
An independent verification instance, inside your environment.
SQACE verifies your data processing where the data sits: on-premise or in an EU cloud, with no telemetry and no callback. Data sovereignty and traceability are built in, not bolted on.
Data flow & sovereignty
Your data stays where it belongs.
SQACE reads from your sources, computes and compares inside your controlled instance, and hands back audit-proof evidence. No data copy is created outside your jurisdiction.
Your data sources
Databases, files, services in your environment. Read access, no pre-processing needed.
SQACE verification instance
On-premise or EU cloud, containerised. Computation and comparison run here. No telemetry, no callback.
Audit-proof evidence
Release, deviation, audit trail. Read-only and versioned in your SQACE storage.
Operations & data sovereignty
In your infrastructure. Under your control.
SQACE is built to grow from a first pilot to an enterprise-wide standard, without data protection and traceability becoming a bottleneck.
On-premise or EU cloud
Containerised operation (Docker/Linux) in your infrastructure or an EU cloud. Your data does not leave your jurisdiction; updates are applied in line with your release processes.
Physically separate workspaces
Each test project gets an isolated workspace (Mission Base) with its own data, connections, rules and rights. Teams work in parallel without affecting one another.
Verification on production data
A separate production instance (Production Server) verifies directly on production data, without direct user access. Privacy by design, not by policy.
Permission concept
Fine-grained, role- and rights-based access to data, connections, test definitions, execution and results, connectable to your existing permission systems.
Versioning & audit trail
Who defined, changed, ran and released what, and when? Released solutions are read-only, audit-proof and not deletable.
Automatic deletion
Defined retention periods and automated data-lifecycle management apply without manual per-project configuration.
Integration
Connectivity to your data landscape, honestly drawn.
SQACE replaces no infrastructure. It fits in: no data copies, no intermediate layers, no separate user management. We only show here what holds today.
Data sources
JDBC databases (Oracle, Microsoft SQL Server, PostgreSQL and other JDBC-compatible systems) plus files in CSV, JSON, XML and fixed-width formats. Distributed data can be pulled into tests directly, without pre-processing.
Web services
Connects REST interfaces, both as a data source for tests and as a way to drive SQACE from the outside.
Test management
Test results, deviations and release status flow straight into Jira / Xray, with no manual transfer and no re-keying between systems.
DevOps & automation
Via the REST API, tests and workflows can be triggered from CI/CD pipelines (e.g. Jenkins, GitLab CI, Azure DevOps) or orchestration tools (e.g. Camunda). Results are reported back.
Identity & access
Integrates with central identity and access systems via Single Sign-On / Active Directory. User management and security policies stay consistent.
Multiple environments
Structured processes across separate stages (Dev, Test, Prod): tests, rule sets and connections are promoted in a controlled, version-controlled way.
This is the confirmed current state of our connectors. For other sources and the roadmap, let’s talk specifics.
Which requirement this serves
Evidence that maps to your frameworks.
SQACE is not a compliance tool. It is a verification instance whose work produces audit-ready evidence. Which requirement each capability serves is decided by your regulatory context, not by a promise from us.
Data quality across the lifecycle
Rule-based expected-vs-actual comparisons and complete documentation provide evidence that processing results are correct. This addresses principles for data quality and traceability such as those described by BCBS 239.
Traceable procedures
Versioned rule sets, the permission concept and an audit-proof audit trail document who checked and released what, and when. This serves requirements for documented, traceable procedures such as those MaRisk places on processes.
Testing before production use
Tests from CI/CD pipelines and verification on production data support the testing of ICT components and data processing, a topic that DORA addresses for the financial sector.
Validation in regulated industries
Reproducible runs, automatic documentation and read-only releases support the validation of computerised systems as required in GxP environments.
FAQ
Frequent questions from CISOs and CTOs
Does our data leave our environment?
No. SQACE runs containerised (Docker/Linux) in your infrastructure or an EU cloud. There is no telemetry and no callback to us. Your data and verification results stay in your jurisdiction, under your control.
How does SQACE access production data?
Through a separate Production Server in your sealed production environment. Released solutions are deployed there from the dev server and run read-only on production data. Developers get no direct access. Privacy by design, not by policy.
Does SQACE replace our existing infrastructure or user management?
No. SQACE connects to your data sources, tools and CI/CD, without data copies and without separate user management. Integration with Single Sign-On and Active Directory keeps user management and security policies consistent.
How do we prove to auditors what was tested?
Every test run, every result and every rule change is documented automatically. Released solutions are read-only, audit-proof and not deletable. Evidence arises as a by-product of the work, not as a parallel compliance track.
Is SQACE a compliance tool?
No. SQACE is a verification instance for data processing. The evidence it produces (audit trail, versioning, permissions) serves requirements from frameworks such as BCBS 239, MaRisk, DORA or GxP. Which requirement is met is decided by your context, not by a compliance promise from us.