Infrastructure as Code: Terraform for Fintech Compliance on Microsoft Azure

I'm Nischal, a cloud engineer based in Auckland, currently looking for cloud engineering and DevOps roles. Early on in building fintech infrastructure, I made a mistake that a lot of engineers make: treating compliance as something to sort out later. Security groups, encryption, audit logging, these got pushed to "we'll get to it" once the system was working.

That approach cost months of rework. Regulators do not assess your roadmap, they assess what is actually deployed.

The practical takeaway from that experience is that Terraform is not just an infrastructure tool, it functions as a compliance tool. When security and regulatory requirements are encoded as code, compliance stops being a manual checklist and becomes something reviewed, tested, and enforced automatically.

This piece sets out how to use Terraform on Azure to build infrastructure that is secure, auditable, and regulator ready from the outset, with the New Zealand regulatory context that shapes those decisions.

Executive summary

Compliance is a design constraint, not an afterthought. In New Zealand's financial services sector, regulatory requirements need to be addressed from the first infrastructure decision.
Terraform turns compliance from a manual checklist into code. When a regulator asks how encryption is ensured, the answer is Terraform code that makes the requirement explicit and repeatable.
Infrastructure as code reduces misconfiguration risk. Financial organisations using IaC generally see fewer security gaps and faster audit readiness than those relying on manual provisioning.
The New Zealand regulatory landscape is complex but codifiable. The Privacy Act 2020, RBNZ BS11, AML/CFT obligations, and ISO 27001 can all be expressed as Terraform controls.
A compliance ready fintech environment on Azure is achievable with Terraform, and the sections below set out a practical approach.

Regulatory drivers for fintech infrastructure in New Zealand

Financial technology infrastructure carries higher requirements than most other domains. Every transaction must be recorded durably and protected against unauthorised changes. Data must be encrypted throughout. Access must be tightly controlled and audited. Regulatory requirements such as PCI DSS, SOX, and banking regulations add further constraints on top of that baseline.

New Zealand financial institutions operate in one of the more demanding cloud compliance environments in the country. The key regulatory frameworks are:

Framework	What it covers	Relevance to Terraform
Privacy Act 2020	Collection, use, disclosure, storage, and cross border transfer of personal data	Terraform code needs to enforce encryption, access controls, and data residency
RBNZ BS11	Outsourcing Policy for registered banks, covering governance, risk management, and monitoring	Infrastructure needs to be auditable and demonstrate control over third party risk
AML/CFT Act	Anti money laundering and counter terrorism financing requirements	Infrastructure needs to support transaction monitoring and reporting
ISO/IEC 27001:2022	Information security management, expected by many NZ financial institutions	Terraform modules can enforce controls such as RBAC and audit logging
PCI DSS	Payment Card Industry Data Security Standard	Terraform code needs to enforce encryption, network segmentation, and logging

The RBNZ's Outsourcing Policy, BS11, is designed to manage the risks that arise when banks outsource functions to third party providers. It requires major banks to keep providing basic banking services and meet liquidity requirements regardless of issues affecting their parent or major outsourcing providers.

Financial services organisations in New Zealand need to know where their data sits, who can access it, and under what legal authority. The Privacy Act 2020 sets out thirteen information privacy principles that businesses and organisations handling personal information must comply with. Even where a breach was not technically caused by an organisation's own systems, responsibility from a compliance standpoint generally still sits with that organisation, since it collected the data and decided how it would be stored and used.

Why Terraform on Azure supports compliance requirements

When a regulator asks how encryption is ensured, the useful answer is Terraform code that makes the requirement explicit and repeatable. When auditors ask about access controls, the policies live in the repository, ready to show them.

Compliance encoded as infrastructure

Rather than relying on manual checklists and policy documents, requirements get encoded directly into infrastructure code. If infrastructure does not meet compliance standards, it does not get deployed.

In a case study published by Rosebud Cloud Solutions, a UK based Azure consultancy that works with regulated enterprises, a Tier 1 financial institution needed a greenfield Azure platform built under strict regulatory and risk constraints. Security, compliance, and operational governance needed to be embedded from day one, with retrofitting controls after deployment ruled out. The delivered platform used Terraform for repeatable, auditable deployments, with a shift left DevSecOps approach embedding security controls early in the lifecycle. At the client's most recent regulatory examination, the team could point the examiner to Terraform code and deployment history rather than assembling evidence after the fact.

Automated audit trails

Every Terraform change is tracked in version control, and every deployment carries a record of who made the change, when, and why. That produces a complete, auditable history of the infrastructure, which is close to exactly what regulators want to see.

The distinction worth drawing out is this: Azure Policy provides the controls, while infrastructure as code provides the evidence that those controls were actually applied. In insurance, financial services, or any sector carrying a serious compliance burden, that distinction tends to be the whole game.

Enforced controls versus documented controls

Compliance theatre, having well written policy documents with limited enforcement in code, does not hold up under scrutiny. Regulatory examinations increasingly ask to see the actual implementation: Git logs, deployment history, access control lists.

Terraform enforces controls at the infrastructure level. With Azure Policy integrated into the Terraform workflow, non compliant configurations fail before they can be applied. Azure Policy can be authored in Bicep or Terraform, which means the governance model lives in version controlled code and can be reviewed and tested like any other artefact.

Microsoft's Financial Services Industry landing zone

Microsoft maintains a Financial Services Industry (FSI) landing zone built specifically for regulated financial workloads. It is built using Azure Verified Modules and uses a Terraform module to configure a bootstrap environment.

