CISA Domain 3: IS Acquisition, Development & Implementation — Free Visual Study Notes

Project governance is the set of structures, policies, and control mechanisms that keep IT projects aligned with enterprise strategy and risk appetite. Effective governance tracks three categories of management factors. Hard factors are quantifiable: deliverables, quality targets, cost, and deadlines. Soft factors cover people dynamics: team communication, conflict resolution, leadership style, and cultural alignment. Environmental factors address the political landscape: managing stakeholder expectations, power dynamics within the sponsoring organization, and the ethical and social context surrounding a project. A project portfolio groups concurrent projects so leaders can identify shared objectives, manage resources, and resolve conflicts across initiatives. Without a governance structure that monitors all three factor types, any one of them can derail a project regardless of how healthy the budget report looks.

Project management is the structured application of knowledge, tools, and techniques to deliver a defined objective — meeting user requirements within budget and on schedule. As a business process, it has formal boundaries. The lifecycle begins when a project charter is created, which documents the project's objective, scope, sponsor, and key stakeholders. The process ends when formal project completion is documented and signed off. Between those bookends, project management encompasses planning, execution, monitoring, and control. An IS auditor reviewing a project should verify both boundary documents exist; their absence signals that the project was never formally authorized or properly closed.

Project management organizational structure determines how authority and control are distributed between project managers and functional department heads. In a functional structure, the project manager has no formal management authority; work is organized by department, and the PM can only advise. In a project-structured organization, the PM has full authority over a dedicated team, with department boundaries subordinated to project needs. In a matrix structure, authority is shared: functional managers retain HR control while the PM directs day-to-day task priorities. The degree of PM influence in a matrix varies from weak (mostly functional) to strong (mostly PM-led). Auditors verify that governance documents reflect the actual authority structure in use.

Project governance assigns distinct accountabilities to four key roles arranged hierarchically. The project steering committee sits at the top, providing strategic direction and holding ultimate responsibility for all project deliverables, costs, and schedules; it ensures that major stakeholders are represented in project decisions. Below it, the project sponsor champions the initiative at the executive level, owns the business case, and makes escalation decisions. The project manager handles day-to-day management: planning, executing, monitoring, controlling scope, budget, and schedule. The project team does the technical and functional work within the boundaries set by those above. An IS auditor verifies that each role has a named person, documented authority, and a clear handoff process between levels.

Project management techniques provide systematic ways to plan, track, and control time and resources. A Gantt chart is a bar-format timeline that maps tasks against a calendar, making schedule slippage visible at a glance. PERT (Program Evaluation and Review Technique) uses a network of task dependencies and three-point duration estimates — optimistic, pessimistic, and most likely — to model schedule uncertainty. The Critical Path Method (CPM) identifies the sequence of dependent tasks with zero float; delay on any critical-path task delays the entire project. Earned Value (EV) analysis provides an integrated cost-schedule status by comparing what was budgeted for completed work against what was actually spent. IS auditors use these techniques to evaluate whether project controls can detect and report deviations early.

Portfolio management provides enterprise-level visibility into all concurrent IT initiatives, enabling leaders to identify overlapping objectives, allocate shared resources, and manage risk across the full body of work. A program is a structured grouping of related projects that share common strategies, objectives, budgets, or schedules, allowing coordinated management of interdependencies that individual project teams cannot see. The Project Management Office (PMO) establishes and enforces the processes, templates, and reporting standards that projects and programs must follow, but it does not direct project content or make delivery decisions. IS auditors treat the PMO as a governance control — its existence, charter, and scope of authority are audit-relevant artifacts. Weak portfolio governance is often a leading indicator of resource conflicts, duplicated investments, and unmanaged interdependency risk.

