Building the Future of Software Delivery Controls: Inside the FINOS SDLC Governance Working Group

In October, technologists from across the financial industry gathered in New York for OSFF 2025 where the general theme was clear: open collaboration has moved from promises to proof.

Projects like Fluxnova and OpenGris showed how institutions can build shared, production-grade infrastructure. The Common Cloud Controls and AI Governance Framework demonstrated that regulatory assurance can be achieved collaboratively, not competitively.

But one layer of software governance remains fragmented — the Software Development Lifecycle (SDLC). That’s why Deutsche Bank, Morgan Stanley, and Kosli came together under FINOS to launch the SDLC Governance Working Group, a new industry initiative to define a Common Controls Catalogue for software delivery.

At OSFF Aaron Searle (Morgan Stanley) and Toby Weston (Deutsche Bank) shared the progress that has been made so far in their joint talk An Open SDLC Controls Framework for Financial Services.

Why We Need a Common Language for SDLC Governance

Every financial institution builds, changes, and releases software under regulation. Each has its own internal definitions for controls — the policies and procedures designed to mitigate risks across the SDLC, such as code reviews, deployment approvals, vulnerability scans, and audit trails.

But, as Aaron put it during the talk:

“Controls are the policies and procedures that protect our institutions. But every firm defines them differently — sometimes even different teams within the same firm.”

And this has significant consequences across businesses and the industry as a whole:

Vague requirements that are too generic to act on or too specific to scale
Baseless standards that lack shared rationale or industry validation
Subjective implementation that resists automation and standardization

Every audit becomes a bespoke conversation. Every control has to be reinterpreted. And every time a regulator or auditor asks, “How do you do code review?” — the answer is different.

As Toby observed:

“Compliance officers, developers, and auditors all talk about the same risks — but in completely different languages. That’s how good controls turn into poor ones.”

From Pull Requests to Policy: A Case Study

During the joint session at OSFF, Aaron and Toby used a deceptively simple example: the humble pull request. It’s a familiar control in nearly every development team — yet when you look closer, it means different things to different people.

To a security expert, it’s a check for vulnerabilities.
To a senior engineer, it’s a mentoring moment.
To a policy writer, it’s evidence of separation of duties.
To a developer, it’s often seen as a tax on velocity.

All of those perspectives are valid — but they’re not aligned. Even the terminology is inconsistent. Code review, peer review, never alone — all describe overlapping but distinct ideas.

“We kept using what we thought were the same words,” said Toby. “But we quickly realised we were addressing completely different risks with the same control.”

This disconnection between intent and implementation is what the working group wants to fix.
The goal isn’t to remove controls — it’s to make them clear, testable, and automatable.

How Controls Come to Life (and Why They Rarely Die)

A key insight from the session was that controls have a lifecycle — much like software. They’re created, deployed, and maintained indefinitely.

New regulations, incidents, or audit findings often trigger new controls. But, once implemented, they’re rarely revisited. The cost of maintaining and evidencing them — monitoring, sampling, logging, and reviewing — often far exceeds the effort it took to define them in the first place.

And because every institution interprets these triggers differently, duplication spreads exponentially.
As Aaron explained:

“We’re multiplying the same amount of toil across every institution. The same risks, the same debates, the same wasted energy — all because we lack a shared vocabulary.”

That fragmentation makes it harder for auditors to compare, vendors to certify, and engineers to automate. The result: governance that’s expensive, subjective, and opaque.

The Vision: A Shared, Composable SDLC Controls Catalogue

The SDLC Governance Working Group aims to solve this through an open, structured catalogue of controls. Building on the success of Common Cloud Controls (CCC) and the AI Governance Framework (AIGF), the group is defining a common language and taxonomy that can be adopted, composed, and referenced by all.

Each control in the catalogue will include:

A clear definition with real-world implementation examples
The specific risks it mitigates
Measurement and audit criteria to enable automation
Cross-references to existing frameworks such as NIST, SALSA, and regulatory standards

By agreeing on language, institutions can start to agree on evidence. That means fewer one-off audits, faster reviews, and more consistent automation.

“Imagine a world where an auditor asks if you meet Control 673 in the FINOS SDLC Catalogue,” said Toby,” “You say ‘yes,’ and they know exactly what that means — because every bank uses the same definition.”

Building Together: From Banks to Vendors

Kosli’s role in the group is to help bridge the engineering and governance worlds — ensuring the language of controls can be implemented and evidenced programmatically.

Our experience automating software delivery evidence helps translate policy into data — making it possible to verify compliance continuously, not just annually. That’s crucial for controls to move from “written” to “provable.”

The catalogue will also create a foundation for vendors. If platforms like GitHub, GitLab, or ServiceNow can reference standard controls, firms can build on top of trusted primitives rather than reinventing them.

“Imagine if platforms could certify against the FINOS SDLC Controls,” said Aaron.
“Auditors could audit once at the platform level, and every team using it inherits that assurance.”

That vision — controls as shared, testable, reusable components — is how we make governance scalable.

A Call for Collaboration

The FINOS SDLC Governance Working Group is open to everyone in the industry. Whether you’re a policy author, platform engineer, auditor, or developer, your perspective matters.

“Developers are often left out of policy discussions,” said Aaron. “If you’re affected by controls, you should help define them.”

The group meets bi-weekly under the FINOS DevOps Automation SIG. Early participants from Deutsche Bank, Morgan Stanley, Kosli, JFrog, and GitLab are already shaping the catalogue’s first entries — focusing on foundational controls such as binary provenance and peer review.

Like all FINOS initiatives, the work will be open, composable, and designed to evolve with the industry.

What Comes Next

In a year where FINOS projects like Fluxnova and the AI Governance Framework 2.0 proved the ROI of openness, the SDLC Governance Working Group adds a missing piece: shared controls for how software is built and changed.

If open collaboration can deliver shared infrastructure, it can also deliver shared assurance — reducing audit cost, improving developer productivity, and building trust between institutions and regulators.

For Kosli, building this shared understanding out in the open achieves a significant milestone. We’ve always believed compliance shouldn’t slow teams down — it should document their speed safely. By helping establish this industry-wide foundation, we’re turning that belief into something measurable.

As Toby summed up:

“This is a common language of confidence. From developers to compliance officers — everyone should be able to say not just that a control exists, but that it works.”

Join the Working Group

👉 FINOS SDLC Governance Working Group – Join Here

To share your insights, attend a meeting, or contribute examples, connect via the FINOS mailing list or Slack channel under the DevOps Automation SIG.