Proposal: Software Development Lifecycle Common Controls Catalogue Framework

# Software Development Lifecycle Common Controls Catalogue Framework

## 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 propose the creation of a Software Development Lifecycle (SDLC) Controls Catalogue Framework—a shared and open reference library for software governance controls.

This will allow for us to share common interpretations or common controls as well as converge around common language used to define, explain and evidence compliance to a given control. Even simply sharing the language has the potential to save significant time.

The proposal, (much like http://sdlc.kosli.com), is to form a framework that tiers controls, the associated risks they mitigate and example patterns of implementation into a reusable taxonomy that allows us to share existing controls as well as determine/refine new ones to be referenced from policies and documentation within each institution.

It is unlikely that an entirely SDLC policy would become common between the institutions involved which is why it was decided that the best approach would be in the form of a library/catalog, where institutions could pick and reference those that are most applicable while setting aside those that do not apply or they have mitigated via other means.

## Primary Objectives
- Establish a common language and taxonomy for software controls.
- Provide a catalogue of reference implementations and control examples.
- Enable collaboration and contribution across institutions & vendors.
- Reduce duplication and drift by promoting reusability and consistency.

## Target Audiences

### Primary Users
- Platform Engineers / Control Implementers
- Control Owners
- Internal and External Auditors

### Secondary Stakeholders
- Regulatory Bodies
- Vendors of Software Governance Software
- Risk and Compliance Teams

## Tentative Roadmap

### Short-Term (0–6 Months)
- Launch a dedicated GitHub repository to host the framework and enable community contributions.
- Define the initial structure and taxonomy for the catalogue.
- Develop a collaborative website for documentation, discussion, and engagement.
- Identify and onboard early contributors and institutional representatives.

### Medium-Term (6–12 Months)
- Populate the catalogue with core control domains, focusing on areas of high commonality (e.g., peer review, change management, requirements oversight).
- Expand to include institution-specific and advanced controls.
- Begin mapping controls to regulatory requirements and industry standards.

## Current State
Initial discussion has taken place broadly on this topic and there is a clear common desire to reduce the overall overhead of maintaining, developing and explaining control definitions.

A small offsite took place to explore the subject, compare notes and opinions on the institutional differences and commonality when it comes to policy. The outcomes of this workshop were:

### Agenda: 2025/06/24
1. **Discuss stakeholders, the conceptual problem and whether or not this is a realistic undertaking.**

It was agreed that this is indeed a common problem and that the amount of work in this area continues to grow and likely that the institutions are growing in their divergence. A draft "definition" of the problem statement was compiled:

> For the Financial Services Industry and their Regulators,
> whose articulation of risks and controls are distributed and inconsistent and ambiguous and duplicative across each institution, this causes inefficient and ineffective risk mitigation, inefficiency causes unnecessary costs, ineffective causes market impacts. Societal or financial impact might be that if we do mitigate risks we may not be able to demonstrate that we have (evidence), we can’t measure.
> the Common Control Standards SIG
> is a consortium of interested parties…
> that aim to provide standard catalogue, patterns and definitions in and around software supply chain risks and their mitigation… because in doing so, we believe it will solve the problems above. FIs, Regulators and stakeholders can have a shared language and understanding
> Different from status quo (where teams have inconsistent and bespoke processes/procedures),
> our working group will… create a common framework for sharing control definitions and example implementation

2. **Highlight any degree of high-level overlap between the institutions present for an example control**

We determined that there was significant drift already in the language and grouping of different controls. As well as their ownership within the organizations. However; we determined that some of the fundamentals were common even if our definitions in terms of language differed significantly.

3. **Begin defining one control, its risks and the implementation**

As an exercise to see how feasible this kind of discussion around a common controls framework would be we started with the principle of "never alone", also referred to or overlapping with 4-eyes check, maker-checker and peer review. This meant unpacking our own understanding of the controls and narrowing it down to a clearer definition that could be reused within existing controls but sizeable enough to be defined on its own.

## Existing Materials
- **Kosli SDLC Controls Reference** - [http://sdlc.kosli.com](http://sdlc.kosli.com)
This site represents more of an implementation story, but gives a similar idea of presenting the controls that are available. It does not mention the risks, nor (since it is not a financial institution) cover the breadth of what we need to demonstrate, but is a very good start.

- **air-governance-framework.finos.org**
A similar idea conceptually, we can reuse the layout/UI, though this is more of a focus on the higher level and more fundamental SDLC risk, controls and implementations.

- **Concepts such as SLSA** overlap, but are limited to software provenance and software supply chain only rather than the broader SDLC governance context.

## Maintainers
- **Aaron Searle** - Morgan Stanley [@aaronsearle](https://github.com/aaronsearle)
- **Mike Long** - Kosli [@meekros](https://github.com/meekrosoft)
- **Toby Weston** - DB [@tobyweston](https://github.com/tobyweston)
- [Steve](https://github.com/tooky)
- [Sofus](https://github.com/sofusalbertsen)
- [Alex](https://github.com/alexkantor87)
## Potential Contributors

TODO: Mike to add other members