A Project Management Office is a permanent organizational unit that owns the project and program management process across an enterprise. Its role is procedural: it sets standards, maintains methodology, and produces portfolio-level reporting. It does not manage individual project content. The four objectives of project portfolio management are optimizing portfolio-level results (not individual project results), prioritizing and scheduling projects, coordinating resources across projects, and enabling knowledge transfer. A mandatory project portfolio database records owner, schedule, objectives, type, status, and cost for every active project. Typical portfolio reports include bar charts of project status, profit-versus-risk matrices, and progress graphs. An IS auditor reviews the PMO's procedural controls — existence of standards, currency of the portfolio database, quality of reporting — rather than evaluating the technical content of individual projects.

Benefits realization management ensures that IT-enabled investments deliver the value they promised, not just that projects finish. Three delivery requirements must be met: capabilities should arrive on time, respecting schedule and time-sensitive market or regulatory windows; they should be delivered within the approved budget; and IT services and assets must continue to generate measurable business value after go-live. Meeting the first two requirements closes a project. Meeting the third is what makes the investment justified. IS auditors verify benefits realization by checking that a pre-launch baseline was established, that benefit metrics are defined and tracked, and that a formal review process exists to compare actual outcomes against the original business case projections.

Project initiation is the formal process of gathering, documenting, and approving the information needed to authorize a project. The process begins when a project manager or sponsor compiles a terms of reference or project charter that captures the project's objectives, the intended stakeholders of the resulting system, the name of the project manager and sponsor, and initial scope. This documentation is formalized into a project initiation document (PID) or project request document (PRD). When an authorized decision-maker approves the PID or PRD, the project is formally sanctioned to proceed. Without an approved initiation document, any project activity — spending, resource assignment, or vendor engagement — occurs without sanctioned authority, which is a material control gap for IS auditors.

Project objectives are specific action statements that operationalize broader project goals. Every objective must satisfy the SMART criteria: Specific (unambiguous), Measurable (quantifiable), Attainable (achievable given constraints), Realistic (relevant to the goal), and Timely (time-bound with a deadline). An Object Breakdown Structure (OBS) decomposes the solution into its component parts and their relationships in a hierarchical format; it is particularly useful when deliverables are intangible. After the OBS is established, a Work Breakdown Structure (WBS) is created to structure all tasks required to build the OBS components. The WBS consists of work packages — the smallest controllable units — each with a distinct owner. The WBS serves as the central communications tool and forms the baseline for cost and resource planning. An IS auditor examines whether both structures exist, are current, and have work package owners assigned.

Every IS project must be planned and controlled across eight dimensions: scope, tasks, task sequence, task duration, task priority, resources, budget, and funding sources. Cost estimation for IS development projects is particularly challenging because these projects are large, integrated, and multi-component. Four standard estimation methods apply: Analogous estimating derives estimates from prior similar projects — quickest but least precise. Parametric estimating applies statistical relationships (such as cost per function point) to historical data for greater precision. Bottom-up estimating sums costs at the individual work-package level and aggregates upward — most accurate but most time-consuming. Three-point estimating calculates a weighted average of optimistic, most-likely, and pessimistic scenarios to account for uncertainty. An IS auditor assesses whether a documented estimation methodology was used, whether it is appropriate for the project's size and complexity, and whether the plan covers all eight planning dimensions.

Project execution begins when planning is complete and the program manager, coordinating with the PMO, activates the tasks described in project plans and procedures. The execution phase is not passive — it requires active monitoring of production output and quality metrics. Critically, this monitoring must cover both internal team members and external contractors or vendors contributing to the project. A key success factor is integrated oversight across all contributors: requirements, architecture, design, and coding standards must be enforced uniformly whether the contributor is an employee or a third party. Execution also involves ongoing coordination to ensure the project remains aligned with the system requirements and technical architecture established during planning. IS auditors verify that metric coverage extends to all delivery parties, not just internal staff.

Project controlling and monitoring encompasses the ongoing oversight activities that keep a project aligned with its approved parameters. Three primary dimensions require continuous management. Scope management demands that any new requirement be formally documented — typically through a change request — reviewed, approved, and allocated resources before implementation; undocumented changes are a material control failure. Resource usage monitoring tracks actual spending, staffing, and effort against the approved project plan, identifying deviations early enough to correct them. Risk management applies to the project lifecycle continuously: as scope or environment changes, new risks emerge and must be assessed and mitigated. Effective change control integrates all three — a change request triggers scope evaluation, resource re-assessment, and risk analysis before approval.

