Systems Development Life Cycle (SDLC) Phases — Apply Systems Development Life Cycle (SDLC) Phases - CPA Isc

SECTION 1

Historical Context & Motivation

Before the 1960s, information systems were built in an ad hoc manner—programmers wrote code, managers requested features mid-stream, and the resulting software frequently failed to meet business requirements. The cost of these failures was enormous: over-budget projects, missed deadlines, and systems that did not align with internal control objectives or regulatory mandates. The Systems Development Life Cycle (SDLC) emerged as the disciplined, phase-based framework that organizations—and the auditors who evaluate them—rely upon to manage the inherent complexity of building and deploying technology. For CPA candidates sitting for the ISC section, understanding the SDLC is not optional; it is the lens through which you evaluate whether an organization's IT governance, change management, and system implementation controls are operating effectively.

1956 • Early Structured Methods

Herbert Benington presents the first staged model for software development at a Navy symposium, planting the conceptual seed for sequential project phases.

1970 • Waterfall Model Published

Winston Royce formally describes the 'waterfall' model in a seminal paper, establishing the sequential phase paradigm—requirements → design → coding → testing → deployment—that still underpins traditional SDLC frameworks.

1985 • Spiral & Risk-Driven Models

Barry Boehm introduces the spiral model, emphasizing iterative risk analysis and prototyping. This marks a shift toward recognizing that requirements can evolve during development.

2001 • Agile Manifesto

Seventeen software practitioners sign the Agile Manifesto, popularizing iterative and incremental approaches. Agile does not eliminate SDLC phases—it compresses and repeats them in shorter cycles (sprints).

2020s • DevOps & Continuous Delivery

Modern organizations embed SDLC controls within DevOps pipelines, automating testing and deployment while maintaining the control checkpoints auditors require under frameworks like SOC 2 and COSO.

The central question the SDLC addresses is deceptively simple: How does an organization move from a business need to a functioning, reliable, well-controlled information system? For CPAs, the follow-up question is equally critical: At which phases must management embed controls, and how should auditors test them? The sections that follow answer both questions in depth.

SECTION 2

Core Principles & Definitions

The SDLC is a structured methodology that divides the creation and maintenance of information systems into discrete, manageable phases. Each phase produces defined deliverables (documents, designs, tested code) that serve as inputs to the next phase and as evidence for auditors. Regardless of whether an organization follows a waterfall, iterative, or agile variant, several foundational principles remain constant.

Phase-Gate Discipline

Each phase concludes with a formal review or sign-off (a 'gate') before the project proceeds. These gates create control points where management authorizes resource commitments and auditors assess risk.

Stakeholder Involvement

Business users, IT staff, internal auditors, and management participate throughout the life cycle. Early engagement prevents costly rework and ensures the system meets operational and compliance requirements.

Documentation & Traceability

Requirements are documented and traced through design, testing, and deployment. Traceability matrices ensure every requirement is addressed, a concept directly analogous to the audit trail in financial reporting.

Separation of Duties

Developers who write code should not be the same individuals who test it or migrate it to production. This IT general control mirrors the segregation principle in accounting and is a frequent CPA exam topic.

Continuous Feedback & Improvement

Post-implementation reviews capture lessons learned and feed them into future projects. This principle ties into COSO's monitoring component and the ongoing evaluation of internal controls over financial reporting (ICFR).

✦

KEY TAKEAWAY

Think of the SDLC like a construction project for a high-rise building. You would never pour the foundation before the architects finalize blueprints, and you would never let tenants move in before the fire inspector certifies safety. Each SDLC phase is analogous to a construction milestone—planning, design, building, inspection, and occupancy—where skipping a step or blurring responsibilities can lead to structural (or financial reporting) failures.

SECTION 3

Visual Explanation — The SDLC Phases

The diagram above illustrates the seven traditional SDLC phases in sequential order (top row, then second row), along with key deliverables produced at selected phases. In a waterfall approach, each phase completes before the next begins; in agile or iterative models, phases 2–5 repeat within shorter cycles.

Notice how the diagram positions each phase as a discrete box with a connecting arrow—this reflects the phase-gate discipline discussed in Section 2. The deliverables listed beneath the flow are not mere paperwork; they constitute the audit evidence an IS auditor or CPA will examine when evaluating IT general controls. A missing feasibility study or an unsigned user acceptance testing (UAT) form signals a control deficiency that could affect the reliability of financial data processed by the system.