Financial services organisations face strict, non negotiable compliance requirements beyond the baseline Azure landing zone. These include:

Ensuring the residency and sovereignty of data, so customers retain full control of their data and key ownership
Transparency in logging of cloud events from customer infrastructure, alongside visibility and control of Microsoft's own operations
A secure by default infrastructure that continuously meets regulatory compliance requirements, with evidence available to regulators
A highly resilient foundation, so mission critical applications such as payment gateways meet their required service level agreements

The FSI landing zone provides additional prescriptive guidance for the financial services industry on Azure to meet these requirements, developed through long term engagements with complex customers. It gives teams a compliant, enterprise grade foundation to build on rather than starting from a blank subscription.

Azure Policy as code: effects and governance model

Azure Policy defines exactly how resources should be configured and enforces it. Restricting deployments to specific regions for data sovereignty, mandating tags on every resource, blocking public IPs on databases, all of that is handled through policy.

There are three main modes to work with:

Audit — watches and logs. Resources still deploy, but non compliance gets recorded.
Deny — blocks the action outright. The resource never gets created.
Modify or DeployIfNotExists — lets the action through, then remediates. A missing tag gets applied, a diagnostic setting gets configured, automatically.

Most teams start in audit mode, work through the worst offenders, then move to deny. The harder problem is usually not the policies themselves but how they are managed at scale.

The workable approach is built in initiatives, applied through infrastructure as code. Azure's built in initiatives get referenced in Terraform, with code split logically: definitions, initiatives, and assignments each in their own place. Every change goes through Git, every change needs a pull request, and every pull request needs a second reviewer. At that point the governance model itself has governance.

One financial services company needed to comply with strict regulatory requirements for data encryption and access controls. It used Azure Policy to define and enforce those requirements across its subscriptions, with Terraform managing the underlying infrastructure as code, giving the same review and audit trail to policy changes as to any other infrastructure change.

Reference architecture: compliant fintech infrastructure on Azure

A fintech infrastructure on Azure typically includes:

Virtual Network (VNet) with strict network segmentation
Azure Key Vault for encryption key management and secrets storage
Azure SQL Database or Cosmos DB with encryption and audit logging
Azure Service Bus or Event Grid for ordered transaction processing
Azure WAF for API protection
Azure Monitor and Log Analytics for compliance auditing
Azure Policy for policy as code enforcement
Azure AD for identity and access management
Managed Identities for secure service to service authentication

Network segmentation

Financial infrastructure needs strict network isolation between tiers. A workable approach leverages the principles set out in Microsoft's Cloud Adoption Framework and builds an enterprise scale architecture with Terraform automation to create a consistent, repeatable foundation.

Identity and access management

Standardised RBAC models aligned to least privilege principles are essential for financial compliance. Security controls belong in the platform architecture itself, designed in from the start rather than layered on afterward.

Encryption and secrets management

Azure Key Vault handles secrets storage, with sensitive data encrypted at rest and in transit throughout. For a Tier 1 financial institution, the governance architecture was redesigned entirely: management group structures, policy frameworks, and security controls were codified using Terraform to improve audit readiness and reduce manual intervention.

Policy enforcement in the reference architecture

Azure Policy assignments defined through Terraform enforce governance, compliance, and organisational standards across Azure resources. The policy framework should be codified through infrastructure as code from the outset, covering regulatory compliance auditing frameworks such as SOX, PCI DSS, and GDPR where they apply.

Case reference: secure by design Azure platform for financial services

A Tier 1 financial institution needed a greenfield Azure platform built under strict regulatory and risk constraints, with security, compliance, and operational governance embedded from day one.

Approach:

Infrastructure as code using Terraform for repeatable, auditable deployments
Shift left DevSecOps embedding security controls early in the lifecycle
Integration of SIEM and cloud native security tooling for continuous monitoring
Codified policy enforcement to prevent configuration drift
Role based access controls aligned to least privilege principles

Outcome:

Security embedded into every deployment
Reduced configuration drift through automation
Improved audit readiness and operational visibility
Faster delivery cycles without compromising regulatory posture

The result was a scalable Azure foundation supporting long term growth under strict compliance requirements.

Operational lessons

Treating compliance as something to add later, rather than a starting constraint, was an early and costly mistake. Encryption, audit logging, and access controls are difficult to retrofit into a system that was not designed for them, and retrofitting is consistently more expensive than building it correctly the first time.

Terraform functions as the compliance record. When regulators ask questions, the useful reference is code rather than documents, since code is unambiguous, testable, and auditable in a way that a policy document is not on its own.

Policy as code scales in a way manual checklists do not. Automated validation catches what a checklist review misses, and a pipeline that fails on non compliant infrastructure is doing its job.

New Zealand employers in financial services are hiring for this specific combination of skills, engineers who can build compliant infrastructure with Terraform rather than treating compliance as a separate function.

Conclusion

Terraform on Azure functions as a compliance tool as much as an infrastructure one. Encoding security and regulatory requirements as code turns compliance from a manual checklist into something reviewed, tested, and enforced automatically.

The New Zealand financial services sector is in the middle of a genuine shift, banks moving to the cloud, fintechs launching new products, and regulators expecting more from all of it. Terraform is becoming a standard part of how compliant infrastructure gets built across that sector, and the practical path to that skill set is building it, documenting the decisions, and being able to show the work.

References

I'm Nischal Khanal, a cloud engineer based in Auckland, working on fintech infrastructure and expanding into Azure alongside AWS. If you are working on something in fintech, cloud, or DevOps, feel free to get in touch, on LinkedIn or via khanalnischal.com.np.