Project closing is a structured process that transitions a finished project into operational status. The project has a finite life, and at its end, the new or modified system must be formally handed over to users and operational support staff. Any open issues that exist at closure time must be documented and assigned to responsible owners — they cannot simply be abandoned. The project sponsor must confirm that the delivered system meets acceptance criteria before sign-off. The PM issues a formal project closure notification to signal the official end of the project and release of project resources. Finally, lessons learned must be captured to benefit future projects and avoid repeating mistakes. Without formal closure, the project enters an ambiguous state where accountability is unclear and development resources continue to be consumed informally.

The IS auditor plays an active role throughout the systems development life cycle, not only after a system goes live. This involvement allows the auditor to ensure controls are designed into a system before it is built, rather than retrofitted afterward. The auditor's tasks include: identifying components, objectives, and areas of control need; assessing risk and ranking exposures; consulting authoritative sources to identify mitigating controls; advising on control design and implementation; and monitoring deliverables through periodic documentation reviews. If deficiencies are found, the auditor advises the project team and escalates to senior management when required. A critical constraint is independence: the IS auditor advises but does not make control design decisions. Management retains accountability for implementing or rejecting the recommended controls. Post-implementation review remains an option but is not a substitute for engagement during development.

Before any significant IT investment, the organization should complete a feasibility study with four independent dimensions. Economic feasibility evaluates whether the investment's financial returns justify the spend through cost-benefit analysis, ROI, NPV, and payback calculations. Technical feasibility confirms that the necessary technology and staff capabilities exist to deliver and sustain the system. Operational feasibility assesses whether users will actually adopt and use the system as intended, including change management and training considerations. Legal feasibility verifies compliance with applicable regulations, licensing terms, privacy requirements, and contractual obligations. The output of this process is a formal business case — a written, executive-signed document summarizing all four dimensions. From an IS auditor's perspective, the absence of any feasibility dimension or the business case document itself is a material control gap.

The IS auditor's role in reviewing a business case goes beyond checking whether one exists. The auditor first evaluates the adequacy of the organization's business case development process — is it consistently applied, formally documented, and subject to independent review? Second, the auditor tests the reasonableness of the specific assumptions and projections within each business case: are benefit estimates grounded in evidence? are cost estimates complete? are timelines realistic? Third, the auditor tracks ROI outcomes across multiple projects over time. When an enterprise consistently fails to meet its projected ROI, the pattern signals a systemic weakness in the system development approach and project management discipline — a process-level finding that transcends any individual project. IS auditors should escalate repeated ROI misses to the appropriate governance body.

A systems development methodology is the structured framework an organization uses to plan and control how information systems are designed, built, tested, and deployed. Methodologies emerged because IT systems are complex and the costs of uncontrolled development — defects discovered in production, cost overruns, and failed deployments — are far higher than the cost of discipline during development. A methodology defines the phases of development, assigns responsibilities for each phase's deliverables, establishes quality checkpoints between phases, and provides consistent, repeatable practices across projects. Different methodologies — traditional waterfall, V-model, iterative, Agile — suit different contexts. IS auditors assess whether an organization has adopted a methodology appropriate to its project types, whether it is consistently applied, and whether it includes the controls necessary to detect problems before they reach production.

Business application development spans systems built to support internal operations and those built to serve external customers. Organization-centric applications focus on collecting, processing, and presenting data to help internal users perform business functions — examples include internal workflow tools, reporting systems, and core banking transaction engines. Customer-centric applications are built around direct external user interaction — customers transact, query, or manage their accounts through these systems. Both types share a common life cycle: each phase of development is an incremental step that establishes the foundation for the next, covering design, build, testing, deployment, maintenance, and eventual retirement. Business application development is triggered by problems in existing processes, new regulatory requirements, or the availability of technology that enables superior outcomes. IS auditors assess the control framework against the application type, recognizing that customer-facing systems carry higher external risk.

