Information Systems Audit (ISA) & 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.

There is no standalone Companies Act section that makes ITGC review mandatory by name. It becomes effectively necessary wherever Section 143(3)(i) requires your statutory auditor to opine on the adequacy and operating effectiveness of internal financial controls, and your financial reporting relies on automated or IT-dependent manual controls — which is the case for the large majority of companies running any ERP today. Separately, it is directly mandatory (in the sense of being required under specific regulatory circulars) for RBI-regulated entities — banks, NBFCs, payment aggregators, and similar categories — under the applicable master direction for that category of institution.

It depends on scale and reliance, not just the software name. A single-entity company with two or three users on a straightforward accounting package and no meaningful segregation-of-duties risk generally does not need a formal COBIT/ISO-referenced ITGC engagement — a lighter access-hygiene review within the regular audit or accounting engagement is proportionate. The calculus changes once you add multiple locations, multiple users with differentiated roles, integrations to e-commerce or payment systems, or investor/lender requirements for control assurance.

We reference COBIT (Control Objectives for Information and Related Technologies), issued by ISACA, as the primary control-objective framework for ITGC engagements, since it maps cleanly to the IT governance and control domains referenced in the ICAI Guidance Note on Audit of Internal Financial Controls. For engagements focused on information security maturity or ISO/IEC 27001 certification readiness, we additionally map findings against the relevant ISO 27001 Annex A control objectives. For RBI-regulated entities, we test against the specific circular or master direction applicable to that category of institution.

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.

Independence rules under the Companies Act and the ICAI Code of Ethics restrict a statutory auditor's ability to provide certain non-audit services to the same audit client, and the specific restrictions depend on the client's listing status and the nature of the service. Where PNPC is the statutory auditor, we assess independence requirements before agreeing to also perform an ITGC review for the same entity, and in some cases will recommend a different qualified firm perform the ITGC work to preserve auditor independence — particularly for listed companies and companies meeting the thresholds under Section 144 of the Companies Act.

We extract the current, system-generated user access list (not a manually maintained spreadsheet that may be stale) for every in-scope system, cross-reference it against the current HR headcount to identify access held by employees who have since exited, review the approval trail for access granted during the review period, identify dormant accounts that have not logged in for an extended period, and specifically test privileged/administrator accounts for business justification and periodic recertification. This is full-population testing wherever the system allows extraction, not a small manually-selected sample.

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.

These classifications follow the same severity framework used in the broader IFC review context. A Control Deficiency exists when a control is designed or operating in a way that does not allow timely prevention or detection of a misstatement, but the impact is limited. A Significant Deficiency is a deficiency, or combination of deficiencies, that is less severe than a material weakness but merits attention by those responsible for governance. A Material Weakness is a deficiency, or combination of deficiencies, such that there is a reasonable possibility that a material misstatement will not be prevented or detected on a timely basis. ITGC findings are classified using this same scale because ITGC gaps ultimately create financial-reporting risk, not just an operational IT inconvenience.

A focused ITGC review at a single-entity company running one ERP typically takes 3–4 weeks from scoping to final report. A multi-entity engagement, or one involving a core banking/lending system with RBI-specific cybersecurity and business continuity testing, typically runs 6–8 weeks. The main variables are the number of in-scope applications and integrations, the quality and completeness of existing IT documentation, and — most significantly in our experience — how quickly the client's IT team can extract system-generated access and change logs rather than relying on manually maintained records.

No — the testing approach differs because responsibility is shared with the cloud provider. For cloud environments, we review the shared-responsibility boundary (the provider secures the underlying infrastructure; the client remains responsible for configuration, access management, and data within their environment), and focus our testing on client-side controls — cloud console/IAM access management, key and secrets management, security group and network configuration, and logging/monitoring of the cloud environment. For on-premise data centres or server rooms, we additionally test physical access controls, environmental monitoring, and fire suppression systems, which are not relevant in a cloud context.

RBI has issued sector-specific master directions and circulars covering information security, cyber-security frameworks, and IS audit requirements for different categories of regulated entities — including banks, NBFCs, and payment system operators — with the specific requirements, frequency, and reporting format varying by the category and risk profile of the institution. Because these requirements are periodically updated by RBI and differ by entity category, we confirm the current applicable circular for your specific licence category and asset size at the start of every regulated-entity engagement rather than relying on a generic checklist.

They are related but distinct. ISO/IEC 27001 is a formal Information Security Management System (ISMS) standard, and certification requires an accredited certification body to conduct the actual certification audit — PNPC does not issue ISO 27001 certificates. However, an ITGC review substantially overlaps with several ISO 27001 Annex A control domains — access control, operations security, and physical security among them — so a well-executed ITGC review gives an organisation a meaningful head start and gap-closure runway ahead of a formal certification audit, reducing the risk of nonconformities being raised for the first time by the certification body.

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.

The absence of a known incident is not evidence of control adequacy — it may equally mean an incident occurred and was not detected, given weak monitoring and logging, which is itself one of the more common ITGC findings we identify. Control testing exists precisely because self-assessment by the team responsible for operating the controls carries an inherent bias, however well-intentioned. An independent review tests actual configuration and evidence, not the operating team's own confidence in their environment.

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.

Yes, and we design the remediation roadmap with exactly that constraint in mind. For organisations with limited IT headcount, we prioritise findings by risk severity and recommend proportionate, often low-cost fixes first — enforcing a documented joiner/leaver access checklist, enabling multi-factor authentication on privileged accounts, scheduling a periodic access recertification — rather than prescribing an enterprise-grade control framework that assumes a much larger IT function. Compensating controls are explicitly considered where a full technical fix is not immediately feasible.

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.

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.

