Compliance software — GDPR, DORA, NIS2, Data Act, EU AI Act

We build dedicated applications and modules for compliance teams, DPOs, CISOs and risk departments. We help you meet GDPR, DORA, NIS2, Data Act and EU AI Act requirements without buying an oversized platform you would have to reconfigure for your industry anyway.

The problem: compliance is not "buy a licence"

Most organisations have tried to solve GDPR by buying an off-the-shelf tool. Six months later the processing register is out of date, the risk analysis exists only in a two-year-old PowerPoint, and the DPO answers every data subject request by manually grepping the file server.

With DORA and NIS2 it gets worse: these are far more operational regulations that demand living processes — a register of information on third-party providers, a resilience testing plan, formal incident reporting procedures, ICT risk assessments with a concrete methodology. Boxed platforms for this exist, but they are expensive and sell modules per regulation. The AI Act phases in from 2024–2026 on top of that and requires an AI system inventory practically nobody has yet.

What we build

We design dedicated applications and modules that genuinely live inside your processes. Not "another system to fill in at year end", but a tool the DPO / compliance / CISO uses daily — with an audit log ready to show the regulator built in from the start.

GDPR — processing register and RoPA

A structured register of processing activities under Article 30 GDPR, with legal bases, data categories, recipients and retention mapped. Change-approval workflow and automatic RoPA generation for audits.

GDPR — data subject rights

A system for receiving and handling access, rectification, erasure and portability requests. Routing to the right system owners, 30-day deadlines, a full audit trail.

GDPR — DPIA and risk analysis

A structured DPIA template with a library of threats and technical measures, 5×5 risk scoring (or your own methodology) and automatic report generation.

DORA — register of information

A DORA-compliant register of ICT providers (standard and critical), with functions, risk categories, contracts and exit plans mapped. Exports for ESMA / your national supervisor in the required format.

DORA — incident reporting

The full DORA ICT incident workflow: detection, classification (major / significant / cyber threat), escalation, supervisor reporting within the required deadlines (4h / 72h / 1 month).

NIS2 — incident reporting

A procedure for reporting significant cybersecurity incidents to your CSIRT under NIS2, with the early-warning, interim and final report workflow.

EU AI Act — AI system inventory

A register of AI systems used in the organisation, with risk classification (prohibited / high / limited / minimal), technical documentation, impact assessments and an approval workflow for new AI deployments.

Data Act — data agreements

A register of data access agreements (B2B/B2G), flow documentation, mapping of information duties and user access rights. A practical module for a brand-new regulation.

Asset and risk inventory

The common foundation for DORA / NIS2 / GDPR: a system inventory, risk assessments (NIST CSF / ISO 27005 / your methodology), control mapping, a compliance dashboard.

Regulations we know inside out

  • GDPR — from the basics to the hard parts (international transfers, legitimate interest, profiling, DPIA).
  • DORA (Digital Operational Resilience Act) — for financial-market entities since 17 January 2025; register of information, ICT risk management, TLPT, supervisor incident reporting.
  • NIS2 — the cybersecurity directive for essential and important entities, as transposed into national law across the EU.
  • Data Act — since September 2025; duties for IoT product manufacturers, related-service providers and data processing services.
  • EU AI Act — phasing in 2024–2026; AI system classification, documentation, transparency, human oversight, inventories.
  • eIDAS 2 and national cybersecurity acts — as a complement, depending on your profile.
  • Sector rules — EBA, EIOPA, ESMA guidelines and national supervisors for financial-market entities.

Our approach

Compliance software sits at the intersection of two disciplines where mistakes are expensive: law (a misread requirement = a regulator's fine) and engineering (a badly built system = unauditable logs, missing data, unhandled edge cases). That is why:

  • Every project is run by people who understand both sides — the legal context and the implementation.
  • Every module starts with mapping the regulation's requirements onto concrete data structures and processes. The result is a traceability matrix — which part of the code covers which article.
  • The audit log is a first-class feature, not an add-on. Every change to compliance data is logged with who/when/what/why.
  • Regulator exports (DPA, financial supervisor, CSIRT) are designed from day one — so in the hour of crisis nobody is googling "how to generate the report".

When it makes sense

It makes sense if:

  • You are a financial-market entity under DORA and your organisation is too small for full-blown GRC software in the OneTrust / IBM OpenPages class.
  • You are an essential/important entity under NIS2 and need to put incident reporting and risk management in order.
  • You are a large organisation (dozens of systems) and your current GDPR register is an Excel file nobody updates.
  • You run or plan more than one AI system and want AI Act-grade control from the start.
  • You are a software/SaaS vendor for regulated clients and they keep asking for compliance documentation you don't have yet.

Combined with our other services

Compliance software rarely lives alone — it usually pulls data from other systems (HR, IT asset management, identity providers, business systems). We naturally pair it with system integrations, and for automatic classification of incidents and documents — with AI systems.

Frequently asked questions

Should we buy an off-the-shelf tool (OneTrust, TrustArc, Securiti) or commission custom software?

Off-the-shelf platforms work for very standard GDPR implementations in large organisations with international requirements. For a mid-size organisation they are often oversized, expensive and need a long implementation project — which ends with writing custom integrations anyway. Custom software makes sense when: (1) your processes or industry are non-standard, (2) you want coherence with the rest of your stack, (3) you need integrations with local registers and systems the big platforms don't cover, (4) your scale doesn't justify six-figure annual licences. We often recommend a hybrid: off-the-shelf for the basics, custom modules for your specifics.

Does DORA apply to us or only to banks?

DORA applies to all financial-market entities in the EU: banks, insurers, investment and pension funds, licensed fintechs, payment service providers, account information providers, parts of the leasing sector. Plus ICT providers critical to those entities (TPPs). If you supply software to a bank, DORA reaches you through your contract with the bank. In practice DORA means formal ICT risk management, resilience testing (TLPT), incident management and a register of third-party providers.

How is NIS2 different from DORA?

NIS2 is the general cybersecurity directive for "essential and important entities" — energy, transport, healthcare, telco, digital infrastructure, public services, and many medium and large companies. DORA is the lex specialis for finance. The requirements are similar (risk management, incident reporting, governance), but DORA is more detailed and more operational (TLPT, the register of information on providers). If you fall under both — DORA takes precedence for ICT requirements, NIS2 covers the rest.

Can you implement an AI system inventory for the EU AI Act?

Yes — it is a frequent request. The AI Act requires organisations deploying AI to maintain an inventory of AI systems with risk classification (prohibited / high / limited / minimal), technical documentation, impact assessments and logs. We build dedicated modules (or standalone applications) managing such a register — with integrations into source systems, an audit log and an approval workflow for new AI deployments.

What do you deliver beyond the code?

Code is about 60% of the value — the rest is compliance documentation: an architecture description mapped to regulatory requirements, a register of processing activities (if the application processes personal data), data flow diagrams, a risk assessment, a DPIA report (where required), an incident management procedure, and an audit-ready documentation pack. In English and Polish, in a format you can hand to an auditor, your national DPA or your financial supervisor.

Facing DORA, NIS2, the AI Act or a new GDPR register?

Briefly describe your situation — industry, regulation, current state. Within 1–2 business days we will come back with a proposed scope and an indicative quote.

Book a consultation →