Business case and feasibility

The business case documents the rationale for the investment. It supports the decision on whether to proceed and is also an operational tool for managing the investment through its full economic life cycle, so it stays in use as the project proceeds rather than being written once and forgotten. When a project is not meeting its planned cost-benefit expectations, OMB's Capital Programming Guide calls for a benefit-cost analysis of whether finishing it is still worthwhile, and if not, conceding the sunk costs and terminating the project rather than pushing it through. Stage-gate reviews are the natural points to commit funds to the next activities, stop the work, or put it on hold.[3][4][5]

SDLC and development approaches

A traditional SDLC moves through defined phases; ISACA's glossary lists the typical ones as feasibility study, requirements study, requirements definition, detailed design, programming, testing, installation and postimplementation review. Stage-gates between phases are where the program is reviewed and a decision is made to commit expenditures to the next activities, stop the work, or put it on hold. Agile instead uses flexible, iterative processes: the customer is closely involved, work is divided into short phases, and plans are reassessed and adapted frequently. In agile, a useful place to look for controls is inside each iteration, for example software security criteria added to the definition of done.[5][6][7][8]

Testing levels

Unit testing checks program logic within an individual program or module; integration testing combines software and hardware elements step by step and tests their interactions until the entire system has been integrated; system testing verifies that the integrated hardware and software system meets its specified requirements; acceptance testing determines whether the system satisfies its acceptance criteria so the customer can decide whether to accept it. Each level widens the scope, from a single module to the whole system.[9][10]

Application controls

Input controls (edit and validity checks, completeness, sequence and limit checks, check digits) verify, validate and edit data so that only correct data are entered and errors are caught before processing. Processing controls such as run-to-run totals give evidence that a program processed all input data and processed it correctly. Output controls validate that program output is consistent with the expected content and control physical access to output so unauthorized individuals cannot obtain it.[11][12][13][14][15]

Change and configuration management

Every change to production should be initiated, assessed, authorized, implemented, and validated by separate people or roles, with authorization independent of whoever implements it. Emergency changes can follow expedited authorization but remain subject to emergency authorization controls and later review. A developer who can move their own code to production has end-to-end control of a change, a classic segregation-of-duties finding.[16][17]

Source code escrow

When licensing software, the licensee can require that the source code be held by an escrow agent and released to it if the vendor goes bankrupt or otherwise fails to maintain and update the software as promised. It protects continuity for vendor-built systems the organization can't maintain itself.[18][19]

Post-implementation review (PIR)

Performed once the system is in operation (OMB's Capital Programming Guide says usually after about six months of operation, or immediately after an investment is terminated), to identify how accurately the project meets its objectives, expected benefits and strategic goals, and to capture lessons learned for future projects. It gives a baseline for deciding whether to continue the system as is, modify it, or consider alternatives. Because it measures whether expected benefits are being delivered, it comes after the system has run for a while, not at go-live.[20][21]

Parallel run vs. pilot vs. phased implementation

A parallel run processes the same source data through the new or altered system and another system (possibly the original one), which serves as the standard of comparison, so inconsistencies between the two versions show up. A pilot is a fully tested, limited implementation used to reduce risk before going to production. A phased implementation delivers the system in successive segments, each solving a specific part of the overall problem and delivering a measurable benefit on its own. Whatever the approach, fallback procedures, which may restore the system to its state before the change, should always be considered so normal business continues if the implementation does not work as intended.[22][23][24]

Batch control total vs. hash total

Both are batch controls. A control total adds the values in selected fields of the transactions, such as invoice amounts. A hash total is the total of any numeric data field in a file (it need not be an amount), checked against a control total of the same field to confirm processing accuracy. Sequence control, the other main batch control, numbers records consecutively so each record's presence can be confirmed.[25]

Auditor involvement vs. auditor ownership

Auditors can advise on the design and implementation of new systems, which is when weaknesses are quickest and cheapest to fix. But when performing advisory services they maintain objectivity by not taking on management responsibility, and they must refrain from later assessing activities they were responsible for (objectivity is presumed impaired for 12 months). So the auditor advises without taking ownership of designing, implementing or running the system or the project.[2][26][27][28]