Several SDLC models provide different structures for organizing system development. The traditional waterfall model sequences development phases linearly — requirements, design, build, test, deploy — with each phase completed before advancing to the next. It suits projects with stable, well-defined requirements unlikely to change during development, because rework is expensive when discovered late. The V-shaped model is a waterfall variant that pairs each development phase with a corresponding test phase planned from the start, improving defect detection and reducing late-stage surprises. The iterative model executes development in repeated cycles, each producing a working increment that stakeholders review. Feedback from each iteration refines the next, making this model suitable for projects with evolving or uncertain requirements. IS auditors assess whether the chosen model creates adequate control points, documentation gates, and traceability between requirements and tested deliverables.

The traditional SDLC organizes system development into six sequential phases, each with defined activities, responsibilities, and outputs that serve as inputs to the next phase. Phase 1, Feasibility Study, determines whether the project should proceed based on economic, technical, operational, and legal viability. Phase 2, Requirements, gathers and documents what the system must do — the authoritative specification that all subsequent work traces back to. Phase 3, Design, translates requirements into technical architecture, database schemas, user interface specifications, and processing logic — the blueprint the development team will build from. Phase 4, Development, implements the design through programming and unit testing. Phase 5, Testing, verifies system functionality, integration, and compliance with requirements. Phase 6, Implementation, deploys the tested system to production following change control procedures. IS auditors use this phase structure to identify which controls should exist at each stage and to detect when phases were combined, skipped, or inadequately executed.

An IS auditor participates in SDLC projects by analyzing the risks inherent in each development phase and verifying that cost-effective controls are in place to mitigate those risks. The auditor obtains and reviews documentation at each phase gate — requirements, design specifications, test plans, implementation procedures — to confirm that controls are functioning. A critical limitation governs this participation: the IS auditor must not design or recommend the controls being reviewed, because doing so creates a self-review threat. If an auditor consults with the project team during development, they cannot independently audit the completed system, because they would be evaluating their own recommendations. Additionally, IS auditors should avoid recommending controls whose administration cost exceeds the value of the risk they address — cost-effectiveness is a core audit principle. Maintaining independence throughout the SDLC engagement is not optional; it is a professional and ethical requirement.

Software development methods describe the technical approach used to design and build software systems, distinct from how the project team organizes its work. Object-oriented development structures software as classes and objects that encapsulate data and behavior — promoting reuse, modularity, and easier maintenance. Component-based development assembles applications from pre-built, independently deployable components, accelerating delivery and ensuring consistency across systems. Agile development is an iterative, incremental approach that delivers working software in short cycles and adapts to changing requirements through continuous collaboration. A critical distinction: the selection of a software development method is generally independent of the project organizational model. An Agile project may use object-oriented, component-based, or procedural coding approaches. IS auditors assess whether the chosen development method is appropriate for the application's complexity, maintainability requirements, and team capabilities.

System development tools and productivity aids reduce the manual effort required to build, document, and test software. CASE (Computer-Aided Software Engineering) applications assist developers in collecting, organizing, and visualizing application, system, and program-level data — including requirements models, data flow diagrams, and entity-relationship diagrams. Code generators take structured specifications or models and automatically produce source code, reducing programming time and variability. Fourth-generation languages (4GLs) allow users to interact with systems using near-natural-language syntax, making database querying and report generation accessible to non-programmers. Each tool category introduces distinct audit risks. Generated code may contain errors that developers assume are correct and do not review. 4GLs can expose sensitive data if access to the query environment is not tightly controlled by role. IS auditors assess whether these tools are covered by access control policies, version management, and output quality review processes.

IT infrastructure acquisition decisions have consequences far beyond initial purchase price. They determine operational procedures, training requirements, installation complexity, and total cost of ownership for the life of the asset. Because enterprise requirements conflict — high availability, zero data loss, legacy hardware compatibility, services-based architecture, and location-independent secure access cannot all be optimized on a single platform simultaneously — a formal, reasoned selection process is required. The selection must evaluate alignment with enterprise standards, appropriate security and privacy controls, integration with existing systems, relevance to industry trends, operational flexibility for future business needs, capacity for projected growth, security architecture for information and storage, day-to-day cost-effectiveness, hardware and software standardization, and overall ROI, cost transparency, and operational efficiency. An IS auditor reviews whether this multi-criteria analysis was documented and approved before a procurement decision was made.