SECTION 4

How Each Phase Works — Deep Dive

Phase 1 — Planning (Initiation & Feasibility)

Planning is the strategic starting point. Management identifies a business need—perhaps a new revenue recognition module required by ASC 606 or a system upgrade mandated by regulatory change. A feasibility study evaluates technical, economic, legal, operational, and scheduling feasibility (often remembered by the acronym TELOS). A cost-benefit analysis is conducted, often using net present value (NPV) or return on investment (ROI) calculations familiar to finance professionals. The phase culminates in a project charter and formal management authorization to proceed.

Phase 2 — Analysis (Requirements Definition)

During analysis, the project team gathers, documents, and validates business requirements and system requirements. Business requirements describe what the system must accomplish (e.g., 'generate aging schedules for accounts receivable'), while system requirements specify how it accomplishes the task (e.g., 'query the AR sub-ledger nightly and output a report sorted by 30/60/90-day buckets'). Techniques include interviews, surveys, observation, joint application development (JAD) sessions, and the creation of data flow diagrams (DFDs) and entity-relationship diagrams (ERDs). From a CPA perspective, this phase is critical because incomplete or inaccurate requirements often lead to systems that fail to enforce proper application controls—input validation, processing controls, and output controls.

Phase 3 — Design

The design phase translates requirements into a technical blueprint. Logical design specifies what the system will do without tying it to specific technology, while physical design details hardware platforms, database management systems, programming languages, and network architecture. Security controls—access control lists, encryption methods, and segregation of duties within the application—are specified here. Auditors pay close attention to design documentation because control weaknesses introduced at this stage propagate through the entire system.

Phase 4 — Development (Coding & Acquisition)

During development, programmers write, compile, and unit-test code based on the design specifications. Alternatively, if the organization is acquiring commercial off-the-shelf (COTS) software, this phase involves vendor selection, contract negotiation, and package configuration. Version control systems track every code change, and code reviews enforce quality and security standards. A key CPA concern is ensuring that development is performed in a separate environment from production to prevent unauthorized or untested changes from affecting live financial data.

Phase 5 — Testing

Testing validates that the system works correctly and meets requirements. Common testing levels include unit testing (individual modules), integration testing (combined modules), system testing (end-to-end), and user acceptance testing (UAT). UAT is particularly important because business users—not IT developers—confirm that the system meets their operational needs. Auditors look for documented test plans, test results, and formal sign-off by business owners before the system goes live.

Phase 6 — Implementation (Deployment & Conversion)

Implementation moves the tested system into the production environment. Four common conversion strategies exist: direct (cold turkey), where the old system is shut off and the new one goes live immediately; parallel, where both systems run simultaneously until confidence in the new system is established; phased (modular), where the new system is rolled out module by module; and pilot, where a single location or business unit goes live first. Data migration—converting legacy data to the new system format—must be carefully controlled and reconciled, a process that directly impacts the accuracy of financial records.

Phase 7 — Maintenance & Disposal

After go-live, the system enters the longest phase: maintenance. Bug fixes, patches, enhancements, and regulatory updates occur on an ongoing basis. Change management controls ensure that every modification follows the same disciplined process—request, approval, development, testing, and migration—that governed the original build. Eventually, the system reaches end of life and must be retired (disposal), with data archived or migrated in compliance with retention policies and regulatory requirements.

SECTION 5

Detailed Breakdown — Conversion Strategies & Controls

The choice of conversion strategy during the implementation phase is a frequent CPA exam topic because it directly affects the risk profile of the go-live event. Each strategy involves a different trade-off between cost, risk, and speed. Understanding these trade-offs is essential for evaluating whether management has selected an appropriate implementation approach given the system's impact on financial reporting.

This diagram contrasts the four conversion strategies by risk level, cost, and deployment pattern. The bottom panel summarizes the auditor's perspective on each strategy—a common CPA exam angle.

Strategy	Risk Level	Cost	Best Used When
Direct	High — no fallback system	Low — runs one system	Non-critical systems or when the old system is already failing
Parallel	Low — old system available	High — dual operations	Mission-critical financial systems; general ledger or ERP conversions
Phased	Medium — module-by-module	Medium	Large, modular systems where full parallel is too expensive
Pilot	Medium — limited initial exposure	Medium	Multi-location organizations; test at one branch before enterprise rollout

Summary of SDLC Conversion Strategies

SECTION 6

Worked Example — Evaluating SDLC Controls at a Public Company

