Release On Demand

Published date: April 15, 2024, Version: 1.0

Overview

Release on Demand is an aspect of the Continuous Delivery Pipeline that releases new functionality immediately or incrementally based on business and customer needs.

The Agile Product Delivery describes how the ‘develop on cadence; release on demand’ dimension creates the ability to deliver valuable solutions to end users with optimal timing and frequency.

Three Questions for Product and Solution Management

When Should a Release Happen?

What elements of the solution should be released?

Which end-users should receive the release?

The Four Activities of Release on Demand

Release

  • the practices needed to deliver the solution to end users.

Stabilize and Operate

  • ensures the solution is working well.

Measure

  • how to quantify if the newly-released functionality.

Learn

  • collecting feedback and preparing for the next loop.
ROD

 

Control ID Control Description Coverage in RoD

ITGC07.Change Management

Requests for program changes and system changes (including maintenance) are standardized, logged, evaluated, prioritized and approved. The enterprise maintains a change management repository to track all requested changes, including the status of approved, in-progress and closed changes. IT Management implements system software that does not jeopardize the security of programs or the integrity of data stored on the system. Post-implementation reviews are conducted to confirm outcomes and results.

Control activities:

  1. The Change Management process/procedures are documented/updated and reviewed/signed-off by the IT owner(s) on a periodic basis

  2. All change requests are documented/logged in a change management repository which includes the description of change. The implementation plan and a backout plan are required for teams with system limitations and not able to follow risk-based automated deployments as documented in the solution development methodology.

  3. All changes are authorized by the business and/or IT owner(s) or designates(s) and medium/high risk changes are reviewed in the weekly Change/Technical Advisory Boards (CAB /TAB)

  4. All changes are tested in a non-production environment prior to production implementation. In cases where testing in a non-production environment is not possible, this is documented within the RFC

  5. Post-implementation validation is conducted and validation results are reviewed    

     

  1. Highlighted actions are covered in Release on Demand

  2. Rest of the actions are covered in Continuous Integration & Continuous Deployment

       

ITGC08.Emergency Change Management

Emergency change requests are documented and subject to formal change management procedures. A post-implementation review is conducted to confirm outcomes and results.

Control activities:

  1. The Emergency Change Management process/procedures are documented/updated and reviewed/signed-off by the IT owner(s) on a periodic basis

  2. All emergency change requests are documented/logged in a change management repository which includes the description of the emergency change

  3. Emergency changes are authorized by the business and/or IT owner(s) or designates(s). Authorization is automated for teams following risk-based automated deployments.

  4. Post-implementation validation for emergency changes validation results are reviewed

  1. Highlighted actions are covered in Release on Demand

  2. Rest of the actions are covered in Continuous Integration & Continuous Deployment

     

ITGC09.Promotion to Production

A process is established to restrict access to authorized individuals functions only for the migration of accepted solutions/software releases into production.
Control activities:

  1. Promotion to production process/procedures are documented/updated and reviewed/signed-off by the IT owner(s) on a periodic basis, for each system with a procedural SOD in place

  2. Proper segregation of duties is established between staff functions responsible for program development, promoting changes to production, and IT operational support

  1. Highlighted action is covered in Continuous Deployment & Release on Demand

  2. First action is covered in Continuous Exploration

     

ITGC13.Configuration Management and Monitoring of Configuration Change

A process is established for implementing and maintaining security configurations, and for monitoring security configuration changes.

Control activities:

  1. Security configuration management process/procedures are documented/updated and reviewed/signed-off by the IT owner(s) on a periodic basis

  2. Systems are configured in accordance with security configuration baselines/standards

  3. Changes to security configurations are monitored, and deviations are followed-up on and resolved

  1. Highlighted action is covered in Release on Demand

     

ITGC14.Job Scheduling and Monitoring

IT Management has documented and established IT operational procedures, including job scheduling changes/events and incident management processes, to ensure the integrity of batch processing.

Control activities:

  1. IT operational procedures are documented/updated and reviewed/signed-off by the IT owner(s) on a periodic basis

  2. Job schedules are maintained and batch/backup jobs are monitored

  3. Job failures are documented, followed-up on and resolved

  1. Highlighted action is covered in Release on Demand

     

ITGC15.Incident Management

IT Management has defined and implemented an incident management system such that operational issues, data integrity issues and security-related issues are recorded, analyzed, resolved in a timely manner and reported to Management.

Control activities:

  1. The incident management process is documented/updated and reviewed/signed-off by the IT owner(s) on a periodic basis

  2. Incidents are documented/logged within an incident management repository which include the description of the incident, incident analysis/diagnostics, resolution steps, historical activity and response time

  3. Incidents are assigned a priority level based on risk and impact to the organization

  4. Incidents are escalated in accordance with the incident management process

  5. Incidents are resolved on a timely basis (based on incident management process documentation) and incident tickets are closed upon verification from or with notification to the affected user(s)

  6. Service Management reports are reviewed and signed-off by the IT owner(s) on a monthly basis

  1. All actions are covered in Release on Demand

     

