If a company installs a new accounting system and it crashes on the first day of the tax year, the business can lose millions in revenue and face regulatory fines. That is why auditors must evaluate how systems are implemented and tested—to ensure that new software or hardware goes live safely, works as intended, and does not disrupt the organisation's critical operations. Without this evaluation, a company could spend a fortune on a system that fails.
Jump to a section
A simple way to picture System Implementation and Testing
A town buys a 47-room hotel to turn into its new town hall. The IT team's job is to move all 47 rooms—offices, meeting spaces, the boiler room—into a new building without losing a single file cabinet or switchboard, and without stopping the town from operating for more than a weekend.
First, they plan the move room by room, testing each doorframe's width and each floor's power outlets. This is like system implementation—installing the new software and hardware in a controlled environment before going live.
Next, they run a 'dress rehearsal': they open the new building for a single day with fake citizens (test data) to ensure the lifts work, the phones connect, and the mayor's office has the right keycards. That's testing—verifying every function works as expected.
Finally, they move the real staff in over a weekend, keeping the old hotel open as a backup. When someone can't find the toilet on Monday, they quickly deploy a paper map and a help desk. That's the post-implementation review—checking for problems and fixing them on the spot.
This analogy works because hotel renovation requires careful planning, incremental testing, and rapid recovery—exactly like implementing and testing a new IT system without breaking the business.
System implementation and testing is the process of moving a new or upgraded information system from a development environment into live production use. For a complete beginner, think of it as the difference between building a car in a factory (development) and then letting people drive it on real roads (implementation). The implementation phase is where the car gets delivered, inspected, and handed over to drivers.
The process typically begins with system implementation—the actual installation and configuration of the new software, hardware, or network components. This includes moving data from old systems to new ones (a task called data migration), installing software on servers and user computers, and connecting everything together. The goal is to ensure the new system is physically and logically ready for use. Implementation can happen in several ways. A direct cutover (also called 'big bang') means switching off the old system and switching on the new one at the same time—risky but fast. A parallel run means running both old and new systems simultaneously for a period, so if the new one fails, the old one is still available—safer but more expensive. A phased implementation rolls out the system in stages, such as department by department or module by module, reducing risk while controlling costs.
After implementation comes testing—the systematic process of verifying that the system meets its requirements and functions correctly. There are several types of testing that auditors care about:
Unit testing checks individual components (like a single function or module) to ensure they work alone.
Integration testing checks that these components work together, like ensuring the login module communicates properly with the database.
System testing checks the entire system as a whole, end to end, under conditions that simulate real use.
User acceptance testing (UAT) is where the actual end users try the system with their own real-world tasks to confirm it meets their needs. This is the final 'thumbs up' before the system goes live.
Security testing (often called penetration testing or pen testing) tries to break into the system to find vulnerabilities before attackers do.
Performance testing checks how the system behaves under heavy loads, such as during peak hours.
Each testing phase has specific documentation: test plans outline what will be tested and how, test scripts provide step-by-step instructions for testers, and test results reports record what passed and what failed. When a test fails, the problem is logged as a defect or bug, and developers fix it before retesting.
After the system is implemented and tested, the organisation must conduct a post-implementation review (PIR). This is a formal evaluation, usually conducted 30 to 90 days after go-live, to assess whether the system achieved its intended objectives—such as faster processing time, lower costs, or better accuracy. The PIR also identifies lessons learned for future projects. For a CISA auditor, the PIR documents are a goldmine of evidence showing whether the project was managed properly.
Why does this process exist? Before modern implementation and testing practices, companies would often install new systems without adequate checking, leading to catastrophic failures—lost data, broken processes, and even regulatory penalties. Today, structured implementation and testing replaces guesswork with evidence, risk management with control, and hope with certainty. It ensures that the system does what it is supposed to do, that data is accurate and complete, and that the business can keep running during the transition.
1. Requirements Definition and Planning
Before any code is written or hardware purchased, the organisation defines what the new system must do. The project team documents functional and technical requirements. For example, a new payroll system must handle 5,000 employees and comply with tax regulations. This step ensures everyone agrees on what success looks like.
2. Environment Preparation and Installation
The IT team sets up the infrastructure needed for the new system—servers, databases, network connections, and security controls. They then install the software and configure it according to the requirements. This is the 'implementation' part of the process. Without proper environment preparation, the system may not perform as expected.
3. Testing (Unit, Integration, System, and UAT)
The team executes a series of tests in increasing scope: first individual components (unit testing), then how they interact (integration testing), then the entire system (system testing), and finally with real end users (UAT). Each test level generates documentation that the CISA auditor will review. Testing reveals defects that must be fixed before proceeding.
4. Data Migration and Cutover
Data from the old system is extracted, transformed, and loaded into the new system. The team validates that the data matches through reconciliation reports. The cutover is the moment when the old system is switched off and the new system is switched on. A parallel run can be used here to reduce risk.
5. Go-Live and Initial Support
The new system goes live for production use. A support team is on standby to handle issues immediately. The team monitors system performance and user activity for the first few days. This is a high-pressure period because any unidentified defect can disrupt the business.
6. Post-Implementation Review (PIR)
After 30 to 90 days of stable operation, a formal review is conducted. The review compares actual outcomes (e.g., processing time, cost savings, user satisfaction) against the original business case. Lessons learned are documented to improve future projects. This step provides the auditor with evidence that the implementation was successful and controlled.
An IT professional, let's call him Alex, works for a mid-sized retail company that is replacing its outdated inventory management system. The old system runs on a server in the basement and uses software from 2005. The new system is a cloud-based solution hosted by a vendor. Alex is the lead implementation manager.
First, Alex coordinates with the vendor to set up a staging environment—a replica of the live system where testing can occur without risking real data. He works with the development team to perform data migration from the old system's spreadsheets and databases into the new system's database. He validates the migrated data by comparing row counts and sample records.
Next, Alex runs a series of tests. He gives the warehouse staff access to the staging environment for user acceptance testing. The staff try scanning barcodes, updating stock levels, and generating reports. They find that the new system does not handle a specific type of bulk discount correctly—a defect. Alex logs it in the tracking system, and the vendor fixes it. After a second round of UAT, the staff sign off.
Then Alex executes integration testing with the company's existing accounting system, sales platform, and shipping provider APIs. He discovers that the shipping API times out under load. He works with the vendor to increase the timeout threshold and retests.
For the go-live, Alex plans a parallel run for one week. The old system continues to operate while the new system runs alongside. Every morning, warehouse staff enter transactions in both systems and compare the outputs. On day three, they notice that the new system is not updating inventory for returns. Alex finds a configuration error and fixes it. By day seven, the systems match perfectly.
After the parallel run, Alex decommissions the old system and schedules the post-implementation review for 60 days later. In the PIR, he surveys users, analyses system performance logs, and compares actual benefits (e.g., 20% faster order processing) against the business case. He writes a report with recommendations for future improvements, such as training staff on advanced reporting features.
Throughout this process, Alex updates the project management office (PMO) on progress, maintains a risk register (a document listing potential problems and their fixes), and ensures all change requests (any modifications to the original plan) are formally approved. This is exactly what a CISA auditor will examine—the trail of evidence proving that implementation and testing were done properly.
The CISA exam tests your understanding of system implementation and testing in several specific ways. You can expect around 5-10 questions on this topic in the actual exam. The examiners love to test your ability to distinguish between different implementation approaches, testing types, and the roles of various stakeholders.
Key concepts you must memorise:
Direct cutover vs. parallel vs. phased implementation: Know the risk level and cost of each. Direct cutover is highest risk but lowest cost; parallel run is lowest risk but highest cost; phased is a middle ground. CISA often asks which approach to recommend in a given scenario (e.g., for a critical financial system, you would recommend parallel run).
User acceptance testing (UAT) is always performed by end users, not IT staff. This is a common trap: the exam will describe an IT team testing and call it UAT—the correct answer is that only end users can sign off on UAT.
Post-implementation review (PIR) is not optional—the exam treats it as a mandatory control. Questions often ask who should conduct the PIR (usually an independent internal audit team, not the project manager) and what it should evaluate (achievement of objectives, cost vs. benefits, user satisfaction).
Defect tracking and change management during testing: The exam tests that all defects must be logged, prioritised, fixed, and retested before go-live. Any change to the system during testing must go through a formal change control process.
Data migration is a high-risk area. The exam tests that data must be validated for accuracy, completeness, and consistency after migration.
Security testing (penetration testing, vulnerability scanning) must occur before go-live, especially for systems handling sensitive data. The exam loves to ask who should perform security testing (ideally an independent third party).
Trap patterns to watch for:
The exam might describe a situation where a system goes live without UAT. The correct answer is always: this increases the risk of user dissatisfaction and business process failure.
They might suggest that the development team signs off on testing. The correct answer: development signs off on unit and integration testing, but end users sign off on UAT.
They might frame a question where a parallel run is recommended but the budget is limited. The correct choice might be a phased implementation instead.
They might ask about the timing of the PIR. The correct answer is generally 30-90 days after go-live, not immediately or after a year.
Memorise these definitions exactly as they appear in the CISA review manual: - Implementation: The process of installing and configuring a new system. - Testing: The process of verifying that the system meets requirements. - Post-implementation review: A formal evaluation of the system's achievement of objectives. - Defect: Any deviation from expected behaviour. - Change control: The formal process for managing changes to a system during its lifecycle.
System implementation has three main approaches: direct cutover (high risk, low cost), parallel run (low risk, high cost), and phased implementation (middle risk, middle cost).
User acceptance testing (UAT) must be performed by actual end users, not by the IT development team, and sign-off must come from the business.
A post-implementation review (PIR) is conducted 30 to 90 days after go-live to evaluate whether the system achieved its intended objectives and to document lessons learned.
Data migration is a high-risk activity that requires validation of accuracy, completeness, and consistency before and after the move.
All defects found during testing must be logged, prioritised, fixed, and retested before the system can be deployed into production.
Security testing, including penetration testing, should be performed by independent third parties to ensure objectivity and thorough coverage.
These come up on the exam all the time. Here's how to tell them apart.
Direct Cutover
Old system is completely switched off at go-live
Lowest cost because only one system runs
Highest risk of business disruption if new system fails
Parallel Run
Old and new systems run simultaneously for a period
Higher cost due to double operation and reconciliation effort
Lowest risk because old system serves as backup
Unit Testing
Tests individual components or modules in isolation
Performed by developers during development
Catches bugs within a single function or unit of code
Integration Testing
Tests interactions between multiple components or systems
Performed after unit testing, often by testers or QA team
Catches interface and data flow issues between units
User Acceptance Testing (UAT)
Performed by actual end users from the business
Focuses on whether the system meets business needs
Final sign-off before go-live
System Testing
Performed by IT testers or QA team
Focuses on technical correctness and requirements
Occurs before UAT, validates the system holistically
Performance Testing
Evaluates system response time under load
Measures throughput and scalability
Uses tools to simulate high user traffic
Security Testing
Evaluates system resilience to attacks
Identifies vulnerabilities like SQL injection or weak passwords
Uses penetration testing and vulnerability scanning tools
Mistake
Testing is only done by the IT team, and if it works in the test environment, it will work in production.
Correct
Testing must involve actual end users (UAT) and must be performed in an environment that mirrors production as closely as possible. Differences between test and production environments often cause failures.
Beginners assume that because developers tested the system technically, it is ready for business. But developers do not know how real users will interact with the system, and test environments often lack the full data, network, and hardware of production.
Mistake
A post-implementation review is only done if something goes wrong.
Correct
A PIR should be conducted for every major system implementation, regardless of success. Its purpose is to capture lessons learned and validate that objectives were met, not just to troubleshoot failures.
People associate reviews with problems because of common language (e.g., 'post-mortem'). In IT auditing, a PIR is a standard control, not a reaction to failure.
Mistake
Parallel run means both systems run forever, so it is the safest and cheapest option.
Correct
Parallel run is the most expensive option because it requires double the work for a limited period (usually days or weeks). It is intended as a temporary safety net, not a permanent solution.
The word 'parallel' might imply running in parallel indefinitely, but in practice, running two systems simultaneously doubles costs and creates data reconciliation issues, so it is always temporary.
Mistake
Security testing is optional if the system is not exposed to the internet.
Correct
Security testing is essential for all systems, including internal ones, because insider threats, malware, and misconfigurations can cause breaches even without internet exposure.
Beginners often think that only internet-facing systems need security testing, but internal systems can be compromised by employees, contractors, or malware introduced via USB drives.
Mistake
Once a system passes testing, it never needs to be tested again.
Correct
Systems must be retested after any change, such as patches, upgrades, or configuration modifications. Continuous testing is part of ongoing operations.
People expect testing to be a one-time event, but changes introduce new defects. The CISA exam emphasises that testing is iterative and must be repeated whenever the system changes.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Unit testing checks a single piece of code or component in isolation, like testing a login button. Integration testing checks how different components work together, like ensuring the login button correctly passes data to the database. Both are necessary for a reliable system.
UAT is performed by the end users—the people who will actually use the system in their daily work, such as accountants testing a new finance module. IT staff do not perform UAT; they only facilitate it. The users must sign off that the system meets their needs.
During a PIR, the project team and stakeholders evaluate whether the new system achieved its objectives, stayed within budget, and met user expectations. They identify what went well and what could be improved. This review typically includes interviews, surveys, and analysis of performance data.
It depends on risk tolerance and budget. Direct cutover is cheaper and faster but carries the highest risk of business disruption if something fails. Parallel run is safer because the old system remains available as a backup, but it costs more because both systems must be operated simultaneously. For critical systems, parallel run is recommended.
Data migration is the process of moving data from old systems to a new one. It is risky because data can be lost, corrupted, or incorrectly mapped during the transfer. If employee salaries or customer addresses are wrong, the business can face serious legal and operational problems. That is why validation and reconciliation are essential.
No, especially not for critical defects. All high-priority defects should be fixed and retested before go-live. Low-priority defects may be deferred with formal approval, but any unresolved defect must be documented and accepted by the business. An auditor would view a go-live with known critical defects as a major control weakness.
You've finished System Implementation and Testing. Continue through the CISA study guide to build a complete picture of the exam.
Done with this chapter?