Consider the following scenario: GlobalTech Inc., a publicly traded manufacturing firm, is implementing a new ERP system to replace its legacy accounting software. As the IS auditor engaged under SOX Section 404, you must evaluate whether management has applied adequate SDLC controls. Walk through the evaluation phase by phase.

IS Audit Evaluation of GlobalTech's ERP Implementation

1
Step 1 — Evaluate the Planning Phase

You request and examine the project charter, feasibility study, and cost-benefit analysis. The feasibility study addresses all five TELOS dimensions and concludes the project has a positive NPV of $2.4 million over five years. The project charter was signed by the CFO and CIO.

Finding: Planning phase controls are adequate — formal authorization and economic justification documented.
2
Step 2 — Evaluate the Analysis Phase

You review the requirements documentation and note that 47 business requirements were gathered via JAD sessions with representatives from accounting, operations, and IT. Each requirement has a unique identifier and an assigned owner. However, you notice that the internal audit department was not consulted regarding control requirements.

Finding: Minor deficiency — internal audit should have been a stakeholder to ensure ICFR requirements were captured upfront.
3
Step 3 — Evaluate the Design & Development Phases

The system architecture document specifies role-based access controls, encrypted database connections, and segregation of duties between the AP and GL modules. Development occurred in a sandboxed environment, and version control logs show all code changes were reviewed by a senior developer who did not write the original code.

Finding: Design and development controls are strong — separation of environments and code review controls are operating effectively.
4
Step 4 — Evaluate the Testing Phase

You examine the test plan, which includes unit, integration, system, and UAT test scripts. The UAT was performed by accounting department personnel using realistic test data (not production data, to protect confidentiality). All 47 requirements are traced to at least one test case in a requirements traceability matrix. The UAT sign-off form is signed by the Controller.

Finding: Testing phase controls are exemplary — full traceability and formal business-owner sign-off.
5
Step 5 — Evaluate the Implementation Phase

Management chose a parallel conversion strategy, running both the legacy system and the new ERP simultaneously for 60 days. Output reconciliations were performed daily, with discrepancies investigated and resolved within 24 hours. Data migration was validated by comparing record counts and control totals between old and new systems.

Finding: Implementation controls are strong — parallel conversion with daily reconciliations is the gold standard for financial systems.
6
Step 6 — Summarize Overall Assessment

Across all phases, only one minor deficiency was identified (failure to include internal audit in requirements gathering). This does not rise to the level of a material weakness or significant deficiency but should be communicated to management as an opportunity for improvement in future SDLC projects.

Overall conclusion: SDLC controls are suitably designed and operating effectively. One management letter comment recommended.

SECTION 7

Strengths & Limitations — SDLC Models

While the traditional waterfall SDLC remains the model most frequently tested on the CPA exam, modern organizations often employ alternative methodologies. Each model applies the same fundamental phases but varies in how those phases are sequenced, repeated, and controlled. Understanding the strengths and limitations of each model helps auditors assess whether the chosen approach is appropriate for the project's risk profile.

Model	Strengths	Limitations	Audit Implications
Waterfall	Clear documentation; well-defined deliverables at each gate; easiest to audit	Inflexible to changing requirements; late discovery of defects; long time-to-market	Traditional audit approach works well; phase-gate evidence is readily available
Agile	Rapid iteration; early user feedback; adapts to changing requirements	Less formal documentation; scope creep risk; harder to define fixed budgets	Auditors must look for sprint-level controls: sprint backlogs, retrospectives, and incremental testing evidence
Spiral	Risk-driven; prototyping reduces unknowns; suitable for large, complex systems	Complex to manage; requires sophisticated risk analysis; potentially costly	Auditors evaluate risk assessments at each iteration and whether prototyping findings are incorporated
DevOps / CI-CD	Continuous integration and deployment; automated testing; fast release cycles	Requires mature tooling; blurs development and operations; cultural shift needed	Auditors evaluate automated pipeline controls: code scanning, automated test gates, deployment approvals in the tool chain

Comparison of SDLC Methodologies from an Auditor's Perspective

✦

KEY TAKEAWAY

The methodology label matters less than the substance of the controls. Whether an organization uses waterfall, agile, or DevOps, the auditor's question is always the same: Are requirements defined, is design reviewed, is code tested, is migration controlled, and is there formal authorization at each critical juncture? Think of it like an audit of revenue recognition—the accounting standard (ASC 606) is the same regardless of whether the client is a SaaS company or a manufacturer; only the application of the standard differs.