ITGC16.Problem Management

IT Management has defined and implemented a problem management system such that operational issues, data integrity issues and security-related issues are recorded, analyzed, resolved in a timely manner and reported to Management.

Control activities:

  1. The problem management process is documented/updated and reviewed/signed-off by the IT owner(s) on a periodic basis

  2. Problems are documented/logged within a problem management repository which include the problem description, historical activity, root cause analysis and resolution steps

Note: Problems identified through incidents, have corresponding incident tickets referenced

  1. Problems are assigned a priority level based on risk and impact to the organization

  2. Problems are resolved and problem tickets are closed

  3. Service Management reports are reviewed and signed-off by the IT owner(s) on a monthly basis

  1. All actions are covered in Release on Demand

     

ITGC17.Backup Monitoring

IT Management has implemented a strategy for cyclical backup of data and programs.

Control activities

  1. Backup and Recovery procedures are documented/updated and reviewed/signed-off by the IT owner(s) on a periodic basis

  2. Application, platform/server and database backups are performed on a scheduled basis based on backup and recovery requirements

  3. Backup jobs are monitored to ensure that the jobs run to completion without errors

  4. Backup job failures are documented, followed-up on and rectified based on business requirements

  5. Backup media are stored at an off-site location

  1. All actions are covered in Release on Demand

     

ITGC18.Backup Media Testing

The restoration of information is periodically tested.

Control activities:

  1. The backup media testing process is documented/updated and reviewed/signed-off by the IT owner(s) on a periodic basis

  2. Testing of the restoration from backup media is conducted periodically and test results are reviewed and signed-off by the IT owner(s)

  1. All actions are covered in Release on Demand

     

ITGC20.Security Event Monitoring

IT Security monitors and logs security activity at the network, platform/server, and database levels and identified security violations are reported to Management.

Control activities:

  1. Security Information and Event Management (SIEM) process/procedures are documented/updated and reviewed/signed-off by the IT owner(s) on a periodic basis

  2. Security logging is enabled at the network, platform/server and database levels and complies with Information Security standards

  3. Security logs are sent to the SIEM tool for monitoring, and security events are assessed to determine if they are security violations

  4. Security violations are documented/logged which include the description of the security violation, analysis/diagnostics, resolution steps, historical activity and response time

  5. Security violations are followed-up on, resolved by IT Security and reported to Management

  1. All actions are covered in Release on Demand

     

ITGC21.User Access Provisioning/23.Segregation of Duties

Procedures exist and are followed relating to timely action for requesting, granting, suspending and closing user accounts. Controls relating to appropriate segregation of duties (SoD) over requesting and granting access to systems and data exist and are followed.

Control activities:

  1. Identity and Access Management process/procedures are documented/updated and reviewed/signed-off by the IT owner(s) on a periodic basis

  2. User access to networks, applications, platforms/servers and databases are requested, documented and approved by the business and/or IT owner(s)

  3. User access is provisioned in accordance with roles and responsibilities, and proper segregation of duties exists for requesting and granting access to systems and data

  4. User account terminations are processed on a timely basis

  1. All actions are covered in Release on Demand

     

ITGC24.Threat and Vulnerability Management

Appropriate controls, including firewalls, intrusion prevention/detection systems and vulnerability assessments, exist and are used to prevent and detect unauthorized access to information assets.

Control activities:

  1. Networks are protected utilizing firewalls and intrusion prevention/detection systems

  2. Anti-malware software is deployed, virus definitions are up-to-date, and scans are performed to detect malware on the networks, platforms/servers and workstations

  3. Vulnerability scans and assessments are performed on a periodic basis

  4. Network penetration testing is performed on a periodic basis

  5. Vulnerability assessment and penetration testing results are documented, reviewed and signed-off by the IT owner(s)

  6. Vulnerability assessment and penetration testing issues are followed-up on, investigated and resolved based on risk and impact to the organization

  7. System security software/patches are applied in a timely manner

   

Release & Deployment process

This process document covers three variations of release, basis the nature of demand and scenario release requests can be classified as below.

Emergency Release

  • P1 or P2 incidents which initiate P1 or P2 Change can be considered for Emergency Release Management process. Delivery Lead will provide approval to qualify Emergency Release scenarios based on inputs from Business, Security, Testing and/or any dependent party. Delivery Lead approval is mandatory to trigger Emergency Release process.

Standard Release

  • Standard release are changes to a service or to any of the operational assets of the network where the implementation process and the risks are known upfront. In some cases, some standard changes are subject to established policies and procedures, they are the easiest to prioritise and implement, and often don’t require approval from a risk management perspective.

Non-Standard Release

  • Non-Standard release are those that must go through the entire change process before being approved and implemented. If they are determined to be high-risk, a change approval board must decide whether they will be implemented.