You would need to consider the frequency of the activity itself to decide on the frequency of the testing of the control. If the activity happens many times, you would typically test quarterly. If an activity happens twice per year, test 1 time in the first half of the year and 1 time in the second half of the year. Treat testing of IT controls the same way that the business controls are tested that would give you an opportunity to fix any issues that arise through testing. Scanning is left to departmental decisions, controls are usually tested annual at 1/3 test to be compliant. But if a control is compliant, you may not need to test it again unless something in the configuration or process has changed Business impact and business risk are the major drivers in determining the frequency of testing an IT control. Testing involves money but failures can cost a lot more. Not all controls are created equal. In very high risk situations you might need to test weekly or monthly (although that would suggest that the controls aren't adequate); in others annual will be sufficient.

Apart from the annual timelines one of the other important points to be considered for the ITGC testing will depend on the level an organisation is.
For eg:- For an organisation which does not have a well organized IT division, it would be advisable to have the review / testing / audit of the IT controls on 6 months basis. For a matured organisation, a year’s time frame is suitable.

To make it short, in an matured organisation the IT controls gets tested on regular interval depending on the certification and level a company has. In a year it can undergo SOX audit, SAS Attestation, IT Audit. All these do t ouch bases on few of the very important controls which do overlap. So the IT controls do get tested.

Segregation of duties (SoD) is a hot topic of conversation among a range of professionals, from compliance managers to executive officers. The outpouring of interest in SoD is due, in part, to the requirements of the Sarbanes-Oxley Act in the US and other similar control-driven regulations worldwide. However, the key factor at work here is the principle that no individual should have excessive system access that enables him/her to execute conflicting end-to-end transactions.

 It is a basic internal control that attempts to ensure that no single individual has the authority to execute two or more conflicting sensitive transactions with the potential to impact the financial statements or confidential information. Without proper guidance and a sound approach, SoD testing, remediation and mitigation may appear to be a huge challenge. Sensitive transactions drive processes with the potential to impact a company’s financial statements. Though companies strive for zero SoD conflicts in their user population, separating discrete job responsibilities into task-oriented roles can often result in inefficiencies and unnecessary costs.

However, a risk-based methodology can make the effort manageable.

A Risk-Based Methodology

A risk-based methodology focuses on the issues that pose the greatest threat to the business and company’s financial statements. Whether the drivers for investing in SoD compliance are fraud prevention, regulatory compliance or a new enterprise resource planning (ERP) system, a company cannot eliminate every potential risk. The goal is to drill down on the issues that meet predefined thresholds of risk. These should be determined at the outset of the SoD initiative. Materiality, fraud thresholds or financially significant value limits are examples of thresholds that serve to measure the sensitivity of SoD conflicts.

The SoD Road Map

Most SoD initiatives consist of five phases:

1. Business Definition

The objective of this phase is to gain an understanding of the scope of sensitive transactions and conflicts that drive the company’s key business processes. These are the transactions that pose the greatest fraud risk to the organization should someone possess excessive access. For example, a company may be concerned about allowing the same individual to both create a vendor purchase order and modify the customer pricing master file. However, the combination of the two may constitute such a low risk that it does not warrant inclusion in the company’s conflict matrix
The matrix and corresponding risk statements differ among companies, industries, business models and even locations within the same company,

2. Technical Definition

The testing phase draws on data from the business definition and technical definition phases to produce an analysis of users with SoD conflicts. This report highlights the SoD conflicts in a number of ways, such as by user and by role/group, and shows the extent of the conflicts among the company’s user population.

The completed conflict matrix should help answer the identify applications that are able to execute the defined sensitive transactions and how are they executed in the system.  The company or business unit must map each sensitive transaction to its associated access rights in the application that enables that transaction. This critical step feeds the data analysis to yield the testing results.

3. Testing

The testing phase draws on data from the business definition and technical definition phases to produce an analysis of users with SoD conflicts. This report highlights the SoD conflicts in a number of ways, such as by user and by role/group, and shows the extent of the conflicts among the company’s user population.

4. Mitigation

The mitigation phase is completed concurrently with remediation, or, depending on the objectives and compliance time frame, mitigation can be performed last, once conflicts have been reduced to their absolute minimum. Mitigation has several critical success factors. Many companies choose to mitigate every potential conflict to establish a safety net of control should a conflict arise. This is a sound and practical strategy for companies looking to control unforeseen or unpredictable risk.

5. Remediation

The goal of this phase is the permanent correction of SoD conflicts. Remediation techniques include role redesign, role cleanup, user appropriateness review and SoD tool implementation. A combination of people, process and technology changes help sustain compliance.

There is no prescribed road map or universal method for remediation of conflicts. Each scenario is unique, depending on the degree of complexity and extent of the conflicts in a given environment. While the appropriate level of effort and emphasis needs to be placed on SoD compliance, companies must also strive for simplicity and precision in the execution of their controls. SoD presents a unique challenge to control compliance as it requires close alignment of business and IT stakeholders to identify, assess, reduce and monitor the risk of fraud or deceptive material.