ITGC Guidance 2

ABCD

IT General Controls Guidance

KPMG LLP Draft – 7 September 2006 This report contains 13 pages kd/1l1480

@ 2006 KPMG LLP, the UK member firm of KPMG International, a Swiss cooperative. All rights reserved. KPMG and the KPMG logo are registered trademarks of KPMG International. International.

ABCD IT General Controls KPMG LLP Draft – 7 September 2006

Contents

1 Introduction

1

1.1 Purpose of this paper 1.2 Content of this paper 1.3 Relevance of this paper to integrated audits 1.4 Relationship of this paper to the KPMG Audit Manual

1 1 1 1

2 ELCP work, not ITGC work, in the Planning phase

2

3 IT General Controls work in the Control Evaluation phase3 4 Implications of IT general controls work

4

4.1 What IT general controls work can provide 4.2 Effect of weaknesses or deficiencies

4 5

5 When to perform tests of controls

6

5.1 General guidance applicable to all controls 5.2 Circumstances when IT general controls work is performed

6 6

6 The extent of tests of the operating effectiveness of IT general controls

8

6.1 Choosing which ITGCP subsections to complete 8 6.2 The level of controls to test 9 6.3 The number of controls to test 9 6.4 The extent of tests of individual controls 10 6.5 Tests of controls supporting IT general controls 10 6.6 Rolling forward tests of operating effectiveness performed before the period end 11

7 When an application is replaced during the year

11

8 IT General Controls and anti-fraud controls

12

9 Integrating IT general controls work into the audit

12

10 IT general controls work in a wholly substantive audit

13


1

Introduction

1.1

Purpose of this paper

In the UK there is some confusion and misunderstanding regarding the role of IT general controls (“ITGC”) in a (non-integrated) financial statements audit and the extent of audit work that is necessary. This document is a policy paper. It is not intended to be rolled out in its current form but has been prepared to allow us to reach agreement on IT general controls between IRM in the external audit (IRMinEA) and DPP-Auditing. This paper reflects the agreed position and sets out the accepted interpretation of the requirements of KAM regarding ITGC. Roll-out of practical guidance based on this paper will be considered separately, by IRM and by DPP-Auditing.

1.2

Content of this paper

This document: •

clarifies the role of IT general controls work in a financial statements audit, including guidance on the circumstances in which testing IT general controls is appropriate

•

clarifies when and how an IT General Controls Program is used in a financial statements audit

•

notes considerations relevant to testing the operating effectiveness of IT general controls

•

provides guidance on IT general controls work in relation to tests of anti-fraud controls

•

considers how to integrate IT general controls work fully into a financial statements audit

•

explains what is necessary in relation to IT general controls in a wholly substantive audit.

1.3

Relevance of this paper to integrated audits

This paper is not relevant to integrated audits..

1.4

Relationship of this paper to the KPMG Audit Manual

[Standard caveat to be included]

1


2

ELCP work, not ITGC work, in the Planning phase In previous KPMG audit methodologies, IT general controls work was positioned in the planning phase of the audit, alongside work on the control environment. The equivalent work in KAM 6 is documented in section 3.2 of the Entity Level Controls Program: ‘Description of controls relating to information systems relevant to financial reporting’. When considering this element of the entity level controls, KAM 6 states this in [4271]: Examples of controls related to the information system relevant to financial reporting may include: internally generated information, critical to the achievement of the business • objectives, is identified and reported •

mechanisms are in place to obtain relevant external information - on market conditions, competitors’ programs, legislative or regulatory developments, and economic changes

•

at the beginning of each year’s budget cycle, IT meets with divisional management to discuss the IT system requirements and jointly decide on the priorities, staff and budget resources and implementation schedules

•

IT management participates in steering groups in all major business areas

•

sufficient resources are provided to develop/enhance information systems

•

mechanisms exist for taking advantage and controlling the use of new technology applications, and incorporating them into the production processes or information systems, and

•

attention is given to the effect of new systems on information flows and related controls and employee training, including focus on employee resistance to change.

