Why does Kosli need a software process? #

Regulated organizations such as banks, insurance companies, and payment platforms obtain their license to operate from a government authority. As a critical element of the country’s economy, and also to protect consumers, these organizations are required by law to manage various operational risks in their use of information technology. For example, in Norway this regulating authority is Finanstilsynet, and the applicable law is the IKT forskrift.

In other countries the laws and regulations differ, but the principle is internationally followed.

Risk Management #

Typical obligations in this framework include having processes around how IT systems change, and managing the risks associated with changes. Crucially, it is expected that there are comprehensive records of these changes, and the risk mitigations and internal controls performed as part of the changes.

This record of your changes should also contain evidence that your developers are following your process and performing risk controls.

Essentially, we must:

Define: Have a defined process for software development
Implement: Actually follow this process in our daily work
Prove: Have the proof that we conform to the process during audit

What should be in a SSDLC process? #

Generally a process should define the activities and technologies used in the development and maintenance of our software. In a regulated setting, the rationale for given controls and processes should map to the risks identified in governance.

A risk register
The areas of SSDCL
- For each area:
  - A definition
  - Risks this area controls for
  - A rationale
  - Application rule (Mandatory, Optional)

How should our SSDLC be documented? #

It should be defined and available on an internal website and stored in a version controlled system such as git.

Documenting Options and Exceptions #

Exceptions and customizations should be defined in the exception register.