Audit of the information system: what a useful review should cover

An audit of the information system is an independent, evidence-based assessment of whether technology risks are understood and controlled. Its purpose is not to produce the longest possible checklist. It is to show leadership where the system is exposed, why the exposure matters and what should be corrected first.

A useful audit connects governance, technology, data and operational resilience. It examines whether documented controls exist, whether they operate in practice and whether the available evidence supports the conclusion.

Start with scope, not tools

The information system is larger than the IT department. It includes business applications, cloud services, infrastructure, endpoints, identities, data flows, vendors, operating procedures and the people who make decisions about them.

Before fieldwork, the auditor should define:

• the entities, locations and business processes included;
• the critical applications, infrastructure and data in scope;
• the standards, laws, contracts and internal policies used as criteria;
• the period being assessed and the evidence required;
• material exclusions and the risks they create.

Without this boundary, an audit can be technically detailed while missing the systems that matter most to the business.

The control areas that matter

A broad information-system audit normally reviews several connected domains.

Governance and risk. Are responsibilities clear? Are risks recorded, accepted by the right people and tracked through remediation?

Identity and access. Are accounts approved, privileges restricted, departures processed promptly and access reviewed periodically?

Infrastructure and endpoints. Are assets inventoried, securely configured, patched, monitored and protected throughout their lifecycle?

Applications and change. Are changes tested and approved? Are development, administration and production responsibilities appropriately separated?

Data protection. Is sensitive data identified, retained deliberately, transferred lawfully and protected according to its importance?

Resilience and response. Can the organisation detect an incident, contain it, recover critical services and demonstrate that recovery plans work?

Third parties. Are provider dependencies, privileged access, service commitments and exit arrangements understood and reviewed?

An audit is not a penetration test

A penetration test searches for exploitable technical weaknesses in a defined target. It can provide valuable evidence, but it does not by itself assess governance, data handling, recovery, supplier oversight or the consistency of day-to-day controls.

Likewise, a compliance checklist confirms whether specified requirements appear to be met. An information-system audit goes further by testing design and operation, tracing evidence and considering how control failures combine into business risk.

The methods complement one another. They should not be treated as interchangeable.

How the audit should run

A proportionate review typically follows five stages:

1. Scoping: agree objectives, criteria, systems, locations and stakeholders.
2. Document review: examine policies, diagrams, inventories, contracts and prior findings.
3. Fieldwork: interview control owners, observe processes and sample technical evidence.
4. Validation: confirm factual accuracy and understand compensating controls.
5. Reporting: rate findings, explain impact and agree practical remediation priorities.

Findings should be discussed during fieldwork rather than revealed at the final meeting. This improves accuracy and gives teams time to produce missing evidence or explain legitimate exceptions.

What a useful report looks like

The final report must work for two audiences. Leadership needs a concise view of material exposure, trends and decisions. Control owners need precise evidence, criteria, risk statements and achievable corrective actions.

Each finding should explain the condition observed, the expected criterion, the risk created and the recommended response. A prioritised remediation plan should identify owners and target dates. High-risk corrections should be re-tested rather than closed on assertion alone.

Apply the relevant local context

For organisations operating in China, the audit criteria may need to connect group standards with PIPL, the Data Security Law, the Cybersecurity Law and MLPS 2.0. The important step is to determine which obligations apply to the actual systems and data, then map them to one coherent control framework instead of running disconnected reviews.

An effective audit leaves the organisation with fewer assumptions and a defensible plan. If you need to establish the right scope, start with a short audit discussion focused on your critical systems and current concerns.