The general tenor of these examples is that IT is expected to support the business operations. Doing this work satisfies the requirements of ISA 315 paragraph 93: “The auditor should obtain an understanding of how the entity has responded to risks arising from IT,” and it also considers how the entity gains benefits from using IT. These considerations, which are on a very different level than the matters included in the ITGC Program, are equivalent to the considerations relevant to other entity level controls. They are likely to be seen by audit teams as relevant to their evaluation of the wider control environment including IT elements, and to the acceptance / continuance decision. Given the non-technical nature of the considerations, it is likely that non-specialist auditors will be able to perform this work for almost all audits. IRM specialists may be involved when deeper understanding is sought. During the Planning phase of every FSA audit, section 3.2 of the ELCP should be completed to an appropriate extent , following the KAM guidance. The requirement is to consider design and implementation. We do not test operational effectiveness.

2


There is no requirement for the matters included in the IT General Controls Program to be considered during the Planning phase. For SE audits the equivalent section is section V.C.2 of the Planning Document. However, the SE Planning Document also has an ITGC document embedded within it as section V.G, prefaced by guidance that suggests the section should always be completed: ‘Document our understanding of the IT general controls . . . in the table below’. KAM [4613.10.2] however is specific in stating that IT general controls work is required only in the circumstances discussed in section 3 of this document.

3

IT General Controls work in the Control Evaluation phase KAM 4420.2.1 states: ‘To the extent that the design and operating effectiveness of an automated application control [on which the audit team wish to rely] are dependent on an indirect (supporting) control, we obtain evidence regarding the operating effectiveness of the supporting control. For instance, internal controls in an application are dependent on IT general controls.” KAM therefore positions work on IT general controls in the Controls Evaluation phase of the audit. The IT General Controls Program is provided to control and record this work.

3.1.1

When tests of controls are required or appropriate

KAM 6 allows auditors to take a wholly substantive approach to an audit objective and, in the extreme, to the entire audit. A controls-based approach is suggested when: •

it is not possible to obtain sufficient audit evidence purely substantively, or

•

a more efficient audit approach would be one that makes an assessment that RoSM is less than high, supported through tests of controls, in order to reduce the extent of substantive evidence required. It is also mandatory to test the relevant anti-fraud controls when a specific risk of fraud has been identified in relation to an assertion.

3.1.2

When tests of ITGC may be required in support of tests of controls

When anti-fraud controls have an IT element we will need to test related IT general controls. Where an assessment of RoSM as less than high depends on tests of an automated application control or a manual control with an IT element (together called “applicationlevel IT controls” in this paper for brevity), we may need to supplement that assessment with work on related IT general controls to support a conclusion that the assessment applies to the whole year. We may also need similar support from IT general controls if in our audit we rely (as a source of audit evidence or as the basis for audit procedures) on IT system-generated

3


reports throughout the period (the reliability of year-end reports may be tested substantively). We do not “rely” on reports if we merely use them as one source of the information that we use in planning the audit, nor if we subsequently corroborate the information with substantive procedures. In this paper, “application-level IT controls” includes such throughout-the-year reports when appropriate.

3.1.3

Timing of ITGC work

Conceptually, work on IT general controls is only planned once we plan to rely on an application-level IT control, which occurs at quite a late stage in the planning phase. In the first year of a new audit, that may be the order of our decisions. However, on a continuing audit we will know in practice whether ITGC work is needed without needing to finalise the audit approach to every audit objective.

3.1.4

We do not necessarily complete an ITGCP for every key IT environment

The ‘Purpose’ section of an ITGCP states that an ITGCP is completed for each IT environment where processing of key financial reporting data occurs. However, KAM makes it clear that an ITGCP is only required to be completed where there is an audit requirement – ie where the work is necessary in relation to one or more specific audit objectives. This is only the case for: •

reliance on the operational effectiveness throughout the year of an application-level IT control

•

reliance on a system-generated report throughout the year for audit evidence or as the basis for audit procedures

•

an identified risk of fraud, when we need to assess the effectiveness of anti-fraud IT controls throughout the year.

This does not rule out the audit team looking for “comfort” over other environments or systems, but this work will not be audit evidence and there is no requirement to complete it to the same degree as is necessary when performing ITGC work as a test of supporting controls. This point is considered in more detail in section 5.2.3.

4

Implications of IT general controls work

4.1

What IT general controls work can provide

IT general controls work is performed to look for deficiencies or weaknesses that may affect the design or operating effectiveness of application-level IT controls. When a control is automated, it is only possible to test its design and operation in real time; we cannot retrospectively perform this work. If a RoSM assessment depends on an application-level IT control operating effectively throughout the period being audited, we can only conclude whether that was so by testing the IT general controls relevant to the

