IT Audit and IT General Controls (ITGC)

An IT audit and ITGC consultant is usually brought in because a financial statement auditor has issued a request list, and nobody internally is confident about which items on it are the company's job to produce or what a good answer to them would look like.

A weakness in these controls is pervasive rather than isolated, and that is the part that surprises people. One access review that was never performed does not stay a small finding about one review. It undermines every automated control and every system-generated report that rests on the same access model, which is how it turns into a material weakness.

The three domains an IT audit and ITGC consultant tests

Access to programs and data

Who can get into the system, what they can do once inside, and whether that has been checked lately. In practice: provisioning tied to an approval, de-provisioning tied to a leaver process that actually runs, privileged and administrative accounts inventoried and justified, periodic access reviews performed by someone who understands what the entitlements mean, authentication standards, and (persistently the most common finding) generic and shared accounts that cannot be attributed to an individual.

The access review is where most programmes fail, and it fails in a specific way. The review is performed by a manager who receives a list of usernames and role codes, cannot interpret them, and approves the list. The control exists on paper and provides nothing.

Program change management

How code and configuration reach production. Changes authorised before they are made, tested before release, approved by someone other than the developer, and migrated by someone who cannot also write the code. Emergency changes are the recurring weak point, legitimate in principle, but frequently the route by which normal change control is bypassed with retrospective documentation that was never actually reviewed.

Computer operations

Job scheduling and monitoring of failures, backup execution and (importantly) restore testing, incident management, and the ability to demonstrate that data processed completely and accurately. A backup regime nobody has tested a restore from is a plan, not a control.

Cloud and SaaS change what gets tested

Where the financially significant application is a SaaS product, the traditional ITGC questions change shape. You do not control the change management process; the vendor does. You do control who has access, how your tenant is configured, what integrations move data in and out, and whether you obtain and read the vendor's SOC 1 or SOC 2 report.

That last item is where most companies stop short. Obtaining the report is treated as the control. It is not. The report contains complementary user entity controls, things the vendor explicitly states you must do for the vendor's controls to be effective. Those are your responsibility, they are rarely read, and an auditor who reads them will ask how each is satisfied.

Infrastructure-as-a-service brings its own scope: IAM policy, network configuration, logging and monitoring, and infrastructure-as-code change control. That overlaps heavily with the cloud security compliance work, and where both are in scope they are tested once rather than twice.

Financial services and FFIEC expectations

Twenty years auditing banks, insurers and mortgage companies produced familiarity with a regulatory environment that is more prescriptive than most: FFIEC IT examination expectations, GLBA safeguards obligations, third-party and vendor management programmes that examiners test in detail, business continuity and resilience requirements, and the specific scrutiny applied to core banking, loan origination and claims systems.

Institutions in Los Angeles County and Ventura County preparing for an examination, or responding to findings from one, are a recurring client type. The value is knowing what an examiner will actually look at; which is narrower and more specific than the published guidance suggests.

Life sciences: 21 CFR Part 11 and GxP

The biotech and medical device concentration along the 101 corridor through Thousand Oaks, Newbury Park and Camarillo generates a distinct variant of this work. Systems holding regulated records fall under FDA 21 CFR Part 11, which imposes requirements (validation, audit trails, electronic signature controls, record retention and system access) that overlap substantially with ITGC but are assessed against a different standard and by a different kind of inspector.

Companies frequently run these as two disconnected programmes: a validation effort owned by quality and an ITGC effort owned by finance, testing many of the same controls twice against different documentation. Mapping them once removes a meaningful amount of duplicated work.

What you receive

A control matrix mapping each ITGC to the financial statement assertions and application controls it supports, so that the significance of a failure is visible rather than assumed. Testing workpapers with evidence retained to a standard an external auditor can rely on. A findings register distinguishing design gaps from operating failures, because they require different remediation. And a remediation plan that accounts for what the IT team can realistically deliver alongside its existing commitments.