This article is based on insights shared by F5 systems engineer Scott Van Kalken, who works with government organisations at multiple levels across Australia. The original piece was published on devops.com.
Why Government and DevOps Are a Natural Fit
At first glance, bureaucratic government agencies and the agile world of DevOps seem like an unlikely pairing. But according to Van Kalken, the missions are closely aligned: government organisations exist to deliver services to the community, and DevOps is fundamentally about delivering reliable, iterative services to a community of users.
Van Kalken’s observation—drawn from working with agencies at local, state, and federal levels in Australia—is that government entities are, in some respects, further along the DevOps maturity curve than their private-sector counterparts. The reasons are structural, cultural, and regulatory, and each offers a lesson for enterprises that are still siloed or struggling to embed security into their delivery pipelines.
Shift-Left Security in Practice
One of the clearest indicators of DevOps maturity is how early security is introduced in the software delivery lifecycle. In government agencies that Van Kalken works with, security is no longer an afterthought bolted on at the end of a project—it is embedded from day one. This “shift-left” approach means vulnerabilities are caught earlier, when they are cheaper and faster to fix, and compliance evidence is generated continuously rather than assembled in a last-minute audit scramble.
The COVID-19 pandemic provided a real-world stress test. As remote-working mandates took effect, government departments had to scale their infrastructure rapidly and securely. Van Kalken cited one large department that expanded its remote workforce from 1,000 to 20,000 people in three to four days. This was possible, he said, because the department automated virtually every step of its infrastructure and security policy deployment, using DevOps practices to spin up cloud capacity with the correct security configuration already baked in. Teams also used APIs to apply security policies to SaaS applications quickly and consistently.
Cross-Functional Collaboration Without Turf Wars
Van Kalken described a government department that was new to DevOps but excelled at something many experienced DevOps organisations still struggle with: getting all the relevant stakeholders—development, operations, security, and policy—into the same room and focused on a shared outcome. There were no territorial disputes over ownership. Security requirements were treated as part of the definition of “done,” not as a separate workstream.
In contrast, private-sector organisations often remain siloed. Development teams optimise for feature velocity, security teams focus on compliance, and operations teams manage uptime—each with different KPIs and sometimes competing incentives. This fragmentation leads to the classic late-stage security review that slows delivery and introduces rework.
The shift Van Kalken describes is a change in the role of the security function itself: from gatekeeper—what he colourfully likens to a nightclub bouncer whose default answer is “no”—to a collaborative partner embedded in the delivery team.
Regulatory Alignment as an Unlikely DevOps Accelerator
Most enterprises adopt one of the common security frameworks (such as NIST CSF, ISO 27001, or SOC 2) and then leave individual project teams to interpret how to comply. That flexibility can breed inconsistency.
Australian government agencies operate under a mandatory baseline: the Australian Government Information Security Manual (ISM), published by the Australian Signals Directorate. Because every department must meet the same minimum bar, there is a built-in alignment that reduces the negotiation overhead between teams. Shared standards create a shared language, and that accelerates cross-departmental DevSecOps collaboration.
Private-sector organisations that choose a framework and then apply it inconsistently across business units could benefit from enforcing a single, organisation-wide baseline—even if it is stricter than the minimum any given project requires.
Speed as a Security Tool
Government systems hold sensitive personal data and are actively targeted by both opportunistic attackers and nation-state actors. Van Kalken notes that government agencies face the same threat landscape as banks and large retailers, with the added dimension of politically motivated attacks.
DevOps practices help agencies respond faster than traditional change-management processes allow. Concrete examples include:
- Automated policy deployment: New firewall rules or access-control policies can be pushed to distributed infrastructure in minutes rather than days, using infrastructure-as-code and CI/CD pipelines.
- Faster patch cycles: Automating the testing and deployment of commercial software updates reduces the window between a CVE disclosure and a patched production environment.
- Freed-up expertise: When routine policy changes are automated, skilled security engineers can focus on anomalies and higher-order threats rather than repetitive manual tasks.
“That element of speed is something very new to the security space,” Van Kalken said—and it is precisely where DevOps practices offer the most immediate, tangible security benefit.
Actionable Recommendations for Private-Sector Teams
Van Kalken’s advice distils down to four practical steps that any organisation can begin implementing regardless of its current DevOps maturity:
- Bring security in from day one. Include security engineers in project kick-offs, sprint planning, and architecture reviews—not just in pre-release gates.
- Align on a shared objective. Every team member, regardless of function, should be able to articulate the outcome the project is trying to achieve and why security is part of that outcome.
- Swim in the same direction. Eliminate competing KPIs that reward one team for speed at the expense of another team’s compliance metrics.
- Sustain collaboration continuously. Cross-functional alignment is not a kickoff exercise—it requires ongoing communication, shared tooling, and joint retrospectives.
“The rest will just happen if you do these things,” Van Kalken said. The implication is that most of the friction in DevSecOps adoption is organisational, not technical.
Key Takeaway
The stereotype of government as a slow-moving technology laggard does not hold universally. In Australia, at least, some agencies are demonstrating that a laser focus on service delivery, mandatory security standards, and genuine cross-functional collaboration can produce DevOps outcomes that private enterprises are still aspiring to. The lesson is not to copy government bureaucracy—it is to copy government’s clarity of mission and commitment to shared security ownership.