3.2 System Development Life Cycle (SDLC) & Implementation

System Development Life Cycle (SDLC) & Implementation

When an organization purchases, develops, or substantially configures an enterprise application—such as transitioning to a new Enterprise Resource Planning (ERP) platform—the implementation process introduces severe risks to internal control over financial reporting (ICFR). Historical corporate history is replete with failed system implementations that resulted in inventory write-downs, invoicing breakdowns, and catastrophic control failures. To manage these risks, organizations follow a formal System Development Life Cycle (SDLC).

For the CPA and IT auditor, the SDLC is evaluated from two distinct perspectives:

1. Evaluating Ongoing Controls: Verifying that the organization maintains robust SDLC controls so that all ongoing system modifications comply with ITGC standards.
2. Auditing Material Implementations: Conducting specific audit procedures over major new systems implemented during the period under audit to ensure that data migration was accurate, controls were properly configured, and business logic was thoroughly tested prior to production go-live.

---

The Seven Phases of the SDLC

While specific development frameworks use differing terminology, the classic SDLC comprises seven distinct phases:

The 7 SDLC Phases
1. Planning & Feasibility ────► Steering Committee Charter & Economic Analysis
2. Requirements Analysis  ────► Functional, Non-Functional & ICFR Specifications
3. System Design          ────► Architecture, Database Schemas & Control Logic
4. Development & Config   ────► Coding, Parameter Setup & Unit Testing
5. Testing & Validation   ────► SIT, Regression, UAT & Sign-Off
6. Implementation/Cutover ────► Data Migration, User Training & Cutover
7. Operations/Maintenance ────► Post-Implementation Review & Ongoing Patches

1. Planning and Feasibility

Management evaluates the strategic necessity, resource requirements, and technical viability of the project. A multidisciplinary IT Steering Committee (including executive leadership, IT leadership, and the Chief Financial Officer) assesses feasibility across three dimensions:

• Economic Feasibility: Cost-benefit analysis, capital allocation, and projected return on investment (ROI).
• Technical Feasibility: Compatibility with existing hardware, network infrastructure, and cloud integration capabilities.
• Operational Feasibility: Organizational readiness, operational impact, and regulatory compliance constraints.

2. Requirements Analysis

System analysts and business users define what the application must do. Requirements are categorized into:

• Functional Requirements: The business rules, transaction processing routines, calculation algorithms (e.g., ASC 606 revenue recognition criteria, tax calculations), and automated approval workflows.
• Non-Functional Requirements: System availability, transaction throughput, response latency, encryption standards, and disaster recovery recovery-time objectives.
• Internal Control Scoping: Defining mandatory internal controls upfront—such as audit logging, field edit checks, and automated segregation of duties (SoD) constraints.

3. System Design

Technical architects design the technical blueprints for the application. This includes creating data models, Entity-Relationship (ER) diagrams, interface specifications for application programming interfaces (APIs), user interface mockups, and database table schemas. System security controls—such as role-based access matrices and field-level encryption—must be integrated directly into the system design architecture.

4. Development and Configuration

Developers write custom software code, or systems integrators configure parameter tables in Commercial Off-The-Shelf (COTS) ERP software (such as SAP S/4HANA, Oracle Cloud ERP, or Microsoft Dynamics 365). Development must occur strictly within isolated development environments. Developers perform preliminary unit tests to verify that individual components function correctly in isolation.

5. Testing and Quality Assurance

Before deployment, the system must undergo rigorous, tiered testing:

• Unit Testing: Executed by software developers to validate individual functions, procedures, or modules.
• System Integration Testing (SIT): Validates data flows across interfaces, APIs, and connected systems (e.g., verifying that data passed from an e-commerce platform successfully creates an invoice in the general ledger).
• Regression Testing: Verifies that new code or configurations do not break existing functionality or corrupt previously tested features.
• User Acceptance Testing (UAT): Operational business users test end-to-end business cycles using realistic transaction scenarios. Formal, dated sign-off from business process owners is required prior to release.
• Performance and Stress Testing: Evaluates system behavior under peak transaction volumes.

6. Implementation and Cutover

The transition from legacy software to the production system. Key activities include data migration (extracting, transforming, and loading legacy master and transactional data), user training, and activating the cutover strategy.

7. Operations and Maintenance

Ongoing operational support, routine patching, user administration, and defect resolution. A critical governance control in this phase is the Post-Implementation Review (PIR), conducted 3 to 6 months post-deployment to assess whether the system achieved its intended business objectives and whether internal controls are functioning as intended.

