Skip to content

The first question is not what you want to build.

It is which rules govern it. DORA, NIS2, MDR, NESA, the EU AI Act. Taiga is configured from that answer. Paying customers in healthcare and fintech run on this today.

Configured means something specific. Your framework's obligations become policies in named areas: security, data protection, software development lifecycle, operations, risk, architecture, supply chain, cloud governance. They are defined once at the organization, inherited by every project, and applied from the first draft of the specification, not bolted on after the build. The verticals below differ in which policies carry the most weight. The mechanism is the same in every one.

How policies become enforcement What runs under the policies

Financial services

  • DORA

DORA made resilience a board problem. Every delivery ships the evidence chain your reporting needs.

Traceable change, tested rollback, an evidence chain from the first deployment. The evidence accumulates as the work happens, not in a quarter-end scramble.

In the delivery
  • Traceable change
  • Tested rollback
  • Resilience evidence

The evidence chain has contents you can inspect. Traceability runs from the initiative that ordered a change down to the pull request that shipped it, with the approvals in between. Dependency and vulnerability posture is continuous: findings are judged against your supply-chain policy as they appear, and fixes arrive as reviewable pull requests. As-built documentation is updated after every merge, so the system described in your reporting is the system that is running.

What the factory produces for DORA

Healthcare

  • GDPR
  • MDR

The DPIA exists before anyone asks for it.

Patient data raises the floor: GDPR, national health data law, MDR where software touches care. The data flow documentation is written inside the delivery.

In the delivery
  • DPIA
  • Data flow map
  • Records of processing

The timing is the point. The DPIA, the data flow map, and the threat model are generated in the Learn loop against your data-protection policy, and a person reviews and approves each one, all before the build starts. Where MDR applies, the same chain links the specification to the verification evidence it demands. On the platform side, customer data stays in the EU and is never used to train models.

What the factory produces for GDPR and MDR Where your data lives, in detail

Defence

  • NESA

Some code cannot leave your control. It does not have to.

Repositories stay in your GitHub under an App you can revoke, built systems deploy into your cloud, and model inference stays inside EU regions. We are Finnish. We understand NESA-grade caution.

In the delivery
  • Residency evidence
  • Threat model
  • Deployment control

Three controls, in the order a reviewer checks them. Code custody: the GitHub App is installed by you, scoped by you, revocable by you, and the repository never changes hands. Deployment: the systems we build run in your environment, subject to your network policy. Inference: EU regions only, and regions outside the EU are denied by organization-wide guardrails.

Residency and revocation, in detail What the factory produces for NESA

Energy and manufacturing

  • NIS2

The NIS2 audits are arriving now. The risk register is already written.

NIS2 brought OT-adjacent software into scope. When we deliver into this sector, the delivery includes the risk register and the incident-ready audit trail that scope demands.

In the delivery
  • Risk register
  • Continuous sweeps
  • Incident-ready audit trail

Already written is not a figure of speech. The risk register is produced in the Learn loop, before the build begins, describing the system as designed instead of reconstructing it afterwards. Supply-chain posture does not go stale: every connected repository is swept, and findings are judged against your policy rather than a generic default. The incident-ready audit trail is the unbroken chain from business goal to deployment, ready on the day the questions arrive.

What the factory produces for NIS2

Public sector

  • EU AI Act
  • Procurement

Systems a successor could take over. No lock-in by obscurity.

Procurement needs transparency, and taxpayers deserve systems that outlive their vendor. When we deliver here, the package includes the documentation, the pipelines, and the infrastructure code a successor could take over.

In the delivery
  • Documentation
  • Pipelines a successor can run
  • Infrastructure code a successor can run

Takeover is a test you can run. The infrastructure is reproducible from the repository alone, and the CI/CD pipeline is versioned as part of the delivery rather than living in a vendor's head. The documentation matches what shipped. For the EU AI Act, the delivery records documented model use, the human oversight points, and the decision logs a review will ask for.

What the factory produces for the EU AI Act

Bring your regulator's hardest question.

Book a demo

Paying customers in healthcare and fintech run on this today.