4


application-level IT control. For this reason, when performing IT general controls work, the tests of operation of the ITGC need to cover the year. If deficiencies or weaknesses are found, the effect on application-level IT controls needs to be considered.

4.2

Effect of weaknesses or deficiencies

If deficiencies or weaknesses are found in IT general controls, the audit team considers, normally in conjunction with the IRM specialists, what the implications are for reliance on application-level IT controls, and thus for the audit. If the ITGC work is not carefully specified beforehand, it may be the case that weaknesses are found in an ITGC that is not directly relevant to the application-level IT control and so there is no effect on the audit. For example, we find weaknesses in controls over backup and recovery of data, but those controls do not provide indirect support for the design or operation of the system-generated exception report control on which the audit team wish to rely. It may also be the case that the effect of the ITGC weakness on the application-level IT control is insufficient to make reliance not possible; we may, for example, be able to conclude that the control is sufficiently effective for the purposes of the audit. For example, we find a weakness but not total failure in the operation of the testing, validation and approval of program changes. However, the automated control operated effectively when tested, it is used daily in the business, there is no record of emergency fixes affecting the control and no one can recall any problems with it during the year, and the importance of the control to the business is such that operational and / or accounting personnel would detect it if the control systematically failed to operate as intended. We therefore conclude that the weakness is minor and does not affect our ability to rely on the control. If the conclusion is that there is an effect on the audit that requires a response, the choice is between: •

identifying and testing IT controls that are related more specifically to the application-level IT control, to see whether the weaknesses did not affect the control. For example, if we wish to rely on a single control within a suite of programs, and we have tested the IT general controls over program change for the suite and found weaknesses in their operation, we may be able to identify and test the operation of the program change controls as they relate specifically to the control, or to the module or program containing the control. For example, if there are weaknesses in the operation of controls over access to data, there may be a detective control based on checksums or some other method of detecting unexpected changes that can be tested instead.

5

ABCD IT General Controls KPMG LLP Draft – 7 September 2006 •

performing additional tests of application-level controls, either identifying and testing other controls related to the same audit objective but not affected by the IT general control weakness, or testing the application-level IT control itself more rigorously For example, if the audit team wishes to rely on an application-level IT control and a related ITGC weakness is known about from the previous audit, it may be possible to test the operation of the control more than once during the period under audit.

•

assessing RoSM as moderate or high, rather than low, and so modifying the nature, timing or extent of the planned substantive procedures. For example, obtaining additional audit evidence from other substantive procedures; not planning to perform an early close and roll forward.

5

When to perform tests of controls

5.1

General guidance applicable to all controls

The general guidance that applies to all controls is included here as it applies equally to tests of manual and application-level IT controls. Unless the audit objective is associated with a significant risk, we do not perform any audit work on controls if it is more practical and efficient to obtain our audit evidence through substantive procedures alone. We therefore evaluate the design and implementation of selected application level manual or IT controls when: •

the audit objective is associated with a significant risk, because the inherent risk of error is significant or because we have identified a fraud risk, or

•

we plan to test the operating effectiveness of controls to support an assessment of RoSM as less than high, which will allow us to modify the nature, timing or extent of our substantive procedures.

We test the operating effectiveness of selected controls when: •

we determine the design and implementation are effective and either •

the controls are anti-fraud controls, or

•

we intend to support an assessment of RoSM as less than high.

5.2

Circumstances when IT general controls work is performed

5.2.1

General circumstances

IT general controls work is performed when the audit approach involves reliance on an application-level IT control, and the operating effectiveness of the control is dependent on indirect support from effectively operating IT general controls.

6


For example, if we test an automated application control once, we can only conclude on its operation throughout the year if we find that relevant IT general controls were operating effectively throughout the year. For example, if anti-fraud controls have an IT element, such as the enforcement of segregation of duties by logical access controls, it is necessary to test the operating effectiveness of those controls. If we need evidence that the controls operated throughout the reporting period, we will also test the relevant associated IT general controls. (The situation when the audit team have identified a specific fraud risk is considered in section 8 of this paper.) Reliance on an application-level IT control normally requires tests of the control itself and tests of relevant ITGC. However, if the audit team plans to rely on tests of automated application controls, it is possible in the absence of program changes to perform tests of their operating effectiveness on a rolling basis every three years, so long as IT general controls are tested every year and found to be operating effectively. NB This is NOT the case for anti-fraud controls.

