You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have reviewed the FINOS Contribution Requirements and understand the intellectual property and licensing expectations for standards projects
FINOS Member Organization Name
Morgan Stanley
Name
Software Development Lifecycle Common Control Catalog Note: This is a rename from the current labs project which was "SDLC-Controls-Framework"
Slug
sdlc-common-controls
Business Problem
The financial services industry is navigating an increasingly complex and fast-evolving regulatory landscape. As software development accelerates to meet business demands, the controls and governance frameworks required to ensure quality, security, and compliance are also growing in both volume and complexity.
Regulators, governments, and industry bodies are issuing more detailed and prescriptive guidance, placing greater scrutiny on software development practices. At the same time, institutions striving to lead in innovation and client protection often go beyond baseline requirements, implementing additional controls to demonstrate excellence in software quality, reliability, and security.
Additionally when it comes to guidance, existing handbooks and policies tend to focus on the risks themselves or leave significant flexibility open in terms of interpretation as well as implementation.
This leads to the following problems:
Duplication: Each institution is interpreting, writing and developing their own set of SDLC controls. Each institution then spends significant time testing/auditing those definitions and implementations.
Drift: Given the room for interpretation and also the desire to keep ahead and be proactive means that there is significant drift across institutions that lead to wasted effort overall.
Fragmentation: Institutions and vendors often develop their own terminologies and frameworks, making collaboration and benchmarking difficult.
Proposed Solution
To address these challenges, we are building the SDLC Common Controls Catalog, a shared and open reference library for software governance controls, published at https://finos-labs.github.io/SDLC-Controls-Framework/.
This allows us to share common interpretations and common controls, and to converge on the language used to define, explain, and evidence compliance with a given control. Even simply sharing the language has the potential to save significant time and help generate convergence.
The catalog is organised as a reusable taxonomy of risks and the mitigations (controls) that address them. Each is written to a consistent structure with an intent, requirements, evidence expectations, and example patterns of implementation. These are then mapped to their underlying risks as well as examples where industry frameworks and regulatory guidance reference them.
We have learnt through collaboration that it is unlikely that an entire SDLC policy would become common between the institutions involved, their starting point and history is often to far apart and their needs are often specific to their own environment, and regulatory landscape As such the framework is deliberately composable: a library/catalog where institutions pick and reference the controls most applicable to them, while setting aside those that do not apply or that they have mitigated via other means.
The catalog is now in active development by a cross-industry working group.
Sep 2025 — Second workshop (hosted by Deutsche Bank): review of similar work (AI Governance Framework, CCC, CSA CSM), repo/project setup, initial taxonomy and first test control.
Oct 2025 — OSFF New York talk and workshop: An Open SDLC Controls Framework for Financial Services.
Feb 2026 - Onsite workshop in London (hosted by Morgan Stanley)
June 2026 - OSFF London workshop: ;First Reading' for getting controls into 1.0
2026 — Ongoing bi-weekly delivery: expanding the catalog, refining control language, and progressing controls through the governance lifecycle toward working-group approval.
Near term (H2 2026)
Progress the drafted catalog through the governance lifecycle — move the ready controls from draft to working-group approval using the readiness checks, prioritising those with complete cross-references and regulatory mappings.
Close known content gaps - mitigations identified as missing or incomplete (e.g. insider-threat mitigations, additional software supply chain risks and mitigations) and the risk/control backlog refinement lists.
Definitions & shared language - publish the glossary of terms (e.g. "released" vs "production") that underpins consistent control language.
Meta controls - add cross-cutting controls raised at the June 2026 OSFF workshop: managed control exceptions (oversight and visibility of exceptions) and evidence retention (approved stores, retention strategy).
Adoption guidance - a document describing what adopting the framework looks like inside an institution: how to select, reference, and evidence controls from the catalog
Complete Risk Catalog - Mitigation definitions are more complete than the risk list, continue to expand as we review upon risks
Link/Associate To Regulatory Guidelines - While we have been linking to industry standards we would like to also link to some of the regulatory guidance that tends to be the starting point for controls definitions.
Emerging topics - extend the framework to areas the working group has begun discussing, such as controls for agentic/AI-assisted software development.
Medium term (6-12 months)
Deepen regulatory and standards mapping — extend the per-control references to regulatory guidance and industry standards so institutions can trace each control to the requirements it evidences.
Broaden institutional participation — grow the contributor and maintainer base across more financial institutions and vendors, building on the 10+ institutions already engaged through workshops.
Reference implementations — expand example implementation patterns for approved controls so the catalog serves implementers as well as policy owners.
Interoperability — maintain compatibility with adjacent FINOS work (AI Governance Framework, Common Cloud Controls) in schema and terminology.
Scope
The SDLC Common Controls Catalog is scoped to software delivery in regulated industries focusing on financial services. The aim is to cover all phases of the software delivery lifecycle and the supervision that take place upon those artefacts in order to ensure that appropriate risks are mitigated and evidence provided to demonstrate the oversight has taken place. The phases include from requirements through development, build, test, and release, up to and including runtime checks on the delivered artifacts.
Current State
Current Progress (as of July 2026)
11 risks defined.
20 controls (mitigations) drafted, spanning requirements, version control, testing, vulnerability management, dependencies, provenance, inventory, deployment gating, and code review — with the first control having passed its first reading.
A defined control governance lifecycle (submit → review → merge as draft → discuss/refine → approve) and an automated readiness check supporting progression to approval.
References
Note: Interest from Fidelity and Natwest in becoming maintainers.
See MAINTAINERS.md for the current list of participating organisations and maintainers.
Organisational coverage: based on affiliations participants have stated within the repositories (maintainer records, proposals, profiles, and comments), organisations represented among contributors and discussion participants include financial institutions such as Morgan Stanley, Deutsche Bank, UBS, Fidelity, and TD Bank, and technology, consulting, and open-source organisations such as Kosli, JFrog, Anchore, Chainloop, Scott Logic, Xodiac, trigosec, VirtusLab, and KPMG.
Target Participants
Who we want involved
From financial institutions
Control owners & SDLC policy officers - These own the controls themselves will be facing the burden but will also have the ability to share their experience on control definition as well as being able to adopt/affect changes their respective organisations
Platform / DevOps engineers - implement and evidence controls; keep them actionable with a focus on automation and the controls themselves being achievable. This is key to avoid this becoming a purely paper exercise.
Technology risk & compliance (second line) - confirm controls mitigate the stated risks and evidence would survive an exam. This is a gap within the current contributor list.
Internalauditors - Useful to be able to ensure that risks are mitigated well, the language will hold up to scrutiny and that the suggested evidence requirements are sufficient.
From the wider industry
Regulators & External Auditors - Ideally involvement from former or present regulator representation.
Governance & supply chain tooling vendors — implementation reality and reference integrations, as well as experience over a breadth of the industry. Also help ideally to include these controls within their own products where possible/applicable. We have good coverage today Kosli, JFrog, Anchore, Chainloop).
Contribution Prerequisites
FINOS Member Organization Name
Morgan Stanley
Name
Software Development Lifecycle Common Control Catalog
Note: This is a rename from the current labs project which was "SDLC-Controls-Framework"
Slug
sdlc-common-controls
Business Problem
The financial services industry is navigating an increasingly complex and fast-evolving regulatory landscape. As software development accelerates to meet business demands, the controls and governance frameworks required to ensure quality, security, and compliance are also growing in both volume and complexity.
Regulators, governments, and industry bodies are issuing more detailed and prescriptive guidance, placing greater scrutiny on software development practices. At the same time, institutions striving to lead in innovation and client protection often go beyond baseline requirements, implementing additional controls to demonstrate excellence in software quality, reliability, and security.
Additionally when it comes to guidance, existing handbooks and policies tend to focus on the risks themselves or leave significant flexibility open in terms of interpretation as well as implementation.
This leads to the following problems:
Proposed Solution
To address these challenges, we are building the SDLC Common Controls Catalog, a shared and open reference library for software governance controls, published at https://finos-labs.github.io/SDLC-Controls-Framework/.
This allows us to share common interpretations and common controls, and to converge on the language used to define, explain, and evidence compliance with a given control. Even simply sharing the language has the potential to save significant time and help generate convergence.
The catalog is organised as a reusable taxonomy of risks and the mitigations (controls) that address them. Each is written to a consistent structure with an intent, requirements, evidence expectations, and example patterns of implementation. These are then mapped to their underlying risks as well as examples where industry frameworks and regulatory guidance reference them.
We have learnt through collaboration that it is unlikely that an entire SDLC policy would become common between the institutions involved, their starting point and history is often to far apart and their needs are often specific to their own environment, and regulatory landscape As such the framework is deliberately composable: a library/catalog where institutions pick and reference the controls most applicable to them, while setting aside those that do not apply or that they have mitigated via other means.
The catalog is now in active development by a cross-industry working group.
Tentative Roadmap
Timeline
Near term (H2 2026)
Medium term (6-12 months)
Scope
The SDLC Common Controls Catalog is scoped to software delivery in regulated industries focusing on financial services. The aim is to cover all phases of the software delivery lifecycle and the supervision that take place upon those artefacts in order to ensure that appropriate risks are mitigated and evidence provided to demonstrate the oversight has taken place. The phases include from requirements through development, build, test, and release, up to and including runtime checks on the delivered artifacts.
Current State
Current Progress (as of July 2026)
11 risks defined.
20 controls (mitigations) drafted, spanning requirements, version control, testing, vulnerability management, dependencies, provenance, inventory, deployment gating, and code review — with the first control having passed its first reading.
A defined control governance lifecycle (submit → review → merge as draft → discuss/refine → approve) and an automated readiness check supporting progression to approval.
References
Existing Materials
Maintainers
Maintainers
Note: Interest from Fidelity and Natwest in becoming maintainers.
See MAINTAINERS.md for the current list of participating organisations and maintainers.
Confirmed Participants
Contributors
Code and documentation contributors (GitHub): @aaronsearle, @meekrosoft, @AlexKantor87, @tobyweston, @kaysavps, @anupriya-goyal, @germanptr, @ColinEberhardt, @petermaddison, @jorok, @shanewidanagama, and @vidhu-balad.
Discussion participants (recurring engagement across pull requests, proposals): @carmithersh, @joshbressers, @cavanap, @migmartri, @jwadhwa5000, @ArturSkowronski, @d1gital-f, and @creativeview
Organisational coverage: based on affiliations participants have stated within the repositories (maintainer records, proposals, profiles, and comments), organisations represented among contributors and discussion participants include financial institutions such as Morgan Stanley, Deutsche Bank, UBS, Fidelity, and TD Bank, and technology, consulting, and open-source organisations such as Kosli, JFrog, Anchore, Chainloop, Scott Logic, Xodiac, trigosec, VirtusLab, and KPMG.
Target Participants
Who we want involved
From financial institutions
From the wider industry
Compliance & Requirements Agreement