IT Audit Process

As with any audit, IT Audit process includes planning, fieldwork/execution, reporting, and follow-up
phases. We are either testing client’s systems as part of their financial statement audit, or assisting them to
perform their annual internal control testing (Silent Note: the process here is how we perform IT Audit).

Planning involves determining the audit objective (or purpose), and the applicable audit framework (or
guide) such as COBIT or IT General Controls if a commercial entity; or FISCAM if a federal agency.
During planning, test plan or audit program is created from the audit framework and customized to the
organization’s internal control environment (Silent note: controls are selected in framework customization
if they are applicable to the client’s environment/business and if such controls are financially significant,
since the objective of most audits are to support financial statement audit or to test internal controls over
financial reporting/statements). Sometimes the controls to test would be selected from the client’s
established internal control program or control matrix (also called Risk and Control Matrix, RCM or
RACM) in the case of internal control assessment. We will then create the audit request/PBC List
(Prepared by Client List) from the controls being tested, which is sent to the client or the group being
audited to obtain evidence needed for the audit. The audit kickoff meeting is also conducted to determine if
the client is fine with our fieldwork starting date when we plan to be with them or be on their premises, if
they have questions about our PBC List or if they have any other question or concern that we need to
address, and to introduce the audit team. (Silent note: we can obtain/pull some or most of the requested
items ourselves during fieldwork if we are granted access to the system, typically with Auditor access which
usually has rights to read and download files and not to input or update data/entries. This is expected on
Internal Audit projects).

The fieldwork begins after we schedule a meeting with the client or group to be audited (usually IT
department personnel or head) to discuss the audit request and perform a walkthrough of the controls,
using one sample of evidence(i.e a test of one sample per control) provided to determine if controls are
properly designed or established. This is when we evaluate the appropriate design of the controls being
tested. We will then perform test of controls (also known as detailed testing) by selecting multiple
sample (usually 10% of the transactions, up to a maximum of 25 samples in commercial entities or 45 in
the government) and test the sample, to determine whether the controls designed are consistently followed
for all the transactions processed, in order to determine the operating effectiveness of the controls (Silent
note: we typically perform some administrative tasks as part of fieldwork, such as holding a weekly status
meeting with client to discuss progress/delay/need/validation of potential audit findings; we will also have
another weekly internal status meeting within the team to discuss status of assigned controls/work; and then
we track our progress towards the agreed deliverables, deadline and budget with status tracker and budget
tracker using Excel spreadsheet or Microsoft Project).

We will then move into the reporting phase during which we conduct exit meeting and provide the list of
our audit findings (usually in form of daft report, which is later finalized and sent to the client) or control
weaknesses found with related risk statement (what could go wrong if the weaknesses are not corrected). We
also provide recommendation on how to correct the weaknesses. We then determine whether the control
environment is effective or not, based on the risk level of weaknesses found such as
low/moderate/high or control deficiency, significant deficiency or material weaknesses.

(Note-Besides the AICPA official definition, control deficiencies (CD) means basic/low findings that clients
can take their time to correct, significant deficiencies (SD) are medium/serious weaknesses that need being

1
corrected as soon as possible and that management needs to know about, and material weaknesses (MW)
are high/very serious weaknesses that need to be corrected immediately)

Depending on the audit objective, we will follow up after some time agreed with the client to determine if
the control weaknesses have been corrected. (Silent note: We perform follow up on annual internal control
testing such as SOX or A-123, and audit readiness projects. It is not performed on financial statements audit
and attestation engagements)

(Note- The follow up involves checking whether the audit findings have been corrected, and this
includes understanding the findings and related recommendation, and obtaining evidence, typically
screenshot or other reports from the client that address the findings and recommendations are sufficient to
correct the findings. We will also need to read the corrective action plan (CAP) documented by the client
to determine if they address/correct the audit findings and indicate the appropriate evidence that may be
requested to close the finding or evidence that it has been corrected. We typically will test one evidence of
the correction as a test of design (TOD)/walkthrough of the failed control, and in some cases where lists
of transactions are available, we may proceed (based on manager’s preference) to select multiple sample and
test the correction/remediation of the finding as a test of effectiveness (TOE) of the control that failed.
(This follow-up is also sometime called independent verification and validation (IV&V) of remediation)

If we are helping with findings remediation in case of audit readiness project, remediation process
involves understanding the audit findings, determining their root cause and coordinating with all the
system stakeholders, such as system administrators and developers who need to make the necessary
changes or change the configuration settings, to correct the findings. We typically will schedule meetings to
discuss the findings, assign the corrective tasks to the stakeholders that are in the best position to correct
each finding and monitor the progress with follow up or regular meetings to ensure the findings are
corrected).

Audit Liaison
The following factors may also be considered, clarified form the system owner and observed if you perform
Audit Liaison functions and attend to the external auditors and provide them requested items and
responded to their Notice of Finding and Recommendation (NFR):

1) The number of days that auditors give in their Request List within which to provide them the requested
items. This is typically 3 - 5 business days.
2) How responsive the people that the items would be collected from are.
3) Identify the people that provide most of or all the items, and determine the process of letting these
people know the items requested by the auditors, and whether this would be via email communication,
phone call or meeting.
4) If there would be a need to send those that provide the evidences reminders before they provide the
items or if they typically provide them once informed of the request and the due date.
5) If you would need to have regular meetings with the folks that provide the items, to explain the requested
items or if they are familiar with what need to be provided.
6) Possibility of collecting the items from those that provide them about two days before they are due to
the auditors, and what actions need to be taken if the folks do not provide the items by the due date.
Overdue items typically get escalated to the supervisors of those that are supposed to provide them.
7) How the items would be provided to the auditors, whether via email, SharePoint or CDs.
8) Whether system owner or another supervisor would need to see the items before you provide them to the
auditors, and how you would send the evidence to such supervisor.
9) Whether you would need to scrub the items of sensitive and PII information or whether they often come
sanitized from the people that provide them
10) Whether there is any pending or current Request List from the auditors and the idea of the status or
percentage of completion of the items provided
2
11) Whether you can be provided the previous year Request List and the items provided for them so as to
see what were provided to the auditors, as most of the current year items would be the same as last year.
12) As an audit liaison officer, whether you would need to attend or sit in at the walkthrough meetings or
interviews that auditors have with other system stakeholders (like system administrators, system
developers, database administrators, system maintainers, system owner) to understand the process or
controls they (the auditors) are auditing.
13) With respect to responding to auditor’s NFR, whether you are responsible for collecting the NFRs from
the auditors and distributing them to the relevant system owners or Points of Contacts (POCs), and getting
their responses back to auditors, or if the auditors reach out to those POCs directly, and
14) If you need to assist the POCs in responding to the NFRs; and if you need to track the NFR issuance
and responses, and if a Corrective Action Plan (CAP) needs to be created to document the progress and
status of audit findings correction/remediation.

(Finally, Silent Note- Depending on employer’s audit methodology (not performed by every audit firm, but
should be admitted as performed if asked), year-end update procedures (typically documented in a year-end
update memo) could be performed on all IT Audit projects to confirm that there has been no change in the IT
environment, such as key personnel, process and systems. This is limited to inquiry and observation
(preferably from one-day visit to the client to confirm that key personnel have not changed), provided the interim
procedures were performed within 3 months of year-end, else walkthrough or limited detailed testing (such as
testing 2 samples) would be performed especially where the process (e.g., access controls change) has changed or
where related key personnel (such as System Administrator that performs the controls) or systems (such as in
system change/upgrade) have changed since the interim testing. This year-end update memo is similar to bridge
letter in SSAE16/attestation engagement)