5.2.2

Reliance on system-generated reports as the basis for audit work

If audit procedures are based on a system-generated year-end report there is no automatic requirement to consider IT general controls, since it is possible, and likely to be more efficient, to test the year-end report substantively. However, if IRM test the report before the year-end, any conclusion about its continuing validity, etc, would depend on tests showing that the relevant IT general controls operated effectively throughout the remaining part of the year – see section 6.6 of this paper. There will be no automatic requirement to test operation of the IT general controls during the period before the report was tested. This circumstance is distinguished from audit procedures based on system-generated reports throughout the year, which would require consideration of IT general controls.

5.2.3

When auditors request ‘comfort’

IT general controls work may also be performed when the audit team wishes to have some “comfort” about the operation of a system to form a context for their audit, without there being an intention to rely on specific application-level IT controls and so no need for audit evidence about their design and operation. In such a case the ITGC Program would not be mandatory, but it may be decided that it forms an appropriate framework for discussing, planning and recording the desired extent of work. In such as case, the choice of controls to test / sections to complete, and the extent of work (eg whether to test operating effectiveness) is one of audit judgment since the use of the Program is optional.

5.2.4

Efficiency and the cost of testing IT general controls

Tests of controls are only performed when reliance on them forms part of an efficient and effective audit approach. There is a cost in time and resources of IT general controls work. If alternative approaches are available, the audit team considers these costs when deciding whether it will be efficient to place reliance on application-level IT controls.

7


6

The extent of tests of the operating effectiveness of IT general controls

6.1

Choosing which ITGCP subsections to complete

Guidance in the ITGC Program states that “Completion of this working paper is required . . . Certain sections of this working paper may not be applicable”. It may be argued that if a risk is present or an activity takes place, such as program development, then the section is applicable, and that it is only not applicable when an activity does not occur, such as program development for a purchased package. However, it is clear from KAM that the intention is that controls are tes ted only when that testing will provide audit evidence. Tests of IT general controls are performed to provide audit evidence about the operation of application-level IT controls throughout the year. If testing a particular category of controls would not provide evidence about that operation, that category is not related to the application-level IT control and so is not applicable. General controls over end-user computing are required to be documented in the relevant Audit Program. Excluding that section, the IT General Controls Program (ITGCP) includes ten subsections organised into four sections. When performing ITGC work it is necessary to consider the applicability, the potential relevance, of controls in all ten subsections. Seldom will all ten subsections will be relevant to the audit approach. The decision whether to complete a subsection is based on relevance. Relevance is best assessed by the engagement team and an IRM specialist together considering the nature of the application-level IT control that is the reason for completing the ITGCP and its role in the audit approach. If it is considered that a weakness in IT general controls in a subsection would have no effect on the audit, work in that subsection would not provide audit evidence and so need not be performed. For example, if an ITCGP is being completed as part of the work to show that an automated control operated throughout the reporting period, there may be no benefit from testing computer operations, and work on segregation of duties may not be relevant. For example, if an automated application control is being relied on, controls over program access will be relevant, but controls over access to data may not be. For example, if a system-generated report is the basis for performance of a manual control, controls over access to data may be relevant to the ability of unauthorised persons to change the report contents, or to change data before the report is run and then change it back afterwards.

8


6.2

The level of controls to test

For tests of design and implementation. it will be appropriate to test IT general controls at the level at which they are implemented – the level of the program, suite, package, platform or environment as appropriate. In the majority of instances this will also be the case for tests of operating effectiveness. However, there may be situations where the degree of persuasiveness required of the audit evidence provided by testing the IT general control implies that tests of operating effectiveness need to be performed at a lower level, so their operation in regard to the primary control can be more appropriately assessed. This is an audit judgment matter, best discussed by the audit team and the IRM specialist. For example, in a bank, most of the audit evidence f or the accuracy of calculated interest is obtained from tests of the automated application control that performs the daily calculation. In consideration of the importance of this control to the audit, the audit team may require IRM to test the operation of IT general controls as they specifically apply to the interest calculation module / program. This is not automatic; in consideration of other factors including the bank’s detective KPIs, the audit team may be satisfied with tests of operating effectiveness at the platform level. For example, when a system-produced report forms the basis of a manual control, the audit team may require more audit evidence about the operating effectiveness of the related IT general controls over access to report data than can be obtained from tests at platform level. Conversely, it may be the case that errors in the report would be subsequently identified and corrected, and while this is an operational concern, it is not an audit concern. Also relevant here is the point about testing secondary IT general controls that support primary IT general controls, which is considered in section 6.5 of this paper.

