IS Audit & ITGC Review: The Process, Start to Finish
The mechanics of IS Audit & ITGC Review are what clients ask about once they have decided to proceed. The questions below are the ones raised most often in practice; the full scope of the service is on the IS Audit & ITGC Review page.
What is the difference between an Information Systems Audit and an IT General Controls (ITGC) review?
Information Systems Audit (IS Audit) is the broader term — an independent examination of an organisation's IT environment covering governance, security, applications, infrastructure, and data. ITGC review is typically the specific subset of an IS Audit that focuses on controls operating across the entire IT environment (access management, change management, IT operations) rather than within a single application — and is the form most directly relevant to financial-reporting reliance under Section 143(3)(i) of the Companies Act. In practice, an ITGC review is one component of a fuller IS Audit; the two terms are often used together because the scope substantially overlaps for most engagements.
In practice: When a client asks for 'an IT audit', we always start by clarifying which driver applies — statutory IFC support, an RBI mandate, ISO 27001 readiness, or general assurance — because the term is used loosely in the market and the right scope differs meaningfully by driver.
How does ITGC review relate to our statutory auditor's work — will it reduce our audit fees or timeline?
Where an ITGC review is completed before year-end fieldwork and the statutory auditor is satisfied with the scope, methodology, and evidence, the auditor may place reliance on the work to reduce the extent of their own IT-related substantive testing — which can help control fee escalation and compress the audit timeline. This is not automatic: the statutory auditor independently assesses whether to rely on any third-party work, including our own, based on their own risk assessment and professional judgement under the applicable Standards on Auditing.
In practice: We coordinate directly with the statutory auditor's team during scoping — even when PNPC is not the statutory auditor — specifically so our workpapers are built in a form they can actually use, rather than discovering post-fieldwork that the format does not meet their evidentiary needs.
What is segregation of duties (SoD) testing within an ERP, and why does it need a specialist rather than a general auditor?
SoD testing examines whether a single user's system role permits them to perform conflicting functions that should be split between two people — for example, creating a vendor master record and approving payment to that same vendor, or posting a journal entry and approving it. Testing this properly requires extracting the actual role-to-transaction-code mapping configured in the system (SAP, Oracle, or similar) and analysing it for conflicts — a documented policy statement that 'maker and checker are separate' is not evidence that the system configuration actually enforces it. This requires familiarity with how ERP role and authorisation objects are structured, which is a distinct skill set from general financial statement auditing.
In practice: SoD conflicts can exist even where a client's own IT team genuinely believes the roles are properly segregated — for example, several authorisation layers deep in a custom role cloned from a standard role years earlier and never re-reviewed.
How long does a typical ISA/ITGC engagement take, and what does it depend on?
The duration of an ISA/ITGC engagement depends on its scope, and the timeline is agreed at scoping. A multi-entity engagement, or one involving a core banking/lending system with RBI-specific cybersecurity and business continuity testing, is broader and will take longer than a focused single-entity review. The main variables are the number of in-scope applications and integrations, the quality and completeness of existing IT documentation, and — often most significantly — how quickly the client's IT team can extract system-generated access and change logs rather than relying on manually maintained records.
In practice: A major timeline driver is not fieldwork pace — it is how quickly the client's IT team can pull clean, system-generated data extracts. We share the exact extract specifications on Day 1 to avoid weeks of back-and-forth over incomplete exports.
What is the difference between ITGC review and a penetration test (VAPT)?
ITGC review assesses whether governance processes and controls — access approval, change management, backup discipline — are properly designed and consistently followed. A penetration test (or Vulnerability Assessment and Penetration Testing, VAPT) is a technical exercise that actively attempts to identify and, in a controlled manner, exploit technical vulnerabilities in a specific application, network, or system. They are complementary rather than substitutes: an organisation can have well-documented, consistently followed change-management processes (a strong ITGC finding) and still have an unpatched, exploitable vulnerability in a public-facing application (a VAPT finding), or vice versa.
In practice: It often makes sense to sequence the two — ITGC first to establish governance maturity, VAPT second to technically validate the perimeter — but they answer different questions and neither substitutes for the other.
What documentation should we prepare before the ITGC review begins to avoid delays?
The most time-saving preparation is having your IT team ready to extract, rather than manually compile, system-generated data: current user access lists per system, privileged account lists, the change log for the review period, backup logs, and batch job exception logs. Alongside this, gather your Board-approved IT policy (if one exists), the current HR headcount/exit list for cross-referencing against access, and any prior internal audit or ITGC findings with their closure status. We provide a detailed document and data-extract request list at engagement kick-off, tailored to your specific application landscape.
In practice: The single biggest timeline saver is having IT pull raw system exports rather than a manually maintained spreadsheet 'summary' — manual summaries are frequently stale or incomplete, and we end up re-requesting the raw extract regardless, which adds back-and-forth that could have been avoided.
How does PNPC handle sensitive findings — for example, evidence suggesting a specific individual bypassed a control?
Any finding suggesting potential misconduct, fraud, or deliberate control circumvention by a specific individual is escalated confidentially and promptly to the Audit Committee or the Board (not routed through the process owner or department implicated), consistent with our professional obligations. Where the evidence suggests a matter requiring specialist investigation beyond the scope of an ITGC review — such as a suspected deliberate fraud — we recommend a dedicated forensic engagement rather than attempting to investigate it within the ITGC scope, which is designed for control assessment, not evidentiary fraud investigation.
In practice: We draw this boundary deliberately. ITGC testing can surface an anomaly consistent with misconduct, but converting that anomaly into a defensible, evidentiary finding requires forensic methodology and, often, legal coordination that sits outside a standard ITGC engagement scope.
Is a review of our WhatsApp-based or email-based approval process considered a valid control?
It can be, provided the approval is documented, retained, and traceable to a specific approver and decision — but email or messaging-app approvals are inherently weaker evidence than a system-enforced workflow approval, because they are easier to fabricate, backdate, or lose, and typically lack any system-enforced segregation of duties. We assess these as a design gap in most cases and recommend migrating critical approvals (payment release, vendor master changes, user access grants) into the ERP's native workflow wherever the system supports it.
In practice: This can happen in fast-growing companies that scaled process discipline slower than headcount — the underlying decision-making is often genuinely sound, but the evidence trail is not defensible under audit scrutiny, and that gap is what gets flagged.
Does PNPC provide ongoing ITGC monitoring, or is this strictly a point-in-time review?
Both models are available. A point-in-time review is appropriate for a first-time engagement, a specific regulatory filing, or ISO 27001 readiness. For companies where IT controls need continuous assurance — particularly those with PE investors, lending covenants, or RBI regulatory obligations — we offer an ongoing programme with periodic (typically half-yearly or annual) re-testing cycles, tracked findings closure, and updated scope as new systems or integrations are added to the environment.
In practice: We generally recommend at least an annual re-test even for companies without a strict regulatory mandate — IT environments change fast, and a control environment assessed as adequate 18 months ago is not a reliable indicator of the current state.
Where this sits in the wider engagement
IS Audit & ITGC Review rarely arrives on its own. The statutory basis and the current requirements are set out on the IS Audit & ITGC Review service page, and the related services are grouped under Audit Assurance.
What PNPC does
PNPC Global has practised since 1986 across India and the UAE. On IS Audit & ITGC Review we take the work end to end — scoping, testing, reporting findings to management and the audit committee, and following up on remediation.