Find Resources and Connect with members on topics that interest you.

Applications

Audit

Business Processes

Career Management

Cloud Computing/Virtualization

COBIT

Controls and Monitoring

Country

Databases

Fraud and Computer Crime

Governance and Management

Industry

Information Security

IT Service Management

Mobile/Wireless

Operating Systems

Privacy/Data Protection

Regulations

Risk

Standards

AI - Acquire and Implement

PO - Plan and Organize

DS - Deliver and Support

ME - Monitor and Evaluate

Application Controls

Process Controls

Please sign in to see your topics.

Subscribe to this discussion

Data change control

Is it a normalpractice for a company to perform direct data changes (this means changes made todata files outside of normal processes and procedures, using tools as SQL)?

This seems to beout of the scope of CobiT Process AI6 Manage Changes. 

How does CobiT deal withwith this? 

Posted by Gustavo Solis on March 4, 2011 02:38PM
You must sign in to rate content.
(Unrated)

Comments

RE: Data change control

Hi,

It is definitely not normal to make changes to data files outside of change management processes and procedures, but it is quite possible and normal to make changes to data using SQL without using the application interface.

In the consideration of Cobit, you should make sure that such changes are placed under the control of your change management process. It means that the change must be analyzed, authorized, tested before being implemented and that there is a rollback plan. In this particular case, testing and rollback planning are extremely important as the change is not done through the application interface and thus will have a much higher risk. Also, only authorized people should have the technical access right required to make such change.

---
IT governance by examples at http://agileskills2.org/ITGBE/
Kent Tong at 3/10/2011 7:37:51 AM
You must sign in to rate content.
(1 ratings)

RE: Data change control

It wouldn't be advisable (in fact, would be very dangerous) for any company to alter production data outside of defined processes.

A small addition to above response is that a log of changes made (including who made them) should be automatically created and saved in a secure environment. A common ID should not be used to make these changes. Any change made must be made with authorised documented approval, with the approval being stored in a secure environment.

PO2.4 Integrity Management touches upon defining processes to ensure integrity of data in databases.

Regards.

Vikram K Malkani at 9/2/2011 4:29:34 AM
You must sign in to rate content.
(Unrated)

RE: Data change control

Another addition - DS5 too mentions ensuring data integrity by defining processes.
Vikram K Malkani at 9/2/2011 4:38:24 AM
You must sign in to rate content.
(Unrated)

RE: Data change control

An IT standard or procedure document should be created to manage the risks for this activity. Manage Change is suggested objective. This occurs in a number of organizations than most would be willing to admit as part of production support emergency changes. I agree with Vikram statement on not allowing a generic/firecall ID too. All production support should occur with the production support users ID. This may require implementation of a production emergency group privilege however acheives greater accountability. Ironically, I posted a similar query in the change management community a few weeks back. I do not believe there's been much, if any, discussion.
Steve_W at 12/2/2011 5:35:12 PM
You must sign in to rate content.
(Unrated)

RE: Data change control

An IT standard or procedure document should be created to manage the risks for this activity. Manage Change is suggested objective. This occurs in a number of organizations than most would be willing to admit as part of production support emergency changes. I agree with Vikram statement on not allowing a generic/firecall ID too. All production support should occur with the production support users ID. This may require implementation of a production emergency group privilege however acheives greater accountability. Ironically, I posted a similar query in the change management community a few weeks back. I do not believe there's been much, if any, discussion.
Steve_W at 12/2/2011 5:35:12 PM
You must sign in to rate content.
(Unrated)

RE: Data change control

Another addition - DS5 too mentions ensuring data integrity by defining processes.
Vikram K Malkani at 9/2/2011 4:38:24 AM
You must sign in to rate content.
(Unrated)

RE: Data change control

It wouldn't be advisable (in fact, would be very dangerous) for any company to alter production data outside of defined processes.

A small addition to above response is that a log of changes made (including who made them) should be automatically created and saved in a secure environment. A common ID should not be used to make these changes. Any change made must be made with authorised documented approval, with the approval being stored in a secure environment.

PO2.4 Integrity Management touches upon defining processes to ensure integrity of data in databases.

Regards.

Vikram K Malkani at 9/2/2011 4:29:34 AM
You must sign in to rate content.
(Unrated)

RE: Data change control

Hi,

It is definitely not normal to make changes to data files outside of change management processes and procedures, but it is quite possible and normal to make changes to data using SQL without using the application interface.

In the consideration of Cobit, you should make sure that such changes are placed under the control of your change management process. It means that the change must be analyzed, authorized, tested before being implemented and that there is a rollback plan. In this particular case, testing and rollback planning are extremely important as the change is not done through the application interface and thus will have a much higher risk. Also, only authorized people should have the technical access right required to make such change.

---
IT governance by examples at http://agileskills2.org/ITGBE/
Kent Tong at 3/10/2011 7:37:51 AM
You must sign in to rate content.
(1 ratings)

RE: Data change control

Hi,

It is definitely not normal to make changes to data files outside of change management processes and procedures, but it is quite possible and normal to make changes to data using SQL without using the application interface.

In the consideration of Cobit, you should make sure that such changes are placed under the control of your change management process. It means that the change must be analyzed, authorized, tested before being implemented and that there is a rollback plan. In this particular case, testing and rollback planning are extremely important as the change is not done through the application interface and thus will have a much higher risk. Also, only authorized people should have the technical access right required to make such change.

---
IT governance by examples at http://agileskills2.org/ITGBE/
Kent Tong at 3/10/2011 7:37:51 AM
You must sign in to rate content.
(1 ratings)

RE: Data change control

It wouldn't be advisable (in fact, would be very dangerous) for any company to alter production data outside of defined processes.

A small addition to above response is that a log of changes made (including who made them) should be automatically created and saved in a secure environment. A common ID should not be used to make these changes. Any change made must be made with authorised documented approval, with the approval being stored in a secure environment.

PO2.4 Integrity Management touches upon defining processes to ensure integrity of data in databases.

Regards.

Vikram K Malkani at 9/2/2011 4:29:34 AM
You must sign in to rate content.
(Unrated)

RE: Data change control

Another addition - DS5 too mentions ensuring data integrity by defining processes.
Vikram K Malkani at 9/2/2011 4:38:24 AM
You must sign in to rate content.
(Unrated)

RE: Data change control

An IT standard or procedure document should be created to manage the risks for this activity. Manage Change is suggested objective. This occurs in a number of organizations than most would be willing to admit as part of production support emergency changes. I agree with Vikram statement on not allowing a generic/firecall ID too. All production support should occur with the production support users ID. This may require implementation of a production emergency group privilege however acheives greater accountability. Ironically, I posted a similar query in the change management community a few weeks back. I do not believe there's been much, if any, discussion.
Steve_W at 12/2/2011 5:35:12 PM
You must sign in to rate content.
(Unrated)

Leave a Comment

* required

You must login to leave a comment.

« Return to All Discussions « Return to Topic