6.3

The number of controls to test

As with all controls, we test selected IT general controls, not all controls that may exist. The decision is based on relevance and efficiency. An acid test for relevance is to consider what the effect on the conclusion regarding the operating effectiveness throughout the year of the application-level IT control or systemgenerated report would potentially be if weaknesses or deficiencies were to be found: no effect, no relevance. Efficiency becomes a consideration when there is more than one control related to a single risk, when testing a subset may provide the desired audit evidence. For example, there may be a number of preventive controls related to program change, covering who can amend code, who can compile, transfer of programs between development, test and live environments, and so on. There may also be a detective control operating in the live environment that detects when programs have changed. In such a case, it will be more efficient to test the one detective

9


control than the many preventive controls. The detective control will also provide assurance about what has happened rather than what ought to have happened.

6.4

The extent of tests of individual controls

A May 2006 KPMG Audit Methodology FAQ states: “As with other tests of operating effectiveness, we determine sample si zes in accordance with relevant guidance in KAM for the extent of tests of controls. Section 8.3 “Extent of tests of controls” in KAM Chapter IV “Control Evaluation” provides guidance for both manual and automated controls. Many IT General Controls are actually manual controls. Further, many are periodic controls, so professional judgment is required to apply the guidance in KAM appropriately for the specific control. “Involvement of IRM professionals in determining the nature, extent and timing of tests of operating effectiveness of IT controls is encouraged.” This interpretation of KAM has best practice status. However, while it is clearly appropriate in some circumstances, such as when testing access controls that enforce segregation of duties as an anti-fraud control, it is not so easy to apply in a circumstance when, in support of a single application-level control, we identify, say, three controls in each of five ITGCP subsections. If the application-level control operates more than daily, indicating a sample size for tests of operating effectiveness of 30, since it is an automated control we test it once for a point-in-time assessment, but we then have to consider performing tests of fifteen supporting IT general controls possibly 15 times each. This level of work is so disproportionate to the evidence required that it seems clear that when the FAQ was prepared, the authors had in mind the former circumstance and not the latter. When testing ITGC in support of an application-level IT control, the extent of testing is a matter for the judgment of the audit team, and it should be focused and scoped in consultation with the IRM specialist to provide the level of audit evidence that the team needs.

6.5

Tests of controls supporting IT general controls In most cases, we test ITGC to support an application-level IT control – an automated application control or a manual control with an IT element. However, occasionally the primary control that we test will be an IT control of a type that is more usually found as a supporting IT general control. The most obvious example is access controls that implement operational policies for segregation of duties. When this is the case, we need to consider whether there are IT general controls in support of the primary IT control. In the access controls example, we may test the existing permissions, but to assess whether access controls enforced segregation of duties policies effectively throughout the year we would need to consider the related IT general controls, which in this case would be the controls over the granting and maintenance of those access permissions – both the manual application and approval controls and the controls over access to the system configuration functions.

10


However, concerns about testing controls of this nature are likely only when a specific risk of fraud has been identified. When considering for example access controls as an IT general control in support of an application-level IT control, we do not need to recursively test controls over those controls and so on (in the absence of an identified need).

6.6

Rolling forward tests of operating effectiveness performed before the period end When IT general controls are tested to allow an assessment of the operating effectiveness of an application-level IT control throughout the year, it is necessary that tests of the (design and) operating effectiveness of the IT general controls cover the period under audit. If the operating effectiveness of IT general controls is tested before the period end, and it is concluded that the controls are operating effectively, it may be necessary to roll the test work forward to cover the full reporting period. The relevant considerations when determining the extent of additional testing are in KAM section 8.2.1 ‘Roll-forward of interim work to period-end’. Where it is known that rolling forward will be necessary, allowance should be made for this when selecting the number of instances of the controls to test, so the necessary sample size is spread across the year.

7