---

Waterfall vs. Agile and DevOps Methodologies

Traditional auditing approaches were developed around linear development methodologies, but modern organizations increasingly utilize iterative frameworks:

---

User Acceptance Testing (UAT) Controls & Governance

User Acceptance Testing (UAT) is the ultimate defense against deploying flawed software into production. For financial systems, UAT is not an IT function—it is a business control executed by functional users (e.g., Senior Accountants, Accounts Payable Supervisors, Billing Managers).

Key controls evaluated by auditors during UAT include:

• Environment Isolation: UAT must be executed in a dedicated staging environment that mirrors production architecture, hardware, and configuration, but is strictly isolated from production data stores.
• Test Data Masking & Sanitization: Using full copies of production data in UAT creates massive data privacy and security vulnerabilities (exposing real customer credit cards, employee SSNs, or executive salaries). Organizations must utilize data masking, anonymization, or synthetic test data generation.
• Comprehensive Test Script Design: Test scripts must not only test the "happy path" (valid transactions that should process smoothly), but also execute "negative testing" (submitting invalid data, expired dates, out-of-balance debits and credits) to verify that programmed edit checks block erroneous data.
• Defect Tracking & Severity Thresholds: Identified defects must be logged in a tracking system (e.g., Jira). Controls must establish clear gating criteria: zero open Severity 1 (critical/blocker) or Severity 2 (high) defects are permitted at go-live.
• Formal Business Sign-Off: The controller or relevant business unit executive must sign and date a formal acceptance document certifying that the system meets all business and internal control requirements.

---

System Cutover Strategies: Comparison & Audit Risks

Selecting a cutover strategy balances operational disruption against financial and control risk:

---

Data Migration Validation Controls

Data migration is the process of transferring master data (chart of accounts, vendor master files, customer records) and transactional balances (open purchase orders, unpaid customer invoices, general ledger balances) from legacy systems into the new application. Errors during migration directly corrupt the financial statements.

Auditors evaluate the ETL (Extract, Transform, Load) control framework:

Data Migration Validation Architecture
Legacy System                   Intermediate / Staging                 New ERP System
┌───────────────┐               ┌────────────────────┐               ┌───────────────┐
│ Legacy Master │ ──Extract───► │ Data Cleansing     │ ───Load─────► │ Production    │
│ & Transactions│               │ & Transformation   │               │ Database      │
└───────┬───────┘               └─────────┬──────────┘               └───────┬───────┘
        │                                 │                                  │
        ▼                                 ▼                                  ▼
   Source Totals                  Mapping Rules Validation             Target Totals
        └───────────────────────────────► Reconcile ◄────────────────────────┘
                                          ├─ Record Counts
                                          ├─ Financial Control Totals
                                          └─ Non-Financial Hash Totals

Key data migration controls include:

• Pre-Migration Data Cleansing: Deactivating obsolete accounts, removing duplicate vendor profiles, and archiving closed transactions prior to extraction.
• Automated Reconciliation Controls:
  • Record Counts: Verifying that 100% of extracted records arrived in the target database (e.g., 50,000 active customer records extracted = 50,000 loaded).
  • Financial Control Totals: Summing financial fields (e.g., total accounts receivable subledger balance must equal exactly $14,289,450.12 in both legacy and new databases).
  • Hash Totals: Summing non-financial numerical fields (such as vendor bank routing numbers or customer IDs) to detect record truncation or field-mapping misalignment.
• Cutover Freeze Windows: Implementing a complete transactional data freeze during migration to ensure no new transactions enter the legacy system during cutover.
• Post-Implementation Review (PIR): A formal review conducted 3 to 6 months post-implementation to verify that business goals were met, operational metrics are stable, and no lingering internal control deficiencies remain.

---

Common CPA Exam Pitfalls & Traps

• Trap 1: Believing Parallel Cutover Eliminates Audit Risk. While parallel conversion minimizes business shutdown risk, it creates high audit risk around user fatigue. Clerks often enter data carefully in one system and carelessly in the other, leading to phantom variances.
• Trap 2: Confusing UAT with Developer Testing. Developer unit and integration testing validates that the software functions according to technical code specifications. UAT validates that the software satisfies business and internal control accounting requirements.
• Trap 3: Treating Data Migration as Administrative. Candidates often overlook data migration as an IT technical task. In financial audits, data migration is a high-risk event requiring mathematical reconciliation of beginning balances under AU-C 510.