Building a CI/CD pipeline for a fintech startup and building one for a BaFin-regulated bank are not the same problem. The mechanics overlap — commit, build, test, deploy — but the constraints are fundamentally different. Regulated industries impose audit trail requirements, change management controls, environment separation mandates, and in some cases four-eyes principle requirements that must be structurally encoded into the pipeline itself, not bolted on as afterthoughts. Deka Technology has designed CI/CD systems for banking, insurance, and healthcare clients across the DACH region. Here is what that experience has taught us.
Regulatory Context: What Pipelines Must Demonstrate
BaFin's BAIT (Banking Supervisory Requirements for IT) and the European Banking Authority's ICT guidelines both require that financial institutions maintain evidence of who authorized each deployment, what changed, when the change was executed, and what the rollback capability is. Insurance regulation under Solvency II adds similar requirements for actuarial and reporting systems. Healthcare deployments under EU MDR (Medical Device Regulation) require validated software environments where any change to a production system triggers a formal validation protocol.
These are not checkbox requirements. Auditors examine pipeline logs, deployment records, and access controls during on-site reviews. A pipeline that cannot produce a machine-readable audit trail of every production deployment is a liability.
Four-Eyes Principle in Deployments
The four-eyes principle — requiring two independent approvals for any significant action — translates directly into pipeline design. In our regulated client pipelines, production deployments require:
- A merge request approved by at least two engineers (enforced at the VCS level in GitLab/GitHub).
- A manual approval gate in the CI/CD platform (GitLab CI protected environments, GitHub Actions environments with required reviewers) that requires a named approver distinct from the deployment initiator.
- An automated deployment record written to an immutable audit log (we use append-only S3 buckets or Azure Blob with immutability policies).
The four-eyes principle is only meaningful if it is structurally impossible to bypass. Pipeline design must make compliant behavior the path of least resistance — not a discipline requirement imposed on engineers under deadline pressure.
Automated Compliance Checks in the Pipeline
Manual compliance review at deployment time creates a bottleneck and a risk: humans miss things under pressure. Our approach moves compliance checks left — into the pipeline, running on every commit:
- SAST (Static Application Security Testing): SonarQube or Semgrep scans for vulnerability patterns and code quality gates. Builds fail on critical findings.
- Dependency scanning: Trivy or Snyk for known CVEs in container images and package dependencies. Regulated clients require a zero-critical-CVE gate before production.
- License compliance: FOSSA or REUSE for open-source license scanning — critical for clients with GPL incompatibility requirements.
- Infrastructure policy checks: OPA/Conftest against Terraform plans to prevent non-compliant resource configurations from reaching any environment.
Environment Separation and Secrets Management
Regulated clients require strict environment separation: development, QA, staging/UAT, and production must be logically and physically isolated with separate credentials, separate network segments, and separate access controls. We implement this using separate Kubernetes namespaces with network policies, environment-specific Vault paths for secrets, and pipeline logic that prevents any secret from crossing environment boundaries.
Secrets management uses HashiCorp Vault in all regulated client environments. Dynamic secrets — short-lived database credentials generated per deployment — eliminate the risk of long-lived credential leakage. Every secret access is logged, and Vault audit logs feed into the client's SIEM.
Our Pipeline Template for Regulated Clients
Deka maintains a regulated-industry CI/CD reference architecture that we adapt for each client. The template includes: GitLab CI or GitHub Actions workflow definitions, OPA policy library, Vault integration patterns, immutable audit log configuration, and a deployment approval runbook. Onboarding a new regulated client to a compliant CI/CD baseline typically takes four to six weeks rather than the months it takes to build from scratch.
Want to learn more about this topic?
First consultation is free — no strings attached.