For a software or fintech business, the financial controls that matter live inside the product and the platform it
runs on. Testing the ledger without testing the systems behind it proves very little. This guide sets out what an it
audit and assurance engagement covers in an Indian technology business, the four general control areas, and why
enterprise customers increasingly ask for the report during procurement. Our note on
risk management audit essentials sets the wider
context.
Key Takeaways
-
Application controls are only as strong as the general controls beneath them, because whoever can change the system
can change the control. - Access management is the most common failure in Indian technology companies, and the cheapest one to fix.
-
For companies selling to enterprise buyers, an information systems audit is a commercial asset rather than a
compliance cost.
Why Systems Testing Is Financial Testing
In a technology business, revenue is calculated by software. Subscriptions renew automatically, usage is metered,
discounts are applied by rules, and refunds are processed through a workflow. Nobody sits with a calculator, which
means the accuracy of reported revenue depends entirely on whether the code and the configuration do what management
believes they do.
The same is true of the controls around payments. An approval limit that exists only as a setting in an application is
a control until somebody with administrator rights changes the setting. Testing the approval without testing who can
change it tests nothing durable.
This is the distinction between application controls and general controls. Application controls are the rules inside
the system: mandatory fields, approval thresholds, automated matching. General controls are the environment those
rules live in: who has access, how changes are made, how the platform is operated and how data is protected.
General controls sit underneath, which is why weakness there undermines everything above it. An auditor who finds poor
change management cannot rely on any application control, however well designed, because there is no assurance it was
in force throughout the period.
For fintech businesses the stakes are higher again, because the platform handles customer money or customer data under
regulatory obligations. Failures there are not only accounting problems, they are licence problems.
None of this requires an enormous programme. Four general control areas tested properly, plus the specific application
controls that drive revenue and payments, is a proportionate scope for a company of fifty to three hundred people.
Scope creep is the usual failure. Teams ask for a security assessment, a penetration test, a privacy review and a
controls audit in one engagement, and receive a document that satisfies none of the readers properly. Decide which
question you are answering before you commission the work, and run the others as separate exercises with their own
scope.
Where application and general controls meet.
Access: The Most Common Failure
Access review is where most Indian technology company audits find their first significant issues, and almost none of
them are sophisticated. Accounts for departed staff remain active. Contractors retain production access months after a
project ends. Administrator credentials are shared between three people because it was convenient during a launch.
The principle is straightforward. Access should be granted on the basis of role, approved by somebody who is not the
recipient, reviewed periodically, and removed promptly when the role changes or ends. Each of those four steps needs a
record, because an auditor cannot test a process that leaves no trace.
Segregation of duties is the second dimension. The person who can create a customer record should not be the person
who can issue a credit note against it. The developer who writes code should not be the person who deploys it to
production. In small teams perfect separation is impossible, and the answer is a documented compensating control such
as an independent review of exceptions.
Privileged access deserves separate treatment. Administrator and root accounts should be individually named rather
than shared, used only when needed rather than as a daily login, and logged. Shared administrator credentials make
every other control unattributable, because no action can be traced to a person.
Periodic review is what keeps this from decaying. A quarterly exercise where each manager confirms the access their
team holds takes a morning and catches almost everything. Businesses that do it annually find that the list has
drifted well beyond what anybody intended.
Our note on
streamlining a business with accounting technology services
covers the practical side of getting systems configured properly in the first place.
Third party access is the piece most often forgotten. Outsourced development teams, support vendors and integration
partners frequently hold standing credentials that nobody reviews, because they were granted by an engineer during an
implementation and never revisited. Include them in the same quarterly review as employees.
Change, Operations and Data
Change management asks a simple question. How does something get from a developer’s machine into the environment that
produces your financial results, and who approved it. A business that cannot answer that for a given release has no
basis for relying on anything the system produced.
The controls are familiar to any engineering team: changes requested and approved, tested in a separate environment,
deployed by somebody other than the author, and recorded so the history can be reconstructed. Modern deployment
tooling produces most of this evidence automatically, which makes the audit easier rather than harder.
Emergency changes are the exception that needs its own rule. There will be occasions when something must be fixed
immediately. The control is not to prevent that but to require retrospective approval and review within a defined
period, so the exception does not quietly become the process.
Operations covers monitoring, scheduled jobs and incident handling. Where a nightly billing job fails silently and
nobody notices until a customer complains, the operational control is absent regardless of how good the billing logic
is. Alerting, an owner and a documented escalation path are what close that gap.
Data protection is the fourth area and backup is the part most often assumed rather than tested. A backup that has
never been restored is a hope rather than a control. Schedule an actual restoration test, document the result, and
repeat it periodically.
Retention and deletion matter too, particularly for fintech businesses holding customer data under regulatory
obligations. Knowing what is held, where, for how long and who can reach it is a question that arrives from customers
and regulators alike.
A first information systems audit that stays proportionate.
Turning the Audit Into a Commercial Asset
Enterprise buyers ask technology suppliers about controls during procurement. Security questionnaires, vendor risk
assessments and contractual audit rights are now routine, and a company that can produce an independent report answers
in days rather than weeks.
That is a genuine commercial advantage in a competitive sale. It shortens procurement, reduces the number of
exceptions the customer’s risk team raises, and signals maturity to a buyer who is deciding whether to depend on you.
It matters for fundraising too. Investors in Indian software and fintech businesses increasingly review the control
environment as part of diligence, and a company that has already tested access, change and operations removes an
obvious workstream from the process.
Scope the engagement with those readers in mind. A report written purely for internal management will not answer a
customer’s questionnaire, and one written for a specific customer may be too narrow for general use. Agree at the
outset who the report is for and what assertions it will address.
Sequence matters as well. Fix the obvious gaps before commissioning a report that will be shown to customers. An
access review, a change management tidy up and a backup restoration test cost little and materially improve what the
report says.
Our note on
risk advisory services and managing growth risks
covers how this fits a broader risk programme, and the
accounting standards material published by the ICAI
sets the professional framework for the financial reporting the systems ultimately feed.
Conclusion
For a technology business, an information systems audit is where financial assurance actually begins. Test access,
change, operations and data before testing the application controls that sit on top of them, fix what the review finds
before showing the report to customers, and treat the result as a commercial asset rather than a compliance cost.
Talk to JPKAD about scoping an it audit and assurance engagement.
