How to Audit Company Projects: IT Project Audit Checklist

Large IT projects often run late, cost more than planned or deliver systems that nobody can secure or support. A project audit helps catch these problems early. When you audit company projects, you check whether the project is well managed, whether it will meet business needs and whether security and controls are built in.

This guide explains the goals of a project audit, the phases to review and a practical checklist for each phase. It works for software builds, ERP rollouts, cloud migrations and infrastructure upgrades.

Why audit a project?

A project audit gives management an independent view of three questions:

Will the project deliver what the business needs? Requirements, scope and benefits should be clear and agreed.
Is the project well run? Budget, schedule, risks and decisions should be tracked and controlled.
Will the result be secure and supportable? Security, data protection and operational handover should be planned, not left to the end.

Ideally, audit during the project rather than after it. As a result, you can still change course.

Phases to review

Most projects pass through the same broad phases. The audit should cover each one in proportion to risk.

1. Overall project management

First, check the governance that holds the project together:

A sponsor owns the project and has authority to make decisions.
A steering committee meets regularly and records decisions.
The plan shows milestones, dependencies and the critical path.
The team tracks costs against the budget and reports overruns early.
A risk and issue log exists, with owners and actions.
Change requests go through a formal approval process.

2. Project start-up

Next, look at how the project began:

A business case explains costs, benefits and alternatives.
Stakeholders agreed on the scope and success criteria in writing.
The team includes the right skills, or plans to hire or train them.
A security and privacy risk assessment happened at the start.

3. Requirements, design and development

Then check whether the solution will meet needs and include controls:

Business, security and compliance requirements are documented and traceable.
Architects reviewed the design, including integration and data flows.
Developers follow secure coding standards and peer review.
For bought software, the vendor met your security requirements before you signed.

4. Testing

Testing shows whether the system really works:

Test plans cover functions, performance, security and user acceptance.
Business users sign off acceptance tests.
The team fixes or formally accepts defects before go-live.
Test environments do not use unprotected production data.

5. Implementation

At go-live, risks peak. So review:

a cutover plan with rollback steps;
data migration checks, such as record counts and reconciliations;
updated access rights, so only the right people can use the new system;
handover to operations, including monitoring, backups and support contacts.

6. Training and documentation

Finally, make sure people can use and support the system:

Users receive training before go-live.
Support teams receive runbooks and admin guides.
Documentation explains configuration, interfaces and recovery steps.

7. Post-implementation review

A few months after launch, compare actual results with the business case. Did the project deliver the expected benefits? What lessons should the next project use?

Warning signs auditors look for

The budget keeps growing, but nobody reports it formally.
Security reviews are planned for “after go-live”.
Requirements change weekly without approval.
Key decisions exist only in emails or chats.
One vendor or person holds all knowledge of the system.

Related guides

Sources

ISACA: IT audit resources

Preparing for an ISO 27001 or IT audit? Our ISO 27001 readiness assessment finds your gaps before the auditor does. You can also start with our free ISO 27001:2022 readiness checklist, or contact us for a quote.

Why audit a project?