Application Controls: Input, Processing and Output
The controls that make a system's transactions complete, accurate and valid, and how they differ from the general controls beneath them. The exam tests which category a control belongs to, and why input validation alone is not enough.
What this makes you able to do
Evaluate whether an application's controls ensure the completeness, accuracy, validity and authorisation of its transactions across input, processing and output.
By the end you can
- Classify a control as input, processing or output, and state what it assures.
- Distinguish application controls from general (IT) controls.
- Explain why controls are needed across all three stages, not input alone.
Transcript
Application controls: input, processing and output. This is the last lesson of Domain 3, and it is where the whole domain’s goal, a system you can trust, becomes concrete, in the controls inside the application that make each transaction dependable.
Start with the situation. A clerk mistypes an account number. Does the system catch it at the point of entry, or does the payment go to the wrong account, process cleanly, and appear on a report as if it were correct? The answer depends on whether controls sit at every stage of the flow, not just the first one.
First, the distinction the exam returns to again and again. Application controls are specific to one application or business process, and they assure that application’s transactions: their completeness, accuracy, validity and authorisation. General controls, the I-T general controls at the heart of the ITGC world, are pervasive across the whole environment: access management, change management, operations, physical security. They do not process transactions; they create the conditions in which application controls can be trusted.
And the dependency runs one way. If change management is weak, someone can alter the application’s logic without authorisation, and every application control inside it is now suspect. So strong application controls sitting on weak general controls give false comfort. When a question asks you to tell them apart: application controls are specific to a process and assure its transactions; general controls are pervasive and assure the environment.
Within an application, the controls are grouped by where in the flow they act, and the objective is the same throughout, completeness, accuracy, validity and authorisation, but each stage guards a different point.
Stage one, input controls, ensure the data entering the system is right before it is accepted, the cheapest place to catch an error, at the door. Validation and edit checks: range, limit, format and existence checks. Check digits, catching a transposed or mistyped identifier like our account number. Sequence checks, catching missing or duplicate items in a numbered series. Batch control totals, and authorisation that the input was permitted.
Stage two, processing controls, ensure the data is handled completely and accurately once inside. The data was correct going in; these confirm nothing was lost or corrupted while the system worked on it. Run-to-run totals, carrying record counts and control totals from the start of a run to the end and comparing them. Reconciliation between files or stages. And reasonableness and limit checks applied during calculation.
Stage three, output controls, ensure the results are complete, accurate and reach only the people entitled to them. Reconciling the output back to the input and processing control totals. Review of the output for completeness and reasonableness. Controlled distribution, so a report of sensitive data goes only to authorised recipients. And error and exception reports, surfacing what did not process correctly.
Here is the point: one stage is never enough. Perfect input validation does not help if a processing error then corrupts the data, or if a clean, correct report is emailed to the wrong distribution list. Each stage catches only its own kind of failure.
Picture the failure chain. A transaction can be entered correctly, processed wrongly, and output to the wrong person. Only a control at each stage catches the failure that belongs to it. That is why the auditor’s question is never just, is there input validation. It is whether completeness, accuracy, validity and authorisation are protected all the way through.
So think of the shape of it as in, through, out. Correct in at the front, intact through the middle, and out only to the right hands. That end-to-end assurance is exactly what makes the delivered system trustworthy, which was the whole purpose of Domain 3.
So carry this away, and it closes the domain. Application controls assure a process’s transactions; general controls assure the environment those controls run in, and weak general controls quietly undermine strong application ones. And do not treat robust input validation as the whole job: input controls only guard the door. A trustworthy system needs control across input, processing and output together. That completes Domain 3.
1.A data-entry screen recalculates and verifies the check digit on every account number a clerk types. This is an example of which type of application control?
2.During a nightly batch run, the system compares the record count and total value at the start of processing against the count and total at the end. This is an example of which type of control?
3.What distinguishes application controls from general (IT) controls?
Independent training produced by Marco Cavani. Not affiliated with, endorsed by, or sponsored by ISACA. CISA is a registered trademark of ISACA. Practice questions are written for this course and are not reproduced from ISACA materials.
Stay ahead of cyber threats
Get the latest cybersecurity reports, threat intelligence, and IT governance insights delivered straight to your inbox. No spam. Unsubscribe any time.
No spam. Unsubscribe at any time.
