S.No.

Assessment Question

Has a formal Change Management process documented and

1 implemented?
(Provide the latest copy of Change Management procedure)

Does there exist a policy document on the creation of a Change

Advisory Board highlighting their responsibilities?
Has a Change Advisory Board (CAB) been created to oversee the
creation and maintenance of Change Management Process? If
2
Yes, are roles & responsibility of CAB documented and shared
with CAB members?
(Provide list of members of CAB along with Roles &
responsibilities)

Are roll-back strategy prepared prior to implementation of all

technology changes? If Yes, are these strategies documented and
3 maintained?

(Provide artifacts for a sample change)

Does a separate Testing and Development Environment exist for

the application / system? If Yes, are all changes developed and
tested in non-production environment before implementation on
4
production / live environment?

(Provide relevant artifacts)

 What is the frequency of the review of the separation of
development, testing and operational environments? Does there
5
exist a compliance review with a policy related to secure
development environment?

Is User Acceptance testing (UAT) performed for changes to

ensure that only approved changes are implemented in the
6
environment?
(Provide UAT results for a sample change)

Are review performed to ensure that all information security

requirements have been met before implementing change on
7
production environment?
(Provide review results for a sample change)

Does there exist a compliance audit to ensure if technology

changes are tested in accordance with the System Development
8
life cycle and Infrastructure Development life cycle processes? If
YES, what is the frequency of such audits?
 How are promotion of changes from non-production to
production environments restricted to users with no
9
responsibilities for developing or testing the technology
solutions?

Is the scheduling of the approved technology changes during the

10 change management process based upon criticality and/or the
level of risk

Are technology production changes allowed to be implemented

11 during business hours? If No, what is approved time-window for
implementation of such changes?

Is User Acceptance testing (UAT) performed for changes to

ensure that only approved changes are implemented in the
environment?
12 Does the initiator sign-off is required before implementation of
changes onto production environment?

(Provide UAT results for a sample change)

What is the frequency of review of Business Continuity and

Disaster Recovery Plans for inclusion of updates during the
13
change management process?
(Provide results for sample review conducted)

Is atleast a two level of management's approval taken for the

14 emergency change management requests?
(Provide relevant artifact for a sample Emergency Change)

Are access rights granted to process an emergency request have

15 been revoked once the emergency request has been processed?
(provide artifacts for a sample emergency change)
 Are all documentation & approval of emergency requests during
implementation of the emergency change management process
16
approved within 48 hours?
(Provide artifacts for sample a emergency change)

Has an inventory / documentation of Configurations for all assets

developed and maintained?
17
(Provide sample documentation)

Are the all changes reviewed and approved by appropriate

technology and business management?
18
(Provide artifacts for a sample change)

How is the logging and monitoring of modifications made to

19 information systems ensured? Where are the change logs
maintained?

Is pre-assessment activity carried out to identify potential

impacts, including information security impacts before
20 implementing a change? If Yes, how are gaps / exceptions
identified during the assessment exercise handled?
(provide artifacts for a sample change)

Has a formal approval matrix for all categories of changes

developed and implemented? If Yes, How do you ensure that all
21
changes are approved as per defined approval matrix?
(Provide approval matrix for all types of changes)

22 What details of change is communicated to all relevant persons?

Required Control Description ISO 27002 Ref No.

Organization should develop and implement a formal change A.12.1.1

management process to ensure that unauthorized changes are not A.12.1.2
implemented on the system. A.12.1.3

A Change Advisory Board (CAB) must be created and implemented

A.12.1.1
by the businesses and business partner groups.CAB must oversee
A.12.1.2
the creation and maintenance of the Change Management Process
A.12.1.3
(CMP) and an Emergency Change Management Process.

The Change Management process must ensure that a roll-back A.12.1.1

strategy is developed and in place prior to implementing technology A.12.1.2
changes. A.12.1.3

The Change Management process must ensure that any technology

changes are developed and tested in non-production environments
to ensure that:
a. approved security design specifications—including functional A.14.2.6
and technical requirements—have been met; A.12.1.4
b. secure software development and hardening of hardware and A.14.2.1
infrastructure assets has been validated;
c. information security requirements have been met; and
d. user access has been segregated on a need-to-know basis.
The Change Management process must ensure that any technology
changes are developed and tested in non-production environments
to ensure that:
a. approved security design specifications—including functional A.14.2.6
and technical requirements—have been met; A.12.1.4
b. secure software development and hardening of hardware and A.14.2.1
infrastructure assets has been validated;
c. information security requirements have been met; and
d. user access has been segregated on a need-to-know basis.

The Change Management process must ensure that any technology

changes are developed and tested in non-production environments
to ensure that:
a. approved security design specifications—including functional A.14.2.6
and technical requirements—have been met; A.12.1.4
b. secure software development and hardening of hardware and A.14.2.1
infrastructure assets has been validated;
c. information security requirements have been met; and
d. user access has been segregated on a need-to-know basis.

The Change Management process must ensure that any technology

changes are developed and tested in non-production environments
to ensure that:
a. approved security design specifications—including functional A.14.2.6
and technical requirements—have been met; A.12.1.4
b. secure software development and hardening of hardware and A.14.2.1
infrastructure assets has been validated;
c. information security requirements have been met; and
d. user access has been segregated on a need-to-know basis.

The Change Management process must ensure that all technology

changes are tested in accordance with the System Development life A.12.1.2
cycle and Infrastructure Development life cycle processes defined A.12.1.4
by the businesses and business partner groups.
The Change Management process must ensure that all promotion
of changes from non-production to production environments are
A.12.1.4
restricted to users with no responsibilities for developing or testing
the technology solutions.