Hardware and software acquisition should follow a structured procurement process that protects the organization from bias, overpricing, and technical mismatch. The process begins with defining detailed specifications that describe the usage, tasks, and technical requirements the equipment or software must fulfill. These specifications are distributed to potential vendors through a formal solicitation: a Request for Proposal (RFP) or Invitation to Tender (ITT). Vendors respond with proposals that are evaluated against pre-defined, weighted criteria covering technical capability, cost, vendor stability, and support quality. A selection committee reviews the scored proposals and documents its decision rationale. IS auditors verify that this process was followed — that requirements were formally defined, that competition was solicited, that selection was criterion-based and documented, and that the chosen vendor was evaluated independently without conflicts of interest.

System software acquisition requires a structured decision process covering both business and technical dimensions. IT management must be aware of hardware and software capabilities that can improve business processes, and must maintain plans for migrating to newer, more effective systems over time. When selecting new system software, the feasibility study must address: business, functional, and technical needs; cost and benefits; obsolescence risk; compatibility with existing systems; security; demands on current staff; training and hiring requirements; future growth needs; performance impacts; and whether open-source or proprietary code is appropriate. Four acquisition cases exist: buying off-the-shelf software that requires no customization; buying vendor software and customizing it; contracting a vendor to develop software to specification; and subscribing to a cloud-based SaaS offering. SaaS is generally suitable for generic processes. Regardless of case, the feasibility study must document the rationale. SaaS is a form of outsourcing — the same outsourcing governance principles apply, including right-to-audit clauses, service delivery monitoring, and contractual data protection requirements. An IS auditor confirms this documentation exists and covers all required dimensions.

Control identification and design for business applications focuses on three sequential control points through which data flows: input, processing, and output. Input controls are the first line of defense, ensuring that only authorized, complete, accurate, and valid data enters the system. They include edit tests that check field format and range, completeness checks that flag missing required fields, and authorization checks that verify the source of input. Processing controls govern how the system transforms input data into results, using mechanisms like batch totals, run-to-run reconciliation, and exception reports to detect errors introduced during computation. Output controls ensure that the results delivered to users are correctly formatted, complete, and securely delivered. IS auditors verify the existence and operation of controls at all three points by examining reports, transaction logs, exception records, and audit trails — the physical evidence that controls are functioning as designed.

Application controls are automated and manual controls embedded within application systems to ensure the authorization, accuracy, and completeness of data throughout input, processing, and output. Edit tests validate individual data fields at entry — checking format, type, length, and permissible ranges, and rejecting records that fail validation. Batch totals provide a control mechanism for high-volume processing: a control total (record count, financial sum, or hash value) is computed on input data before processing and compared to the output total after processing; any discrepancy indicates a problem requiring investigation before the batch can proceed. Reconciliations compare control totals across related systems or time points to detect accumulated errors. Exception reporting flags records outside defined parameters for separate human review and disposition. Automated controls reduce reliance on manual review but must themselves be subject to change management — any change to an automated control is a significant audit event.

Output controls provide assurance that data delivered to users is presented accurately, distributed to authorized recipients, and handled securely throughout its lifecycle. Negotiable, sensitive, or critical forms — including blank checks, certificates, and regulated documents — must be logged in a form log, stored in a secured location, and regularly reconciled against on-hand inventory; discrepancies must be investigated immediately. Report balancing compares output report totals against control totals established during processing to verify accuracy before distribution. Distribution controls ensure outputs reach only intended, authorized recipients — tracked by name or identification code, often with signature confirmation. Retention controls define how long output records must be kept and in what format. Disposal controls require that sensitive outputs be destroyed securely — shredded or incinerated — rather than placed in general recycling. IS auditors verify all four mechanisms as part of output control testing.