We flag material weaknesses to management and the Audit Committee as soon as they are identified during fieldwork — not held back for the final report — specifically so remediation, or at minimum an interim compensating control, can be put in place before year-end testing by the statutory auditor. A material weakness identified and disclosed proactively, with a credible remediation plan already underway, is viewed very differently by a statutory auditor and by the Audit Committee than the same weakness discovered independently and for the first time during year-end audit fieldwork.

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.

Fees are driven primarily by the number of in-scope applications, the complexity of the IT environment (single ERP versus multiple integrated systems), whether regulatory-specific testing (RBI circular compliance, for example) is required, and the entity's size and transaction volume. Because these variables differ so significantly between a single-location mid-market company and a multi-entity regulated financial institution, we do not quote a standard fee without first completing the scoping conversation — but we always confirm the engagement fee in writing before fieldwork begins.

Yes. For groups with operations in both India and the UAE, we coordinate the review across both entities from our Chennai/Bangalore/Hyderabad and Dubai offices under a single engagement, which is particularly useful where a shared ERP instance, shared IT infrastructure, or a common cloud environment spans both jurisdictions. UAE-specific regulatory requirements — including sector-specific cybersecurity requirements set by UAE regulators for financial and other regulated entities — are assessed separately by our Dubai team where applicable, alongside any India-specific requirements.

It is guidance issued by the Institute of Chartered Accountants of India to help statutory auditors form and support their opinion under Section 143(3)(i) of the Companies Act on whether a company has an adequate internal financial controls system operating effectively. The guidance explicitly addresses the role of IT general controls as a foundation for reliance on automated and IT-dependent manual controls — meaning an auditor cannot reasonably conclude financial controls are effective if the underlying IT environment (access, change management) has not been assessed. This is the direct link between ITGC work and the statutory IFC opinion your Board must ultimately stand behind.

The DPDP Act establishes obligations for entities processing personal data of individuals in India — including consent management, data security safeguards, and breach notification. While DPDP compliance is a distinct legal obligation from ITGC/IS Audit, there is meaningful overlap: access controls, encryption, and incident management practices tested during an ITGC review are also foundational to DPDP's 'reasonable security safeguards' requirement. Where personal data is processed within in-scope systems, we flag relevant DPDP-related observations as part of the review, though a dedicated DPDP compliance assessment is a distinct and more comprehensive engagement.

We test both your organisation's own controls and, where feasible, request evidence of the outsourced vendor's relevant controls — for example, a SOC 1 or SOC 2 report if the vendor produces one, or direct confirmation of their access-management and change-management practices. Where a vendor will not or cannot provide adequate assurance, this itself becomes a reportable finding, because outsourcing an IT function does not outsource the accountability for the control — your Board remains responsible for the adequacy of controls over your financial reporting regardless of who operates the underlying system.

Yes, where spreadsheets are used for material financial reporting purposes — such as group consolidation, complex valuation models, or key MIS feeding into the financial statements — we assess End-User Computing (EUC) controls: version control, access restriction, formula integrity checks, and independent review before the output is used. Spreadsheets sit outside the core ERP's system-enforced controls and are a frequently under-controlled area, since they can be altered by anyone with file access and without any audit trail unless specific EUC discipline is imposed.

The Audit Committee (or the Board, where no Audit Committee is mandated) is the primary governance recipient of the ITGC review — approving the scope where relevant, receiving the findings and severity classification directly from the review team, and holding management accountable for the remediation roadmap. This mirrors the reporting-line design used for internal audit, and is intended to preserve independence: findings are not filtered through the same IT management whose controls are being assessed before reaching the body responsible for oversight.

Access management, change management, and IT operations testing can largely be performed remotely through secure access to system-generated data extracts, screen-shares for configuration walkthroughs, and video-based interviews with IT and process owners. Physical and environmental security testing of an on-premise data centre or server room does require an on-site visit, since CCTV coverage, fire suppression, and physical access controls cannot be meaningfully assessed remotely. For cloud-only environments, the engagement can typically be conducted fully remotely.

All system access lists, configuration details, and findings are handled under our standard client confidentiality obligations and, for sensitive technical findings such as unremediated access gaps, are communicated through secure channels rather than plain email attachments where the sensitivity warrants it. Draft reports identifying specific control weaknesses are shared only with the agreed engagement contacts and the Audit Committee — not broadly circulated — until remediation is substantially underway, to avoid the findings themselves becoming a roadmap for misuse before they are fixed.

Access management gaps — specifically, terminated or transferred employees whose system access was not promptly revoked, and privileged/administrator accounts with no documented business justification or periodic recertification. This consistently outranks change-management or backup-related findings in both frequency and severity, largely because the process trigger connecting HR exit processing to IT de-provisioning is often informal or entirely absent, even in companies with otherwise reasonably mature finance controls.

A pure-technology firm can test technical controls competently but often lacks the statutory-audit and Companies Act context needed to frame findings in the language your Board, Audit Committee, and statutory auditor actually need — material weakness classification, Section 143(3)(i) implications, CARO commentary risk. A large firm brings brand recognition but often at a cost and turnaround timeline disproportionate to a mid-market engagement, with more junior staff doing the actual fieldwork. PNPC combines practising-CA statutory audit context with dedicated IS-audit expertise, sized appropriately for mid-market and growth-stage companies, and backed by four decades of practice across India and the UAE.