Proposed Standard: Software Development Lifecycle Common Control Catalog - APPROVED

### Contribution Prerequisites

- [x] I confirm I am contributing on behalf of a FINOS member OR I will seek a maintainer from a member during socialization.
- [x] I have reviewed [Open Standard Projects governance](https://community.finos.org/docs/governance/#open-standard-projects).
- [x] I have reviewed [Establishing and Running an Open Standard project](https://community.finos.org/docs/governance/standards-projects/).
- [x] I have reviewed the [FINOS Project Lifecycle](https://community.finos.org/docs/governance/project-lifecycle) stages.
- [x] I am familiar with [FINOS Governance](https://community.finos.org/docs/governance) and [Maintainer Responsibilities](https://community.finos.org/docs/finos-maintainers-cheatsheet/).
- [x] I have reviewed the [FINOS Contribution Requirements](https://community.finos.org/docs/governance/software-projects/contribution-compliance-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.

### Tentative Roadmap

## Timeline

- Jul 2025 — Problem discussion workshop (hosted by Deutsche Bank); working group created under the FINOS DevOps Automation SIG (https://github.com/finos/devops-automation/issues/261).
- Aug 2025 — Working group kick-off.
- 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

### Existing Materials

- **Background:** [Issue #261 — Software Development Lifecycle Common Controls Catalogue Framework](https://github.com/finos/devops-automation/issues/261).
- **Introductory talk (OSFF NY 2025):** *An Open SDLC Controls Framework for Financial Services* — Aaron Searle & Toby Weston.
- **Live site:** https://finos-labs.github.io/SDLC-Controls-Framework/
- **Labs Repository:** https://github.com/finos-labs/SDLC-Controls-Framework

### Maintainers

## Maintainers

| Name | Organisation | GitHub |
|------|--------------|--------|
| Mike Long | Kosli | @meekrosoft |
| Toby Weston | Deutsche Bank | @tobyweston |
| Aaron Searle | Morgan Stanley | @aaronsearle |
| Gay Pinto | UBS | |
| Abhishek Chowdhury | UBS | @abhishek-chowdhury_ee2 |

Note: Interest from Fidelity and Natwest in becoming maintainers.
See [MAINTAINERS.md](https://github.com/finos-labs/SDLC-Controls-Framework/blob/main/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**

- **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).

### Compliance & Requirements Agreement

- [x] I understand standards projects follow the [Community Specification process](https://community.finos.org/docs/governance/standards-projects/) and should use the [FINOS Standards Project Blueprint](https://github.com/finos/standards-project-blueprint).
- [x] I understand the [IP licensing requirements](https://community.finos.org/docs/governance/standards-projects/#ip-licensing-requirements), including that all participants must agree to the CSLA.
- [x] I understand the [patent exclusion rules](https://community.finos.org/docs/governance/standards-projects/#community-specification-license-patent-exclusion-rules) in the Community Specification License process.
- [x] I understand any software included in this standards project must follow FINOS software licensing rules (Apache-2.0 unless otherwise approved).
- [x] I understand the standard project and it's participants must comply with all [FINOS policies](https://community.finos.org/docs/governance/#policies).
- [x] I understand new open standard projects are approved by the FINOS Governing Board.
- [x] I understand this proposal may require socialization with community@finos.org before final review.