IS Audit & ITGC Review: Where It Goes Wrong
The failures on IS Audit & ITGC Review repeat, which means they are avoidable if you know what to watch. 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.
We are a mid-sized private company using Tally or Zoho Books with a handful of users. Do we really need a formal ITGC review?
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.
In practice: We scope this honestly. If a full ITGC engagement is disproportionate to your risk profile, we say so and recommend the lighter-touch alternative — a generic package sold regardless of fit does not serve the client well.
What counts as a 'material weakness' versus a 'significant deficiency' versus a 'control deficiency' in ITGC findings?
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.
In practice: We deliberately frame ITGC findings in financial-reporting-risk language, not just technical IT language — a Board or Audit Committee member without a technology background needs to understand why a dormant admin account matters to the integrity of the balance sheet, not just that it is 'a security best-practice gap'.
What RBI circulars or master directions govern IS Audit for regulated entities?
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.
In practice: RBI's regulatory framework for IS audit has evolved over time and continues to be refined for different categories of regulated entities. We treat 'confirm the current applicable circular for this specific entity' as a mandatory first step on every regulated engagement — not an assumption carried over from a prior year's scope.
Does an ITGC review help with ISO/IEC 27001 certification, or are they completely separate exercises?
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.
In practice: We are explicit with clients that we support ISO 27001 readiness — we do not certify. Any firm that offers to both prepare you for certification and issue the certificate itself has a conflict of interest worth questioning.
Our IT team says our systems are secure because we have never had an incident. Is that a reasonable basis to skip an ITGC review?
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.
In practice: We have, more than once, identified a genuine security incident during ITGC fieldwork that the client's own IT team was unaware had occurred — surfaced through anomalies in access logs or unexplained configuration changes that nobody had reviewed until we asked for the raw log extract.
Can a startup with a lean IT team realistically implement the remediation you recommend?
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.
In practice: A remediation roadmap the client cannot realistically execute is not useful advice — it is a document that sits in a drawer. We calibrate every recommendation to the organisation's actual operating capacity, and revisit the roadmap the following cycle to see what genuinely got implemented.
Can PNPC support both the India entity and a related UAE entity's IT controls review under one engagement?
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.
In practice: Groups running one shared ERP instance across an Indian and a UAE entity often assume a single review covers both jurisdictions' requirements — it frequently does not, because the regulatory drivers differ. We flag this distinction explicitly during scoping rather than let a client discover the gap later.
How does PNPC ensure the confidentiality of sensitive system access data and vulnerability information gathered during the review?
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.
In practice: We are deliberate about not creating a single unencrypted document listing every open control gap in an organisation's environment and circulating it widely — the report itself, until remediated, is sensitive information that needs to be handled with the same discipline we are recommending the client apply to their own systems.
What is the single most common finding PNPC identifies across ITGC engagements in the Indian mid-market?
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.
In practice: If a company can only afford to fix one thing before their next audit or regulatory filing, we tell them: fix the joiner/leaver access process first. It is the highest-frequency, highest-risk, and — relative to most other ITGC remediation items — genuinely the cheapest and fastest to correct.
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 — reviewing the facts, preparing and filing what is required, and dealing with the authority through to closure.