Implementation testing is integral to ensuring that a system works as intended before it enters production. Three prerequisites must be in place before testing begins. First, a testing methodology appropriate to the system's type, complexity, and risk must be selected and documented. Second, test plans must be developed that are fully traceable to requirements — each test case must reference the requirement it validates, creating evidence that all requirements have been tested and that testing coverage is complete. Traceable to requirements means traceable to the requirements specification document produced in the SDLC requirements phase — not to general business intent. Third, all resources required to execute testing must be in place: competent test staff, representative test environments, controlled test data, and adequate tooling. Completed testing provides stakeholders with evidence-based confidence that the system operates as specified and that the benefits promised in the business case can be achieved. Without proper testing prerequisites, what passes for 'testing' is activity without assurance.

Software testing is classified by the scope of what is being verified. Unit testing is the most granular — it tests an individual program module in isolation, using test cases derived from the module's control structure to confirm it performs according to specification. Integration testing evaluates combinations of components — whether hardware and software interfaces, or module-to-module connections — work correctly when assembled together. System testing evaluates the complete, integrated system against its overall requirements to verify end-to-end functionality. User acceptance testing (UAT) is performed by business users to validate that the system meets their needs and that the organization is ready to operate it. Regression testing verifies that changes made to an existing system have not inadvertently broken previously functioning capabilities — this test type applies to every change, from minor bug fixes to major feature additions. IS auditors verify that all applicable test types were executed, documented, and signed off before implementation.

Software testing is structured around test plans that define scope, methodology, and quality standards before testing begins. A test plan identifies which portions of the system will be tested and establishes categories for the types of deficiencies that may surface: actual system defects (bugs), gaps in requirements or design specifications that make requirements untestable, and errors in the test cases themselves. For each defect found during testing, the tester assigns a severity level based on the impact on system operation and the business priority of the affected function. Severity levels guide the prioritization of fixes — critical defects must be resolved before implementation proceeds; lower-severity defects may be deferred with documented risk acceptance. IS auditors review test documentation to verify that severity criteria are objective and consistently applied, that all defect categories are being captured, and that critical-severity defects were resolved before production deployment.

Data integrity testing is a set of substantive tests that examines the accuracy, completeness, consistency, and authorization of data currently stored in a system. Accuracy testing verifies that stored values are correct relative to their source. Completeness testing checks that no required data fields or records are missing. Consistency testing verifies that related data across tables, files, or systems agrees — a key consistency test for relational databases is referential integrity, which confirms that every foreign key in a child table points to a valid primary key in a parent table. Authorization testing verifies that data was created or modified only by authorized users following approved processes. Data integrity tests are classified as substantive because they evaluate the data itself, not just the controls. When data integrity failures are found, IS auditors look upstream to identify which input or processing controls failed to prevent the problem.

Testing the effectiveness of application controls involves selecting methods appropriate to the control type and risk level. The test data method creates a set of controlled transactions — covering both valid inputs and boundary or invalid cases — and processes them through the application, verifying that the system accepts valid inputs and correctly rejects or handles invalid ones. Parallel simulation builds an independent replica of the application's processing logic, runs the same input data through both the application and the simulation, and compares outputs; discrepancies identify control failures. The Integrated Test Facility (ITF) creates a fictitious entity within the live production system and routes test transactions to it, enabling continuous testing in the real environment. ITF is the most powerful technique but carries production risk: test transactions must be reversed before financial reporting, or they will contaminate live financial totals. IS auditors choose the method based on the application environment, risk tolerance, and need for live-system validation.

System implementation begins only after the testing phase concludes successfully and formal sign-offs have been obtained. The IS auditor's implementation review covers four areas. First, pre-implementation sign-offs: the auditor verifies that all required approvals — from change management, business owners, security, and operations — were obtained and documented before deployment, not after. Second, scheduling and parameter review: the auditor reviews the production run schedule, system parameters, and configuration to confirm they match what was tested and approved. Third, documentation completeness: all user guides, technical specifications, and operating procedures must be complete, accurate, and available to operations staff at the time of deployment. Fourth, support structure readiness: help desk staff and operations personnel must be trained and prepared to support the system from day one. An IS auditor who discovers that any of these four elements was absent at go-live documents an implementation control failure.