When an application is replaced during the year If an application containing an automated application control on which reliance was placed in previous years is replaced during the year, it will be necessary to test IT general controls covering the period before replacement to allow an assessment that the control, which no longer exists and so cannot be tested, operated effectively until replacement. In such circumstances, the audit team may consider whether the audit does actually place reliance on controls in the replaced system. For example, an automated application control in the sales system prepared invoices and calculated sales revenue, etc from information about quantities, prices and discounts. The system was r eplaced, as planned, three months into the year. Given the company’s bad debt policy, all sales processed by the old system have been either settled in cash or written off (or provided against in full). Substantive work on sales processed by the old system will be based on cash and provisions. The audit team recognises that no reliance is being placed on the automated control in the old system and so does not plan to test the related IT general controls for the period up to replacement. However, the audit team may decide to perform tests of IT general controls as they related to both systems. If the IT general controls are established and tested at a level above the replaced system (eg platform level), the design and operation may be the same

11


for the two systems. Where different IT general controls existed for the two systems, two ITGC Programs may need to be completed. NB This does not address the question of whether controls over the migration of data between the two systems need to be tested. In that connection, where the timing permits, it will be more efficient and effective to test detective controls than preventive. If those controls were performed by operational personnel, they may be testable by the audit team without specialist IRM involvement.

8

IT General Controls and anti-fraud controls Whenever we identify an assertion-level fraud risk, we are required to evaluate the design and implementation of related anti-fraud controls, defined as those controls specifically intended to address risks of fraud, and test the operating effectiveness of anti-fraud controls that are effectively designed and implemented. Segregation of duties is used in most systems and applications to limit access to authorised, trained and competent persons and so reduce the risk of error, and this will not necessarily be of interest to the audit team. However, segregation of duties is also a common anti-fraud control when it is used to limit access to conflicting functions, and this will be of interest to the audit team where they have identified a specific risk of fraud and have identified segregation of duties as an anti-fraud control. In an IT environment, access to specific functions, etc, is specified by operational management and enforced by logical access controls configured by IT personnel. When there is an audit requirement to test this enforcement, the scope of the testing (eg who should be / should not be able to access which functions) is therefore for the audit team to decide. Testing of access permissions can be performed by the audit team, by observing people as they attempt to access functions to which they should not have access, or it can be tested by IRM specialists examining user profiles and comparing those with both profiles requested by operations and the segregation of duties of interest to the audit team. Where IT anti-fraud controls are in turn dependent on a higher level of IT general controls, auditors will need to evaluate the design and implementation and test the operating effectiveness of the relevant IT general controls, as discussed in section 6.5 of this paper.

9

Integrating IT general controls work into the audit An ITGC Program should only be completed where that is a necessary part of an audit approach that relies on application-level IT controls or system-produced reports, as discussed in section 3.1.4 of this document. This will ensure that the work is integrated. However, it is necessary to demonstrate that integration by cross-references.

12


The ITGC Program should identify the environment, platform, application or system to which it relates. That Program should include all work on that system, for all relevant audit objectives. The completed ITGC Program should be filed in an appropriate section of the audit file with an appropriate reference. In the audit program(s), the procedure for testing the application-level IT control should include a procedure to test the related IT general controls, which should be referenced to the ITGC Program. Where a single ITCG Program is relevant to more than one section of the audit file, it may be helpful to reference the Program to the other sections by for example including section references on the front page. Where there are a number of different procedures performed in support of different application-level IT controls, it may be helpful to reference the controls in the ITGP Program to the procedures in the related Audit Programs.

10

IT general controls work in a wholly substantive audit A wholly substantive audit is one where no reliance is placed on controls and all audit evidence is substantive. Such an audit will have no requirement for completion of an ITGC Program in support of an application-level IT control. For such audits the completion of section 3.2 of the Entity Level Control Program for FSA audits, and the Planning Document section V.C.2 if using SE work papers, is sufficient to comply with KAM and ISA 315 (UK and Ireland) paragraph 93. The discussion in section 2 of this paper is relevant to t his work. The audit team should however consider whether the wholly substantive audit is based in part on system produced reports not just at the year-end, which could themselves be tested substantively, but throughout the year, which may require tests of relevant supporting IT general controls as considered in section 5.2.2 of this paper.

13

ITGC Guidance 2

Recommend Documents