The Change Management process must ensure that all approved

technology changes are scheduled based upon criticality and/or the A.12.1.2
level of risk prior to promotion to production, and are A.12.1.3
communicated to the appropriate businesses and business partner A.12.1.4
groups.

The Change Management process must ensure that technology

production changes are not made during business hours identified
by the business and business partner stakeholders that will
A.12.1.2
negatively impact the change or the business and are made within
the change management timeframes established by the clients and
third parties.

The Change Management process must ensure that any business

and business partner group stakeholders initiating the change
A.12.1.2
request verify the change implementation and sign-off on the
acceptance of it.

The Change Management process must ensure that all system A.12.1.2
changes include updates to the appropriate Business Continuity A.17.1.1
and Disaster Recovery Plans and systems. A.17.1.2

The Emergency Change Management process must ensure that any

emergency change management requests must be approved by at A.12.1.2
least two levels of management.

The Emergency Change Management process must ensure that any

access rights granted to process an emergency request adhere to A.12.1.2
the Privileged User Administration Standard and are revoked once A.9.2.3
the emergency request has been processed.
The Emergency Change Management process must ensure that
A.12.1.1
emergency requests are documented and approved within 48 hours
A.12.1.2
of the emergency change being implemented.

Change Management and Configuration Management processes

must require an inventory of assets and documentation of
A.12.1.2
configurations.

Change Management and Configuration Management processes

must ensure that implementations are reviewed and approved by
A.12.1.2
appropriate technology and business management.

Change Management and Configuration Management processes

A.12.1.2
must require logging and monitoring of modifications.

Assessment of the potential impacts, including information security

A.12.1.2
impacts should be identified before implementation of change.

Formal approval procedure for proposed changes should be

A.12.1.2
defined.

Communication of change details to all relevant persons should be

A.12.1.2
done
Risk

Lack of documented change management process leading to

implementation of un-authorized changes on production
environment.

Lack of change management governing body leading to

implementation of un-authorized changes on production
environment.

In case a planned change management implementation fails then

lack of a roll-back strategy might lead to unavailability of the
application, delays in recovering.

Lack of frequent review of the separation of development, testing

and operational environment could potentially mean that security
design specifications—including functional and technical
requirements—have not been met and not detected, secure
software development and hardening of hardware and
infrastructure assets have not been validated and not detected,
information security requirements have not been met and not
detected, user access has not been segregated on a need-to-know
basis
Lack of frequent review of the separation of development, testing
and operational environment could potentially mean that security
design specifications—including functional and technical
requirements—have not been met and not detected, secure
software development and hardening of hardware and
infrastructure assets have not been validated and not detected,
information security requirements have not been met and not
detected, user access has not been segregated on a need-to-know
basis

Lack of frequent review of the separation of development, testing

and operational environment could potentially mean that security
design specifications—including functional and technical
requirements—have not been met and not detected, secure
software development and hardening of hardware and
infrastructure assets have not been validated and not detected,
information security requirements have not been met and not
detected, user access has not been segregated on a need-to-know
basis

Lack of frequent review of the separation of development, testing

and operational environment could potentially mean that security
design specifications—including functional and technical
requirements—have not been met and not detected, secure
software development and hardening of hardware and
infrastructure assets have not been validated and not detected,
information security requirements have not been met and not
detected, user access has not been segregated on a need-to-know
basis

Lack of an audit of compliance to the System Development life

cycle and Infrastructure Development life cycle processes could
potentially mean that risks to all such processes are not being
detected and that they could be ineffectiveness.
Lack of frequent review of the separation of development, testing
and operational environment could potentially mean that security
design specifications—including functional and technical
requirements—have not been met and not detected, secure
software development and hardening of hardware and
infrastructure assets have not been validated and not detected,
information security requirements have not been met and not
detected, user access has not been segregated on a need-to-know
basis

If the approved technology changes during the change

management process are not scheduled based upon criticality
and/or the level of risk then potentially some high critical changes
might be delayed

Inadequate change implementation process leading to disruption

of services.

There would be no way of knowing if the implemented changes

have met the indented end results without a verification and
acceptance of the change from the change requestor, leading to the
issue or risk still being open.

In the event of a disaster, essential business processes and

information systems shall not be recovered in a timely manner.
Lack of business continuity plans may lead to increased impact of
service interruption.

Even in cases of emergency at least some management approval

must be taken to ensure that legitimate emergency changes are
implemented

Any access rights granted to process an emergency request should

be revoked once the emergency request has been processed to
ensure that all such access isn't used for unauthorized activities.
Lack of a swift approval process for all emergency changes if not
documented and approved in a reasonable amount of time could
lead to all such emergency changes being ineffective and may lead
to increased impact of service interruption.

If application software is not configured appropriately, control

activities within the significant flows of transactions may be
ineffective and systems may not function in a manner that is
consistent with management's intentions.

If changes are not reviewed post implementation, control activities

within the significant flows of transactions may be ineffective and
systems may not function in a manner that is consistent with
management's intentions.

If logging and monitoring of modifications made to information

systems are not administered appropriately, significant
information resources may be modified inappropriately, disclosed
without authorization, and/or are unavailable when needed (e.g.,
they may be deleted without authorization). Furthermore, such
security breaches may go undetected.

Lack of pre-assessment activity making system vulnerable to

security threads and other potential impact, post implementation
of changes.

Lack of documented approval matrix leading to implementation of

un-authorized changes on production environment.

Lack of documented approval matrix leading to implementation of

un-authorized changes on production environment.