Complex IT systems require three integrated management processes to maintain integrity and availability. Configuration management maintains a formal record of the attributes of every IT component — hardware, software, firmware, and network connectivity — and controls changes to those attributes through documented baselines and change authorizations. Change management governs the lifecycle of every proposed modification to IT components: formal request, risk assessment, approval by an appropriate authority (such as a change advisory board), tracked implementation, and post-change verification. Release management controls how tested and approved changes are packaged, deployed, and activated in the production environment — requiring that changes be validated in a non-production environment before live deployment. The three processes are interdependent: a change that bypasses configuration management leaves no record of what changed; a change that bypasses release management may introduce untested code into production. IS auditors assess all three processes as a unified IT change control framework.

Configuration management is the systematic practice of identifying, recording, and controlling the attributes of IT components throughout their lifecycle. Configuration items are the individual components under management — any hardware, software, firmware, or documentation element that must be controlled — each assigned a unique identifier and version record. Baselines are formally approved snapshots of system or component states at specific milestones, providing a stable reference for all subsequent changes and a baseline from which deviations can be detected. The change control group (CCG) or change advisory board is the governance body responsible for reviewing and approving all maintenance requests before work begins, ensuring changes are assessed for risk and properly authorized. The audit trail is a complete, tamper-evident record of all changes to each configuration item — who changed it, when, what was changed, and under what authority. Many regulatory frameworks, including SOX and PCI-DSS, now mandate configuration management systems because they provide the documented control and repeatability that compliance programs require.

System migration is the process of moving data from a source system to a replacement target system. Modern applications tend to be more comprehensive and integrated than the legacy systems they replace, and organizations increasingly rely on data warehouses and analytical models that require clean, well-structured data. Migration risk is high because source and target systems often differ in field formats, file and database structures, coding schemes, and hardware platforms. A migration requires careful extraction of source data, formal transformation to match target system specifications, and controlled loading into the new environment. Post-migration integrity validation is essential: it verifies that all records were transferred, that values were correctly transformed, and that referential integrity in the target database is intact. A rollback plan provides a documented, tested path back to the source system if migration validation reveals unacceptable data quality or if the go-live fails. IS auditors treat the absence of either the integrity validation or the rollback plan as a material migration control gap.

Data conversion — also known as data porting — is the formal process of transforming data from a source system's format into a format compatible with a target system. A conversion is required when source and target systems differ in any of three ways. Field format differences occur when the source and target use different data types or representations for the same value — for example, a number stored as text in the source that must be an integer in the target, or a binary-coded decimal amount that must become a floating-point value. Database structure differences arise when the target uses a fundamentally different data organization — moving from flat files or VSAM structures to relational database tables requires creating primary and foreign key relationships that did not exist in the source. Platform differences occur when source and target run on different hardware or operating systems, sometimes requiring byte-order translation or character encoding conversion. IS auditors verify that a data model mapping document covers all three difference types, that conversion logic was tested with representative data before migration, and that post-conversion validation confirms data accuracy and completeness.

Changeover refers to the technique used to transition users from a legacy system to its replacement. Four approaches exist, each offering different risk and cost profiles. Direct cutover — also called big bang — switches all users and functions to the new system simultaneously at a defined moment; it is the simplest and least costly approach but offers no fallback path if failures occur at go-live. Parallel running operates both the old and new systems simultaneously for a defined period, comparing outputs for consistency until confidence is sufficient to decommission the old system; it provides maximum safety but at high cost and operational complexity. Phased implementation deploys the new system incrementally — by module, geography, or user group — limiting the impact of any failure to the deployed segment. Pilot deployment activates the complete new system for a limited, representative group of real users, gathering operational experience before full rollout. IS auditors assess whether the selected changeover technique is appropriate for the system's criticality, the organization's risk tolerance, and the quality of testing completed.