SECTION 8

Connection to Advanced Theory — IT Governance & COSO Integration

The SDLC does not exist in isolation; it operates within the broader IT governance framework an organization establishes. For CPA candidates, the most important connection is between SDLC controls and the COSO Internal Control–Integrated Framework and COBIT (Control Objectives for Information and Related Technologies). Understanding how SDLC maps to these frameworks elevates your analysis from a technical checklist to a risk-based governance assessment.

SDLC Phase	COSO Component	COBIT Domain	IT General Control Category
Planning	Risk Assessment; Control Environment	Align, Plan & Organize (APO)	Program Development
Analysis & Design	Control Activities; Information & Communication	Build, Acquire & Implement (BAI)	Program Development
Development & Testing	Control Activities	Build, Acquire & Implement (BAI)	Program Development; Access to Programs & Data
Implementation	Control Activities; Monitoring	Build, Acquire & Implement (BAI)	Program Changes; Computer Operations
Maintenance & Disposal	Monitoring Activities	Deliver, Service & Support (DSS)	Program Changes; Computer Operations

Mapping SDLC Phases to COSO, COBIT, and IT General Control Categories

Looking ahead, the CPA exam increasingly tests your ability to evaluate not just whether SDLC phases were followed, but whether they were integrated with enterprise risk management (ERM) and data governance. As organizations adopt cloud computing, artificial intelligence, and blockchain-based systems, the SDLC framework must accommodate new risks—such as algorithmic bias, third-party cloud provider controls, and the immutability challenges of distributed ledgers. The fundamental SDLC principles of phase-gate discipline, documentation, and separation of duties remain constant, but their implementation evolves with technology.

SECTION 9

Practice Problems

Question 1: CONCEPTUAL

A CPA is evaluating the IT general controls of a publicly traded company. During the review of a recent system implementation, the auditor discovers that the requirements traceability matrix was never completed. Which SDLC phase was most likely deficient, and why does this matter for the audit of internal controls over financial reporting (ICFR)?

Show answer

The deficiency most likely occurred during the Analysis (requirements definition) phase, where requirements are documented and tracked, and carried forward into the Testing phase, where the traceability matrix ensures every requirement has a corresponding test case. Without the traceability matrix, the auditor cannot obtain evidence that all business requirements—including those related to financial processing controls—were actually tested and validated before the system went live. This gap undermines the auditor's ability to rely on the system's application controls (input validation, processing accuracy, output completeness) and may constitute a control deficiency that must be communicated to management and those charged with governance.

Question 2: BASIC CALCULATION

A company is deciding between building a custom system and purchasing commercial off-the-shelf (COTS) software. The custom build has an estimated cost of $1,200,000 over two years with annual maintenance of $150,000. The COTS solution costs $600,000 in licensing fees with $200,000 in annual customization and maintenance. Using a simple 5-year total cost of ownership (TCO) analysis (no discounting), which option is less expensive?

Show answer

For the custom build, the TCO over 5 years equals $1,200,000 (development) + $150,000 × 5 (maintenance) = $1,200,000 + $750,000 = $1,950,000. For the COTS solution, the TCO equals $600,000 (licensing) + $200,000 × 5 (customization and maintenance) = $600,000 + $1,000,000 = $1,600,000. The COTS solution is $350,000 less expensive on a simple TCO basis. However, the auditor should also consider qualitative factors evaluated during the Planning phase's feasibility study, such as vendor stability, customization limitations, and the degree of control the organization retains over the source code.

Question 3: INTERMEDIATE

During an IS audit, you learn that a company deployed a new accounts payable module using a direct (cold turkey) conversion strategy. Two weeks after go-live, the CFO reports that duplicate payments totaling $430,000 were made because a data migration script double-loaded vendor invoices. As the auditor, identify: (a) what SDLC control failures likely contributed to this outcome, and (b) which conversion strategy would have mitigated the risk.

Show answer

(a) Multiple SDLC control failures likely contributed. First, the Testing phase was deficient—data migration testing should have included reconciliation of invoice counts and dollar totals between the legacy system and the new module. A properly designed test plan would have caught the duplicate load before go-live. Second, the Implementation phase lacked adequate data migration controls; specifically, control totals (record counts and hash totals of invoice amounts) should have been compared before and after migration. Third, the absence of a post-implementation reconciliation in the first days of operation suggests inadequate monitoring controls. (b) A parallel conversion strategy would have mitigated this risk because the legacy AP system would have continued processing payments concurrently. Management could have compared outputs from both systems daily, detecting the $430,000 discrepancy before actual duplicate payments were disbursed.

