ISO 27001 Auditable System on a Budget with just 20 Files

Our journey has been about one thing: building a sovereign, secure, and radically efficient company. Today, I’m showing you the engine that drives it all.

For years, the tech world has been sold a story: that to be secure, compliant, and scalable, you must surrender your wallet and your control to the cloud giants. That achieving something like ISO 27001 certification requires an army of consultants, binders full of checklists, and a state of perpetual anxiety.

We call bullshit.

After we detailed how we slashed our audit prep time and our infrastructure bills, the single biggest question we got was, "How? What does the system that enables this actually look like?"

Here it is. This is the blueprint for our automated, self-healing, and continuously compliant infrastructure.

Compliance as Code

The old way of doing compliance is taking screenshots and manually ticking boxes in a spreadsheet. It's a snapshot in time, obsolete the moment you save it. It’s a performance for the auditor.

Our philosophy is different: The system is the documentation. The evidence for our compliance is generated by the very workflows that run our business, every single day.

Our stack is simple, powerful, and transparent:

• Hosting: Hetzner and OVH Cloud (for sovereignty and cost)

• Version Control: GitHub (as our single source of truth)

• Infrastructure: Terraform (to define our infrastructure as code)

• Configuration: Ansible (to enforce the state of every server)

• Secrets: Infisical with OIDC (to eliminate manual secret handling)

These aren't just tools. They are the components of a machine designed for auditable, repeatable operations.

The Blueprint: A Tour of the Machine

When an auditor asks, "How do you manage change?" we don't point to a Word document. We show them our GitHub Actions.

• terraform-plan/apply.yml: No one can make a "quick change" in the live environment. Every infrastructure modification – adding a server, changing a network rule – starts as a line of code in a pull request. It gets planned, reviewed by a teammate, and requires manual approval to apply. The entire audit trail – who proposed, who approved, what changed – is baked into our Git history forever. (This is ISO 27001's A.12.1.2 Change Management, automated).

• ansible-deploy.yml: Configuration isn't a suggestion; it's a contract. Ansible ensures every server is configured identically and correctly, every single time. It sets up our web servers, hardens our databases, and deploys our monitoring agents. If we release a new version of our app, this workflow ensures it lands perfectly in a tested, consistent environment.

• terraform-drift-detection.yml: We don't hope our infrastructure is compliant; we verify it. Every night, a scheduled job runs terraform plan against our live environment. If a single resource has been changed manually – if reality ever drifts from our code – we get an immediate alert. (This is how you prove continuous compliance).

Our Disaster Recovery Is Just Another Workflow

This is the part I’m most proud of. Ask a typical CTO about their disaster recovery plan. They’ll point you to a dusty binder with a 50-page plan that was last "tested" a year ago in a theoretical tabletop exercise.

Our DR plan is a file: disaster-recovery.yml

Once a month, we point this workflow at our staging environment and run it. Here’s what it does:

1. Terraform: It systematically destroys every single server and resource. Total annihilation.

2. Terraform: It re-provisions the entire infrastructure from scratch, using the exact same code that runs our production environment.

3. Ansible: It runs restore-database.yml to pull our latest backup and restore it to the newly built database server.

4. Ansible: It runs our site.yml playbook to configure the entire environment from the ground up.

The result? We prove, every month, that we can recover from a catastrophic failure. We don't just test a backup; we test our entire business continuity process. We have a measurable Recovery Time Objective (RTO), backed by logs, not theories. (This is ISO 27001's A.17, made real and reliable).

Project Structure

.
├── .github/
│   └── workflows/
│       ├── terraform-plan.yml
│       ├── terraform-apply.yml
│       ├── ansible-deploy.yml
│       ├── terraform-drift-detection.yml
│       ├── ansible-drift-enforcement.yml
│       └── disaster-recovery.yml
├── ansible/
│   ├── site.yml
│   ├── restore-database.yml
│   ├── release-version-of-application.yml
│   └── inventories/
│       ├── staging/
│       │   ├── hosts
│       │   └── group_vars/
│       │       └── all.yml
│       └── production/
│           ├── hosts
│           └── group_vars/
│               └── all.yml
└── terraform/
    ├── main.tf
    ├── variables.tf
    ├── staging.tfvars
    ├── production.tfvars
    ├── backend-staging.tf
    └── backend-production.tf

Description

This project is organized into three main components: GitHub Actions workflows, Ansible, and Terraform.

.github/workflows/

This directory houses all GitHub Actions automation:

• terraform-plan.yml – Runs terraform plan for either the staging or main environments, depending on the pull request target.

• terraform-apply.yml – Applies Terraform changes. If the pull request targets master, it first performs a smoke test on staging.

• ansible-deploy.yml – Executes the Ansible playbook. Like Terraform apply, this workflow also smoke tests on staging when run on master.

• terraform-drift-detection.yml – A scheduled job to detect configuration drift in Terraform-managed infrastructure.

• ansible-drift-enforcement.yml – A scheduled Ansible run to ensure configuration consistency and identify any drift.

• disaster-recovery.yml – A comprehensive monthly recovery test on staging. It destroys and recreates infrastructure using Terraform, then reapplies configuration using Ansible.

ansible/

This directory manages system configuration and deployment via Ansible:

• site.yml – The main entry point for Ansible, aggregating all roles and tasks.

• restore-database.yml – A playbook focused on restoring the database.

• release-version-of-application.yml – Used to release a specific version of the application.

ansible/inventories/

Defines host inventories and environment-specific variables:

• Staging

  • hosts – Hosts inventory file for the staging environment.

  • group_vars/all.yml – Global variables for staging.

• Production

  • hosts – Hosts inventory file for the production environment.

  • group_vars/all.yml – Global variables for production.

terraform/

This directory contains the Terraform infrastructure-as-code definitions:

• main.tf – Core Terraform configuration.

• variables.tf – Defines input variables for the configuration.

• staging.tfvars / production.tfvars – Provide environment-specific values.

• backend-staging.tf / backend-production.tf – Define remote backend configurations for state management in each environment.

Stop Performing Compliance. Start Engineering It.

This system gives us more than an ISO 27001 certificate. It gives us:

• Constant Audit-Readiness: An audit isn’t a fire drill. It’s a 30-minute meeting where we walk them through our workflows.

• Bulletproof Resilience: We have absolute confidence that we can recover from disaster because we practice it routinely.

• Velocity & Freedom: Our developers can ship code faster because the path to production is secure, automated, and predictable.

We built this because we had to. Now, we want to help you do the same.

We’ve had dozens of founders and CTOs ask for the source code, the playbooks, and the strategy behind this. So, we’ve packaged it all up.

---

The ISO 27001 Accelerator Kit

Tired of the compliance consultants who charge a fortune to write you a binder of paper? Want to skip months of trial-and-error and build a system that actually works?

We're offering a complete package to get you off the races:

• The Complete Workflows: All our annotated GitHub Action .yml files for CI/CD, drift detection, and disaster recovery.

• Production-Grade IaC: Our Terraform configurations for building a secure and resilient environment on Hetzner.

• The Full Ansible Playbook: All our roles and playbooks for server hardening, deployment, and database restoration.

• A 3-Hour "Whiteboard-to-Workflow" Session: Me and you. We'll map your specific needs and get these playbooks adapted and running for your application.

This isn't just about passing an audit. It's about building a better, stronger, and more efficient tech company.

Interested in trading compliance anxiety for engineering confidence?

Reach out on LinkedIn https://www.linkedin.com/in/jknobel/

Email us: jk@datapult.dk

Buy the code: https://knobel-dk.github.io/landingpage-iso-playbooks/