After a system is implemented and stabilized, it enters a maintenance phase that lasts until retirement. All changes during this phase — whether routine enhancements or emergency corrections — must be governed by a formal change control process. The IS auditor evaluates whether a methodology exists for authorizing, prioritizing, and tracking change requests; whether emergency procedures are documented in operations manuals; whether the change control log captures all changes and their resolution; whether security access controls restrict modification of production source and executable modules; and whether emergency logon IDs are secured and their use monitored. When sampling the change log, the auditor verifies that each change has corresponding documentation, was implemented as documented, and was adequately tested. Emergency changes receive heightened scrutiny because they bypass normal approval steps — the auditor checks that retroactive authorization and documentation occurred. User satisfaction with change turnaround is in audit scope as a leading indicator of process fitness for purpose: if users routinely experience slow or costly changes, the change management process may lack adequate capacity or prioritization controls. Source and executable code integrity controls prevent unauthorized modifications from reaching production.

System software implementation involves more than simply installing or updating software. The process begins with identifying the features, configuration options, and security controls to apply — establishing a standard configuration baseline that will be deployed consistently across the enterprise. Next, the software must be tested in a non-production environment that replicates production conditions, verifying that it functions correctly and that security controls operate as intended without relying solely on the vendor's testing. The final and most critical step is certification and accreditation. Certification is the process by which an independent assessor performs a comprehensive security evaluation of the software configuration against the organization's defined security requirements, producing an evidence-based assessment of the system's security posture. Accreditation is the formal management decision — based on that certification evidence — to authorize the software for production operation, explicitly accepting any residual risk. IS auditors verify that both steps occurred before production deployment. A vendor's release notes or internal team testing do not substitute for organizational certification and accreditation.

Certification is a comprehensive assessment performed by an independent assessor against defined standards, policies, and security requirements. The assessor determines whether controls are correctly implemented, operating as intended, and producing the desired security outcomes. The certification results update the system security plan and provide the factual basis for the next step. Accreditation is the formal management decision — issued by a senior official — to authorize an IS to operate and to explicitly accept the risk to the enterprise's operations, assets, or individuals. Accreditation functions as a quality-control mechanism that drives managers and technical staff to implement the most effective controls given mission requirements and technical, operational, and cost/schedule constraints. The critical accountability principle: by signing the accreditation decision, the senior official accepts personal responsibility for the system's security and for any adverse consequences of a breach. Responsibility and accountability are core principles that characterize accreditation.

A postimplementation review (PIR) is a formal evaluation conducted after a system has been operating in production for a sufficient period — typically several weeks to several months — to generate meaningful operational data. The PIR is distinct from project closure: closure formally ends the project, documents whether project objectives were met, captures lessons learned, and releases resources. The PIR, by contrast, evaluates whether the implemented system is delivering its intended business benefits in actual operation, whether new control gaps have emerged in production that were not identified during development, and whether the organization's processes and staff are effectively using the system as designed. The PIR's findings directly inform future project governance — repeated PIR shortfalls indicate systemic weaknesses in the development and delivery process. IS auditors conducting PIRs must be independent of the original system development process; an auditor who participated in development cannot objectively evaluate the same system.

An IS auditor performing a postimplementation review must be independent of the system development process. This independence requirement is categorical: if an IS auditor consulted with or assisted the project team during development — advising on controls, reviewing designs, or making recommendations — that auditor cannot perform the PIR on the same system. The self-review threat created by evaluating one's own prior work eliminates the objectivity the review requires. The IS auditor's PIR differs in focus from the internal project team's self-assessment: the IS auditor concentrates on the control aspects of the SDLC and implementation rather than on functionality or user satisfaction. The auditor evaluates whether controls were appropriately designed at each development phase, whether they were implemented as designed, and whether they are operating effectively in the production environment. Evidence collected during the PIR — test results, configuration records, transaction logs, access control reports — forms the basis of the auditor's conclusions. All audit involvement in the development process must be documented, and those who were involved must be excluded from the PIR engagement team.