Fintech DevOps is regular DevOps with one critical constraint: every pipeline, every deployment, and every infrastructure change must be auditable, traceable, and compliant with financial regulations.
PCI DSS 4.0 changed the game in 2024. CI/CD pipelines are now explicitly in scope if they contribute to software running in the cardholder data environment. This means your build system, your container registry, your deployment tooling — all of it needs to meet PCI requirements.
We build DevOps pipelines for fintech companies. Here is the architecture that passes audits without slowing down delivery.
Why Fintech DevOps Is Different
Standard DevOps priorities: ship fast, iterate, automate everything.
Fintech DevOps priorities: ship fast, iterate, automate everything — and prove you did it correctly to auditors.
The key constraints:
| Requirement | What It Means for DevOps |
|---|---|
| Audit trail | Every deployment must be traceable to a commit, reviewer, approver, and timestamp |
| Separation of duties | The person who writes code cannot approve it. The person who approves cannot deploy it |
| Change management | Every production change needs documented approval |
| Vulnerability management | Container images and dependencies must be scanned before deployment |
| Access control | Infrastructure access must be role-based with MFA |
| Encryption | Data at rest and in transit must be encrypted everywhere |
| Logging | All access and changes must be logged and retained for 12+ months |
The Pipeline Architecture
Here is the pipeline we build for fintech clients. Every stage produces audit evidence automatically:
Developer → PR → Code Review (2 approvers) → Merge
│
▼
┌─────────────────────┐
│ Build Stage │
│ • Compile/bundle │
│ • Unit tests │
│ • SAST scan │
│ • License check │
└──────────┬──────────┘
│
▼
┌─────────────────────┐
│ Security Stage │
│ • Container scan │
│ • Dependency audit │
│ • Secret detection │
│ • SBOM generation │
└──────────┬──────────┘
│
▼
┌─────────────────────┐
│ Compliance Gate │
│ • OPA policy check │
│ • Approval required│
│ • Evidence logged │
└──────────┬──────────┘
│
▼
┌─────────────────────┐
│ Deploy Stage │
│ • Staging first │
│ • Integration tests│
│ • Production deploy│
│ • Rollback ready │
└──────────┬──────────┘
│
▼
┌─────────────────────┐
│ Post-Deploy │
│ • Smoke tests │
│ • Audit log entry │
│ • Notification │
└─────────────────────┘The Pipeline in Code
# .github/workflows/deploy.yml
name: Fintech CI/CD Pipeline
on:
push:
branches: [main]
pull_request:
branches: [main]
permissions:
id-token: write
contents: read
security-events: write
jobs:
build-and-test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Run unit tests
run: npm test -- --coverage
- name: SAST scan (Semgrep)
uses: semgrep/semgrep-action@v1
with:
config: p/owasp-top-ten
- name: License compliance check
run: npx license-checker --failOn 'GPL-3.0'
security-scan:
needs: build-and-test
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Build container image
run: docker build -t myapp:${{ github.sha }} .
- name: Scan container (Trivy)
uses: aquasecurity/trivy-action@master
with:
image-ref: myapp:${{ github.sha }}
severity: CRITICAL,HIGH
exit-code: 1 # Fail on critical/high vulnerabilities
- name: Secret detection (Gitleaks)
uses: gitleaks/gitleaks-action@v2
- name: Generate SBOM
uses: anchore/sbom-action@v0
with:
image: myapp:${{ github.sha }}
artifact-name: sbom-${{ github.sha }}.spdx.json
- name: Dependency audit
run: npm audit --audit-level=high
compliance-gate:
needs: security-scan
if: github.ref == 'refs/heads/main'
runs-on: ubuntu-latest
environment: production # Requires manual approval in GitHub
steps:
- name: OPA policy check
run: |
# Verify deployment meets compliance policies
conftest test deployment/ --policy policies/ --output json \
> compliance-report.json
- name: Log compliance evidence
run: |
echo '{
"timestamp": "'$(date -u +%Y-%m-%dT%H:%M:%SZ)'",
"commit": "${{ github.sha }}",
"actor": "${{ github.actor }}",
"approvers": "${{ github.event.pull_request.requested_reviewers }}",
"security_scan": "passed",
"compliance_check": "passed"
}' | aws s3 cp - s3://audit-logs/deployments/${{ github.sha }}.json
deploy:
needs: compliance-gate
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Configure AWS (OIDC - no stored keys)
uses: aws-actions/configure-aws-credentials@v4
with:
role-to-arn: arn:aws:iam::123456789:role/github-deploy
aws-region: eu-west-1
- name: Deploy to EKS
run: |
kubectl set image deployment/app app=myapp:${{ github.sha }} \
-n production --record
kubectl rollout status deployment/app -n production --timeout=300s
- name: Smoke tests
run: |
sleep 10
curl -f https://api.myapp.com/health || exit 1
- name: Notify
if: always()
uses: slackapi/slack-github-action@v2
with:
webhook: ${{ secrets.SLACK_WEBHOOK }}
payload: |
{"text": "Deploy ${{ job.status }}: ${{ github.sha }} by ${{ github.actor }}"}PCI DSS 4.0: What Changed for DevOps
PCI DSS 4.0 (enforced March 2025) brought significant changes:
CI/CD Is Now In Scope
Previously, only the cardholder data environment (CDE) was in scope. Now, any system that “contributes to the software” running in the CDE is in scope — including your build servers, CI/CD pipelines, and container registries.
What this means:
- GitHub Actions runners that build CDE-bound code must be hardened
- Container registries storing CDE images need access controls and audit logs
- Terraform state files containing CDE infrastructure are in scope
- Secrets used in pipelines must be managed through approved secret managers
Software Bill of Materials (SBOM)
PCI DSS 4.0 Requirement 6.3.2 requires maintaining an inventory of custom and third-party software components. Generate SBOMs automatically in your pipeline and store them alongside deployment artifacts.
Automated Vulnerability Management
Requirement 6.3.1 requires identifying and managing security vulnerabilities in custom and third-party software. Integrate vulnerability scanning at every stage:
| Stage | Tool | What It Catches |
|---|---|---|
| Pre-commit | Gitleaks | Hardcoded secrets |
| Pull request | Semgrep/SonarQube | Code vulnerabilities (SAST) |
| Build | npm audit / pip audit | Dependency vulnerabilities |
| Container build | Trivy / Grype | OS and library CVEs |
| Pre-deploy | OPA / Kyverno | Policy violations |
| Runtime | Falco | Suspicious container behaviour |
PCI Scope Reduction Strategies
Smart architecture reduces what falls under PCI scope — cutting audit effort by 40-70%:
Network Segmentation
Isolate the CDE from the rest of your infrastructure:
┌──────────────────────────────────────────┐
│ Non-CDE (out of PCI scope) │
│ ├── Marketing website │
│ ├── Internal tools │
│ ├── Analytics │
│ └── Development environments │
└──────────────┬───────────────────────────┘
│ firewall / network policy
▼
┌──────────────────────────────────────────┐
│ CDE (in PCI scope) │
│ ├── Payment processing service │
│ ├── Card data storage (tokenised) │
│ ├── Payment gateway integration │
│ └── Audit logging │
└──────────────────────────────────────────┘In Kubernetes, use network policies and separate namespaces:
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: cde-isolation
namespace: payment-processing
spec:
podSelector: {}
policyTypes: [Ingress, Egress]
ingress:
- from:
- namespaceSelector:
matchLabels:
pci-scope: "true"
egress:
- to:
- namespaceSelector:
matchLabels:
pci-scope: "true"
- ports:
- port: 443 # Payment gatewayTokenisation
Replace card numbers with tokens at the earliest possible point. If your services only handle tokens, they are out of PCI scope:
Customer → Payment Form (Stripe.js) → Stripe → Token
│
Your Backend receives TOKEN only ──────────────────┘
(never sees card numbers = reduced PCI scope)Using Stripe, Adyen, or similar payment processors as the tokenisation layer keeps most of your infrastructure out of PCI scope.
Separate CI/CD for CDE
Run CDE deployments through a dedicated pipeline with stricter controls:
- Separate GitHub environments with required reviewers
- Dedicated self-hosted runners (not shared with non-CDE)
- Separate container registry with stricter access controls
- Enhanced logging sent to a tamper-proof audit store
Infrastructure Architecture
The infrastructure we build for fintech clients:
┌─ AWS Account (Production) ─────────────────────────┐
│ │
│ VPC (10.0.0.0/16) │
│ ├── Private Subnets (CDE) │
│ │ ├── EKS Node Group (payment services) │
│ │ ├── RDS (encrypted, multi-AZ) │
│ │ └── ElastiCache (encrypted) │
│ │ │
│ ├── Private Subnets (Non-CDE) │
│ │ ├── EKS Node Group (general services) │
│ │ └── Internal ALB │
│ │ │
│ └── Public Subnets │
│ ├── External ALB (WAF-protected) │
│ └── NAT Gateway │
│ │
│ Cross-cutting: │
│ ├── CloudTrail (all API calls logged) │
│ ├── GuardDuty (threat detection) │
│ ├── Config (compliance monitoring) │
│ ├── KMS (encryption key management) │
│ └── Secrets Manager (credential storage) │
└─────────────────────────────────────────────────────┘Provisioned with Terraform (or OpenTofu), every infrastructure change is version-controlled and auditable:
# RDS with encryption (PCI requirement)
resource "aws_db_instance" "main" {
engine = "postgres"
engine_version = "16.2"
instance_class = "db.r6g.large"
storage_encrypted = true # PCI: encrypt at rest
kms_key_id = aws_kms_key.db.arn
multi_az = true # High availability
deletion_protection = true
# PCI: audit logging
enabled_cloudwatch_logs_exports = ["postgresql", "upgrade"]
}Kubernetes Security for Fintech
If you run on Kubernetes, these are non-negotiable:
RBAC with Least Privilege
Every team gets access to their namespace only. Nobody gets cluster-admin outside the platform team:
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: payment-team
namespace: payment-processing
rules:
- apiGroups: ["apps"]
resources: ["deployments"]
verbs: ["get", "list", "watch"] # Read-only for most
- apiGroups: [""]
resources: ["pods/log"]
verbs: ["get"] # Can view logsSee our Kubernetes RBAC audit guide for the full setup.
Pod Security Standards
Enforce restrictive pod security at the namespace level:
apiVersion: v1
kind: Namespace
metadata:
name: payment-processing
labels:
pod-security.kubernetes.io/enforce: restricted
pod-security.kubernetes.io/audit: restricted
pci-scope: "true"This prevents containers from running as root, using host networking, or escalating privileges — all critical for PCI compliance.
Image Signing and Verification
Only deploy verified, scanned images:
# Kyverno policy: only allow signed images
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: verify-images
spec:
rules:
- name: verify-signature
match:
resources:
kinds: [Pod]
namespaces: [payment-processing]
verifyImages:
- imageReferences: ["registry.example.com/*"]
attestors:
- entries:
- keyless:
rekor:
url: https://rekor.sigstore.devDeployment Patterns for Fintech
Blue-Green Deployments
For payment processing services where zero downtime is critical, use blue-green deployments. Two identical environments run simultaneously, with traffic switched after validation:
- Deploy new version to “green” environment
- Run integration tests against green
- Shift traffic from blue to green
- Monitor for errors for 15-30 minutes
- If issues detected, instantly shift back to blue
Change Freeze Windows
Implement deployment freezes during peak transaction periods (month-end, payroll dates, holiday shopping). Automate this in your pipeline:
- name: Check deployment window
run: |
DAY_OF_WEEK=$(date +%u)
HOUR=$(date +%H)
# No deployments on Fridays after 2 PM or weekends
if [[ $DAY_OF_WEEK -ge 5 && $HOUR -ge 14 ]]; then
echo "::error::Deployment blocked: outside change window"
exit 1
fiAudit Readiness Checklist
When your PCI auditor asks “show me how deployments work,” you should produce:
- Git commit history with PR reviews and approvals
- CI/CD pipeline logs showing security scans passed
- SBOM for every deployed artifact
- Container vulnerability scan results
- OPA/Kyverno policy check results
- Deployment approval evidence (GitHub environment protection)
- CloudTrail logs showing who deployed what and when
- Rollback evidence (if applicable)
Every item should be automated. If your team manually creates audit evidence, you are doing it wrong.
Building Compliant DevOps for Your Fintech?
We build PCI-compliant DevOps pipelines for fintech companies — from early-stage startups getting their first PCI certification to established platforms scaling their infrastructure.
Our DevOps consulting services for fintech include:
- Pipeline architecture — design CI/CD with built-in compliance gates and audit trails
- PCI scope reduction — network segmentation, tokenisation strategy, and architecture isolation
- Kubernetes security — RBAC, network policies, pod security, and secrets management
- Infrastructure as Code — Terraform with compliance controls for AWS/Azure/GCP
- Audit preparation — automated evidence collection and compliance reporting