Question 4: APPLIED

You are the IS auditor for a financial services firm that recently adopted an Agile development methodology for its new loan origination system. The development team argues that formal phase-gate documentation is unnecessary because Agile emphasizes 'working software over comprehensive documentation.' Prepare a response that addresses: (a) how SDLC controls can be maintained within an Agile framework, and (b) what specific evidence you would request to satisfy audit requirements.

Show answer

(a) Agile does not eliminate the need for controls—it embeds them within shorter, iterative cycles called sprints. Each sprint effectively compresses the analysis, design, development, and testing phases into a two-to-four-week cycle. The Agile Manifesto values working software over comprehensive documentation, but this does not mean zero documentation; it means documentation should be sufficient and purposeful rather than ceremonial. Control objectives—such as requirements traceability, code review, testing validation, and authorized deployment—must still be met. (b) Specific evidence the auditor should request includes: sprint backlog items mapped to business requirements (serving as the requirements traceability matrix); code review records or pull request approvals in the version control system; automated and manual test results for each sprint, including regression testing; sprint retrospective documentation showing defects identified and remediated; and deployment approvals showing that a designated individual (not the developer) authorized the release to production. These artifacts collectively demonstrate that the substance of SDLC controls is maintained even though the form differs from a waterfall model.

Question 5: CRITICAL THINKING

A multinational corporation is implementing a new cloud-based ERP system across 15 countries over 18 months. The project steering committee is debating between a phased conversion (one country at a time) and a pilot approach (deploy in one country, learn, then roll out to all remaining countries simultaneously). Analyze the risks, benefits, and audit implications of each approach, and recommend which strategy is more appropriate given the complexity and scale of the project. Consider data sovereignty regulations, local accounting requirements, and the auditor's ability to test controls.

Show answer

The phased approach—deploying one country at a time—offers several advantages for this scenario. Each rollout serves as both a deployment and a learning opportunity, allowing the team to adjust configurations for local accounting standards (e.g., IFRS vs. local GAAP), tax regulations, and data sovereignty requirements (such as the EU's GDPR or China's PIPL) before moving to the next jurisdiction. From an audit perspective, the phased approach produces a clear evidence trail for each country-level implementation, and auditors can test controls at each site independently. However, the 18-month timeline creates integration risk: as later countries go live, earlier implementations may require patches or upgrades, creating version inconsistencies. The pilot approach—deploying fully in one country, then rolling out to all 14 simultaneously—is faster but significantly riskier at scale. If the pilot country is not representative of all jurisdictions (e.g., it has simpler tax rules), lessons learned may not transfer, and the simultaneous rollout to 14 countries multiplies the impact of any undetected defect. Auditors face the challenge of testing controls across 14 concurrent implementations, which strains audit resources and increases the risk of undetected control failures. The recommended strategy is a hybrid: use a phased approach grouped by regulatory similarity (e.g., EU countries together, Asia-Pacific together), with the first group serving as a pilot. This balances speed with risk mitigation, respects data sovereignty boundaries, and gives auditors manageable clusters of implementations to evaluate. The steering committee should also ensure that each phase includes a post-implementation review whose findings feed into the next phase's planning—embodying the SDLC principle of continuous feedback.

SUMMARY

Lesson Summary

Summary

The Systems Development Life Cycle (SDLC) is a structured methodology that guides the creation, deployment, and retirement of information systems through seven core phases: Planning, Analysis, Design, Development, Testing, Implementation, and Maintenance & Disposal. Each phase produces specific deliverables that serve as both project management artifacts and audit evidence. The five core principles—phase-gate discipline, stakeholder involvement, documentation and traceability, separation of duties, and continuous feedback—apply regardless of whether the organization follows a waterfall, agile, spiral, or DevOps methodology.

For CPA candidates, the critical skill is evaluating SDLC controls from an auditor's perspective. This means assessing whether feasibility studies justify the project, requirements traceability matrices ensure completeness, UAT sign-offs confirm business validation, and conversion strategies (direct, parallel, phased, pilot) are appropriate for the system's risk profile. The SDLC maps directly to COSO and COBIT frameworks, reinforcing that IT controls are an integral component of internal controls over financial reporting.