Separate by design
Sandbox and production are separate environments, each in its own Azure subscription, built from the same Terraform modules. Production is the sandbox’s shape with stronger settings, and every change reaches sandbox first.
Group cloud foundation
Every change is code, reviewed before it is real
The whole Azure estate as code; Terraform and Bicep provisioning, GitHub Actions pipelines, Entra ID and Intune policy as code, secured zero-trust from endpoint to edge. It covers the company’s Microsoft 365 tenant as well as its Azure subscriptions: who can sign in and from what device, where each system runs, how secrets are held, and what stands between the internet and the staff tools. The intent lives in git, not in one administrator’s head or in clicks in a portal.
Environments
Sandbox first, production by approval
Production is held to more
Production keeps its logs longer and backs its database up to a second region. Services send their logs and metrics to a central workspace, with alerts on database load and application errors.
A developer tier with no customer data
An empty-data environment on a small virtual machine, for building without touching anyone’s records. Its database password is generated on the machine at first boot and never written to git.
Each system its own stack
Servers such as the Job Adding System’s and JARVIS’s are built from Bicep; the Job Adding System keeps its sandbox and production parameters side by side. Edge settings are Terraform, one stack per application and environment, and each stack manages only its own records, so applying one can never change another.
Pipelines
Planned on every pull request, applied only on approval
The infrastructure pipelines in GitHub Actions sign in to Azure with OpenID Connect federation: each run gets a short-lived token, and no Azure password or key is stored in GitHub.
How a change lands
- Every change is a pull request, and the plan is run on it for review.
- Changes apply only from the main branch, and a manual apply needs a typed confirmation; anything else only plans.
- An apply saves its plan to a file and applies that file, so what changes is exactly what was planned.
- Bicep templates are compiled on every infrastructure change, so a broken template is caught before a deployment.
What the pipelines check
- A static security scan of the infrastructure code gates both pull requests and applies. It fails on any finding new against a recorded baseline, and the baseline is only meant to shrink.
- The Job Adding System’s pipeline adds a secrets scan of the whole git history, Dockerfile linting, a configuration scan, an audit of locked dependencies against published advisories, and a scan of the workflows themselves.
- In the RenewCompare and Job Adding System pipelines, third-party actions are pinned to commit hashes, not movable tags.
- Job permissions are narrowed to the job: the security scan runs with read access only and no cloud sign-in at all.
Further reading. How the images those pipelines build are made: Building a container image I’d trust in production.
Identity and devices
Entra ID and Intune, as code
The tenant’s intended state is a repository: every change a pull request, and the real tenant checked against it on a schedule.
From policy to code
The company’s written policies, from acceptable use and data handling to shadow IT, incident response and backup, are mapped to the technical controls that implement them. That map is the reason for everything in the code and the yardstick the audit measures against.
Sign-in policy in Terraform
Conditional Access, authentication strengths and groups are Terraform, planned in review and applied by an owner, so who can sign in, and how, is a reviewed change rather than a click in a portal.
Device baselines
Compliance policies for company computers and phones, and app-protection policies for company data on mobile apps, are kept as code and assigned by group, so a new device gets the same baseline as the last.
Read and write kept apart
The audit and the changes use separate identities, each with its exact least-privilege permissions written down. The audit identity can only read, and the write path is applied by an owner, never by itself.
Secrets and the edge
Where secrets live, and what faces the internet
Secrets in a vault
RenewCompare’s secrets live in Azure Key Vault, reached over private networking. Its applications read them through managed identities, their configuration refers to a secret rather than holding it, and sensitive account fields are encrypted with a key that stays in the vault.
Private by default
The managed database sits inside a private network with public access switched off. Scheduled jobs run inside the same network, so they reach the database without it ever being exposed.
The edge, as code
DNS, managed firewall rules, rate limiting, single sign-on policies and tunnels are Terraform. The staff console sits behind single sign-on at the edge, reached through a tunnel its server opens outward.
Hosts that watch themselves
The Job Adding System’s server carries an outbound firewall, audit logging and a watch on its listening ports, and its network keeps flow logs, all defined alongside the server itself.
Audit and review
Checked every week, reviewed in depth
Every week. Since July 2026 a read-only audit of the Microsoft 365 tenant has been scheduled in CI every week. It signs in by federation, collects the tenant’s state, ranks what it finds, and commits the report to git, so any drift in posture is visible in the history.
In depth. In July 2026 I ran a read-only security review across every RenewCompare repository and the live Azure estate. Each finding was verified before it was fixed, and every fix went through the normal pull request, pipeline and deploy path. Among them: security headers on every API response, error pages included; every third-party CI action in those repositories pinned to a commit; and services that refuse to start in production with authentication switched off.
Owned decisions. Anything that needs a decision beyond mine goes to the company’s security owner on a register, split by who owns the system. Fixes I can make, I make through the same reviewed path as everything else.
Terraform • Bicep • GitHub Actions • OIDC • Entra ID • Intune • Microsoft Graph • Azure Key Vault • Azure Container Apps • Cloudflare • Checkov • gitleaks • Trivy