Security Compliance Automation Platform

At a glance: Built and deployed a security compliance automation platform for a PCI Level 1 payments platform running across four Azure subscriptions, spanning production and non-production, automatically creating, deduplicating, and routing actionable compliance findings to the correct engineering team, with no manual ticket creation or chasing by security required.

Problem

Both security and engineering were new to Azure, and security tooling procurement was running roughly 18 months behind the pace of the Azure build-out. There was no dedicated platform in place to close that gap.

Security had their own visibility into findings through the Azure portal, but the way that got communicated to engineering was a single Jira ticket carrying Azure’s own generated PDF report, covering every finding regardless of severity. Actioning a finding from that meant either security manually creating a separate Jira ticket per finding, impractical at volume, or engineering doing it themselves from a document that wasn’t built for the purpose. Engineering needed everything tracked in Jira to log time against it, and there was no automated path to get individual findings there.

The compliance target was zero Critical or High Defender findings in production, later extended to non-production, alongside compliance with the Microsoft Cloud Security Benchmark, ISO 27001, and PCI DSS. Azure’s own risk rating for a finding changes dynamically though, something rated High on Monday could be Medium by Wednesday, so tickets raised from a point-in-time PDF were often chasing findings that had already changed.

That noise was compounded by the pace of the build-out itself. Azure infrastructure was still being built while the security requirement was being defined, so findings were frequently resolved as a side effect of ongoing engineering work before security ever flagged them. Security had no visibility into that, so tickets were regularly raised for issues that no longer existed.

Not everyone with a stake in this had access to the Azure portal, so there was no shared, real-time view of compliance posture that security, engineering, and leadership could all see. Security tracked Microsoft’s Secure Score as their headline metric and needed to demonstrate trend over time, not just a snapshot.

Some findings needed a fix delivered in Terraform, others were safe for Azure to remediate directly, and there was no reliable way to tell which was which at the point a finding was raised.

Policy exemptions were inconsistent too. Some people could raise one with no security oversight at all, others who legitimately needed to couldn’t, and there was no shared view of what was active or why.

Tech Stack

Azure - Defender for Cloud, Azure Policy, Logic Apps, Functions (Python 3.12), Key Vault, Managed Identity
Terraform - infrastructure as code
GitLab - CI/CD pipelines for deployment
Jira - automated ticket creation via API
Grafana Cloud - shared compliance dashboard

What We Did

Built real-time Teams notifications for new Critical or High Defender findings and new policy violations only, not a repeat of everything open, so alerts stayed meaningful rather than becoming daily noise.
Built two daily pollers, one for Defender findings and one for Azure Policy compliance findings, that pull directly from the Azure APIs rather than relying on manually distributed reports.
Deduplicated findings so the platform never raises a second ticket for something already being worked, and automatically closed tickets once Azure confirmed the underlying finding was resolved. This removed the ghost ticket problem and kept security’s view dynamically aligned to the engineering work already happening, rather than chasing a static snapshot.
Leveraged tag enforcement that was already in place to determine whether a resource was managed through Terraform. This mattered because auto-remediating a Terraform-managed resource directly in Azure would just get undone the next time Terraform applied. Those findings were legitimate engineering work and were routed to the team as a code fix instead.
Triggered Azure’s own auto-remediation directly for resources outside of Terraform, where it was safe to do so, closing the ticket automatically once the resource came back into compliance.
Built a Grafana dashboard giving security, engineering, and leadership a single shared view of compliance posture, including Secure Score trend over time, without needing Azure portal access.
Pulled active policy exemptions into the dashboard directly via the Azure API, so everyone could see what exemptions existed and why, closing the gap left by inconsistent exemption permissions.
Flagged findings that required a policy change at Management Group level with a distinct label, since engineering had no ability to action those directly. That kept the noise out of engineering’s queue and routed it back to the teams who actually own policy at that level.
Extended coverage to non-production environments as well, even though non-prod isn’t PCI-scoped, as an engineering decision to catch findings there before they ever reached production.
Delivered the entire platform as Terraform, deployed through GitLab CI/CD, so it was auditable and repeatable from day one rather than a bolt-on script.

Outcome

Over the first month in production, only 40 tickets were created in total across Defender and Policy findings combined, against an initial security estimate of around 800. The platform’s actionability filtering and deduplication logic removed the noise before it ever reached Jira.
In that same first month, 330 tickets were auto-closed as their underlying findings resolved, with no manual housekeeping required.
Security moved from manually creating and chasing tickets to reviewing outcomes on a shared dashboard, an advisory role rather than an operational bottleneck.
The platform proved robust and general enough that the security team is adopting it as their own product for wider use beyond this initial rollout.
For the first time, engineering had a clear picture of exactly what security expected of them, and could schedule and prioritise that work like any other, rather than it landing unpredictably from the side.
Security stopped chasing teams individually. Progress and exemptions are now covered in a single 30-minute weekly meeting against the shared dashboard, moving to a monthly touch point once the initial build-out settles, with a clear escalation path if a new finding needs attention sooner.

Client Quotes

“This is the first time in our Azure adoption that security hasn’t felt like an us-versus-them situation. This solution lets us collaborate with and guide engineering teams, rather than being seen as the ones pushing work with no notice. It’s such a simple, elegant solution that even we can maintain it ourselves, and we’re getting so much value from it that we’re rolling it out across our entire Azure estate. It’s also raising some tough questions for our security software vendors. It’s made security-led conversations easy, from board level right down to junior engineers.” — Head of Security

“One of the constant complaints from our PMs was that project schedules kept slipping because teams had to down tools to address a security finding, only to discover the work they’d done two weeks earlier had already fixed it. The disconnect between security and engineering was causing friction between teams that should have been working towards the same goal. This solution resolved that. The amount of unnecessary noise kept away from engineering, and the level of automation achieved without any AI in the loop, yet, is exceptional.” — CTO

If your security and engineering teams are working from different sources of truth, chasing the same findings twice, or losing schedule time to work that’s already been done, this is exactly the kind of problem we solve.

Get in Touch

If you’re facing similar challenges, reach out to us at hello@eiscir.com.