IT Governance implementation has become indispensable for organizations aiming to manage their regulatory compliance as well as broader business governance functions. However the number of organizations actually implementing a formal IT Governance program and reaping benefits out of it is relatively modest. What makes it so?
We often hear these statements – Don’t we?
“We see IT Governance as an important issue, and we are carrying on an assessment of what is needed”
“We have put ad hoc measures in place till we decide on the final IT Governance framework”
“We are not getting the expected results; hence we are optimizing our IT Governance processes”
“We already have some well-defined IT Governance processes in place and are working on establishing a IT Governance program”
Wrong Processes
Wrong definition, interpretation, and implementation of processes that are in-built in the IT Governance framework may lead to scary results. Hence before deciding on your IT governance design, make sure to inspect your core work processes first. Lack of a solid core process is often the root of the problem. IT governance does work, but only when it is not clogged up with the processes that don’t fit its goals and when it is designed along with the processes it is supposed to help. Here’s a close look on possible mistakes and ways to avoid them:
IT governance as a separate set of overlays on the top of core day-to-day processes
Remediation
IT Governance should not be treated as a separate area needing attention; instead it should be integrated and managed consistently across the business. One should follow a bottom-up approach, not a top-down approach while implementing it.
Improper authorization management
Remediation
SOX Compliance has enforced strong internal controls to operational levels but the big gap of provisioning still remains. A gap between pre-emptive and detective approach. There is control on the assignment of users to groups/roles/profiles in the IT systems. But the functions these groups, roles or profiles are allowed to do is defined and managed by someone else – the operator/administrator of these IT systems. These authorized people (operator/administrator/senior executives) are not under strong controls even now. Remember, who did wrong activities at Satyam/Enron/WorldCom? Operational level or Executive level?
You should always keep that in mind, that internal controls for executive level are as important as they are for operational level and hence there should not be just a single level but a multi-level authorization, starting with the system admin (who confirms that groups, roles, or profiles) whether he has the correct access rights at that level? This will avoid the occurring of an instance where any access right is granted which later on has to be revoked.
Over-reliance on a single preventive or detective control
Remediation
Instead of stacking more of a particular type of control regime, the organization should focus on developing and implementing a portfolio of controls. That way, if one control fails or is subverted, an independent control serves as a safety net.
For instance organizations should augment manual review of user account and access rights provisioning/re-provisioning/de-provisioning with a detective control. This enables them to compare actual user access with authorized users and permissions thus eliminating the possibility of any security breach.
Be the first to rate this post
- Currently 0/5 Stars.
- 1
- 2
- 3
- 4
- 5