DevOps for Indian fintech isn't "DevOps with extra compliance bolt-ons." Done right, it's a fundamentally different posture from generic SaaS DevOps. The constraints — RBI guidelines, data residency, audit requirements, payment system reliability expectations — drive architecture decisions from day one.
Here's the playbook for engineering teams building fintech that's meant to hold up to regulators, auditors, and the unforgiving uptime expectations of payment systems. Written for Series A–C startups, NBFCs going digital, and product teams inside larger fintechs.
The constraints up front
Indian fintech engineering operates within a specific set of constraints that drive everything else:
- Data residency. Payment data must be stored in India (RBI April 2018 guidance and subsequent). Many fintech sub-categories have similar localisation requirements. Multi-region cloud architectures need an India-first design.
- Audit trails. Every transaction, every config change, every admin action must be logged immutably for the regulator-mandated retention period. Audit logs are not optional infrastructure.
- Reliability standards. Payment system downtime is reportable. RBI-DPSS expects four-nines or better for systemically important payment systems.
- Security baseline. RBI Cybersecurity Framework, PCI-DSS for card data, ISO 27001 commonly expected. SOC 2 increasingly expected for global business.
- Incident reporting. Many incident types require regulator notification within strict timelines (often 6 hours).
- Vendor controls. Cloud providers, third-party services, and outsourced tech must meet specific RBI guidance. Vendor risk management is a regulator-monitored function.
If you're building Indian fintech and your DevOps practice doesn't have answers for each of these, you're carrying invisible regulatory risk.
1. Cloud architecture — pick India regions intentionally
Default to India regions (Mumbai, Hyderabad, Chennai depending on cloud provider). Multi-AZ within the India region is the baseline. Multi-region for disaster recovery should also stay India-based for payment data — DR to Singapore won't satisfy RBI for localisation.
If you have non-payment workloads (general SaaS components), you can architect them more flexibly — but the data flow between regions must be carefully mapped. Many fintech teams discover they're unintentionally pushing payment-adjacent data through a non-India region for analytics or logging. That's a compliance issue.
Practical step: draw the data flow diagram for your platform, label each data store by data classification (payment, KYC, PII, general), and verify each is in an India region. This is a 1-hour exercise that often surfaces 2-3 issues.
2. Secrets management — make it impossible to leak
The most common fintech security issue we see in audits: secrets in the codebase. AWS keys in committed `.env` files. Database passwords in Kubernetes manifests. API keys hardcoded in mobile app builds.
The right setup:
- AWS Secrets Manager / Azure Key Vault / GCP Secret Manager — pick one, use it everywhere
- Vault for advanced secrets workflows (dynamic credentials, ephemeral certificates)
- CI/CD pipelines pull secrets at runtime, never bake them into images
- Pre-commit hooks (git-secrets, trufflehog) prevent accidental commits
- Regular secret rotation — quarterly minimum, monthly for high-sensitivity
- Audit logging on every secret access (your audit trail covers this implicitly)
Setting this up week one is 10x cheaper than retrofitting after an incident.
3. Audit logging — immutable from day one
The audit log infrastructure has specific requirements:
- Immutable. Use a write-once data store. CloudTrail logs to a separate S3 bucket with object lock enabled. Or stream to Splunk/Elastic with strict write-only access.
- Retention. Match the regulator-mandated retention period (typically 5+ years for payment data, longer for some categories).
- Coverage. Application transactions, admin actions, infrastructure changes, secret access, login events, configuration changes, code deployments — everything that could be relevant to incident investigation.
- Searchable. An audit log nobody can query within minutes is useless during an incident.
- Time-synchronised. NTP everywhere, drift monitoring. Timestamps without synchronised time are misleading at best, evidence-destroying at worst.
4. CI/CD with security gates
Modern fintech CI/CD pipelines are not optional. The pipeline structure that works:
- Code push → static analysis (linting + security linting via Semgrep, Bandit)
- Dependency scanning (Snyk, GitHub Dependabot, OWASP Dependency-Check)
- Unit and integration tests
- Container image building
- Container image scanning (Trivy, Snyk Container)
- IaC validation (tfsec, Checkov)
- Deploy to staging environment
- Automated security regression tests
- Manual approval gate for production
- Deploy to production with canary rollout
- Automated rollback on metric anomaly
Each security gate must fail the build hard, not warn-and-continue. Otherwise the gates become decorative.
5. Network segmentation
Payment data systems must be network-segmented from general SaaS components. The typical zone structure:
- DMZ — public-facing services (API gateways, web servers)
- Application zone — business logic services
- Data zone — databases, caches, message queues
- Payment zone — anything touching card or payment data (most restrictive)
- Admin zone — bastion hosts, management tools, observability
Cross-zone traffic only through explicit allowlists. No backbone "everything talks to everything" architectures. Use VPC peering, transit gateways, and security groups precisely.
6. Observability — for ops, for security, for compliance
Three layers of observability in fintech:
- Operational: traditional metrics + logs + traces. Prometheus + Grafana + OpenTelemetry, or a paid suite (Datadog, New Relic).
- Security: SIEM that aggregates security-relevant events from all sources. Wazuh, Splunk SIEM, Elastic Security. Detection rules for known attack patterns.
- Compliance: reports for regulators — uptime, incident history, security posture, vulnerability remediation timelines. Often built on top of operational + security observability.
Don't conflate them. Each has different retention, access control, and report requirements.
7. Incident response — practiced, not theoretical
The fintech incident response checklist:
- Defined incident severity levels and response timelines
- On-call rotations with PagerDuty / OpsGenie
- Runbooks for top 10 likely incident types
- Communication trees — who notifies whom, internally and to regulators
- Regulator notification templates pre-drafted
- Post-incident review process with written postmortems
- Quarterly incident response drills — actually run them, don't just plan them
When a real incident hits at 2am, the team that's run drills will respond cleanly. The team that hasn't will panic, miss notification timelines, and explain to the board why.
8. Vendor and third-party management
RBI specifically expects fintech to manage vendor risk. Practical version:
- Inventory of every third-party service that touches data — cloud provider, payment gateways, KYC vendors, analytics, monitoring, email, SMS
- Annual vendor security review for each material vendor — get their SOC 2 reports, security questionnaires
- Contracts include data processing agreements (DPA), security commitments, breach notification SLAs
- Right-to-audit clauses where feasible
- Plan for vendor switching — no single vendor lock-in for critical services
9. Compliance automation
Manual compliance is expensive and fragile. The patterns that work:
- Policy-as-code: AWS Config rules, Azure Policy, OPA / Gatekeeper for Kubernetes
- Automated evidence collection for SOC 2 / ISO 27001 / RBI audits — Drata, Vanta, Sprinto, or custom scripts
- Continuous control monitoring — alerts when a control drifts out of policy
- Quarterly self-assessment reports auto-generated for board and regulator review
What we'd start with at week one
If we were spinning up a new Indian fintech today and only had two weeks to set up the DevOps foundation:
- India-region AWS account, multi-AZ baseline, network segmentation in place
- Terraform-managed infrastructure from line one
- GitHub Actions CI/CD with security gates (Snyk, Trivy, Semgrep, tfsec)
- Secrets in AWS Secrets Manager, pre-commit hooks to prevent leaks
- CloudTrail + immutable audit log bucket from day one
- Wazuh SIEM for security observability
- Prometheus + Grafana for operational observability
- Incident response runbook draft (even rough — refine over time)
- SOC 2 readiness program kicked off (typically 8–16 weeks to audit-ready)
Retrofitting any of these later is painful. Doing them week one is cheap.
For more on our cloud and DevOps services, see the DevOps service guide. For the broader cybersecurity side, see cybersecurity services.