Information Systems Acquisition, Development & Implementation

Major Categories of Business Application Systems

Application Architecture Approaches

• Monolithic: Single, self-contained application — simpler but harder to scale and update
• Client-Server: Logic split between client (UI) and server (data/business logic)
• N-Tier / Multi-Tier: Presentation, business logic, and data tiers separated
• Service-Oriented Architecture (SOA): Reusable services via standard interfaces (SOAP, REST)
• Microservices: Small, independently deployable services — cloud-native; used in DevOps
• Event-Driven Architecture: Components communicate via events/messages (Kafka, RabbitMQ)

Data Processing Methods

Database Management Systems (DBMS)

• Relational DBMS (RDBMS): Tables, SQL, ACID properties (Oracle, SQL Server, MySQL)
• NoSQL: Non-relational — document, key-value, graph, columnar (MongoDB, Cassandra)
• Data Warehouse: Centralized repository for analytical reporting (OLAP)
• Data Lake: Raw data storage in native format for big data analytics

SDLC Phases Overview

IS Auditor's Role in SDLC

The IS auditor can participate in the SDLC as:

• Reviewer/Observer: Reviewing deliverables and controls at key phases — most common and appropriate role
• Participant: Active involvement in design reviews — must be cautious of independence impairment
• Post-implementation auditor: Reviewing completed system

Requirements Types

• Functional Requirements: What the system must DO (business processes, calculations, workflows)
• Non-Functional Requirements: HOW the system must perform — performance, security, availability, scalability, maintainability
• Security Requirements: Authentication, authorization, encryption, audit logging
• Regulatory/Compliance Requirements: Must be captured during requirements phase

Feasibility Study Components

• Technical Feasibility: Can the technology deliver the solution?
• Economic Feasibility: Is the cost justified by benefits? (ROI, NPV)
• Operational Feasibility: Will the organization adopt and operate it?
• Legal/Regulatory Feasibility: Does it comply with applicable laws?
• Schedule Feasibility: Can it be delivered in the required timeframe?

Project Management Frameworks

• PMBOK (PMI): Knowledge-area based framework with 49 processes across 5 process groups
• PRINCE2: Process-based method with defined roles (Project Board, Project Manager, Teams)
• Agile/Scrum: Iterative, adaptive project management — see Section 4

PMBOK Process Groups

Project Governance Controls (IS Auditor Focus)

• Project Charter: Formally authorizes the project; defines objectives, scope, constraints
• Steering Committee: Executive oversight — approves scope changes, resolves issues
• Project Management Office (PMO): Standards, templates, portfolio oversight
• Change Control Board (CCB): Evaluates and approves scope/schedule/budget changes
• Risk Register: Documents project risks and mitigation plans
• Status Reporting: Regular reporting to stakeholders and governance bodies
• Phase Gate Reviews: Formal approval to proceed at end of each SDLC phase

Project Performance Metrics

Common IT Project Failure Causes

• Unclear or changing requirements (scope creep)
• Inadequate project governance and oversight
• Poor stakeholder engagement and communication
• Underestimated complexity and technical risk
• Inadequate testing and quality assurance
• Lack of experienced project management
• Insufficient change management (organizational resistance)

Waterfall (Traditional SDLC)

Sequential, phase-by-phase approach where each phase is completed before the next begins.

• Strengths: Predictable, well-documented, clear milestones, easy to audit
• Weaknesses: Inflexible to change; late delivery; high risk of delivering wrong thing
• Best for: Stable, well-understood requirements; regulatory systems

Agile Methodology

Iterative, incremental development with continuous stakeholder collaboration and adaptability to change. Governed by the Agile Manifesto (4 values, 12 principles).

Agile Values: Individuals & interactions over processes & tools | Working software over comprehensive documentation | Customer collaboration over contract negotiation | Responding to change over following a plan.

• Scrum: Most popular framework — Sprints (1-4 weeks), Product Backlog, Sprint Backlog, Sprint Review, Retrospective, Daily Standup; Roles: Product Owner, Scrum Master, Development Team
• Kanban: Visual workflow management; WIP (Work-in-Progress) limits; continuous flow
• SAFe (Scaled Agile Framework): Agile at enterprise scale with portfolio, program, team levels

Rapid Application Development (RAD)

Emphasizes rapid prototyping and iterative delivery over extensive planning. Relies heavily on user involvement and CASE tools. Risk: inadequate documentation and testing.

Spiral Model

Risk-driven model combining iterative development with systematic aspects of Waterfall. Each spiral loop: Planning → Risk Analysis → Engineering → Evaluation. Best for large, high-risk systems.

Comparison Table

Secure Software Development (SSDLC)

Security must be integrated throughout the SDLC, not added as an afterthought. Key practices:

• Threat Modeling: Identify threats early in design (STRIDE: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege)
• Secure Coding Standards: OWASP guidelines, input validation, parameterized queries
• Static Application Security Testing (SAST): Code analysis without execution
• Dynamic Application Security Testing (DAST): Testing running application
• Software Composition Analysis (SCA): Open-source/third-party component vulnerability scanning

Application Control Categories

Input Validation Controls (Exam Favorites)

• Field/Format Check: Ensures data is in the correct format (e.g., date as DD/MM/YYYY)
• Range Check: Value within acceptable min-max range (e.g., age 0-120)
• Limit Check: Single-sided upper or lower boundary
• Completeness Check: Required fields are not empty
• Validity/Table Lookup Check: Value matches a valid list (e.g., valid country codes)
• Reasonableness Check: Value is logically reasonable given other data
• Check Digit: Mathematical verification of a numeric code (e.g., ISBN, bank account)
• Duplicate Check: Detects duplicate transaction entries
• Sequence Check: Ensures transactions are in correct sequence

Batch Control Totals

Application Interface Controls

When data flows between systems (interfaces), controls must ensure completeness and accuracy:

• Reconciliation of records sent vs. received
• Error handling and exception reporting
• Timing controls (cut-off, sequencing)
• Authentication between systems (API keys, certificates)
• Data format and integrity validation

Audit Trail / Transaction Logging

Applications should maintain audit trails capturing: who did what, when, what changed (before/after values), from where. IS auditors verify audit logs are:

• Complete and tamper-proof
• Retained for appropriate periods
• Reviewed regularly
• Protected from unauthorized modification

Testing Types & Objectives

Test Approaches

• Black Box Testing: No knowledge of internals — tests functionality from user perspective; finds external behavior errors
• White Box Testing: Full knowledge of internal code — tests code paths, branches, logic (also: glass box, structural testing)
• Gray Box Testing: Partial knowledge of internals — combination approach

Test Coverage Techniques

• Equivalence Partitioning: Divides inputs into valid/invalid classes; tests one from each class
• Boundary Value Analysis: Tests at exact boundaries (min, min+1, max-1, max)
• Decision Table Testing: Tests all combinations of conditions and actions
• State Transition Testing: Tests system behavior across different states

IS Auditor's Review of Testing

Key questions the IS auditor asks:

• Were test plans formally developed and approved before testing began?
• Was UAT conducted by business users (not developers)?
• Were all defects logged and tracked to resolution?
• Were security controls specifically tested?
• Was regression testing performed after defect corrections?
• Was there formal sign-off on test completion before production deployment?

Defect Management

All defects must be: Logged with severity/priority → Assigned for resolution → Fixed → Re-tested → Formally closed. Outstanding defects should be formally accepted by business management before go-live.

Change Management Process

Change management controls ensure that only authorized, tested changes are made to production systems. The ITIL change management process:

1. Request for Change (RFC): Formal submission describing the proposed change
2. Change Assessment: Impact, risk, resource, and benefit analysis
3. Change Advisory Board (CAB): Reviews and approves/rejects changes
4. Change Scheduling: Planned for maintenance window to minimize disruption
5. Implementation: Executed by authorized personnel using documented procedures
6. Post-Implementation Review: Confirm change was successful; rollback if needed
7. Change Closure: Formal documentation of outcome

Change Types (ITIL)

Key SoD in Change Management

• Programmer who writes code should NOT migrate code to production
• Requestor of a change should NOT approve their own change
• Change implementer should NOT perform post-implementation testing

IS Auditor's Change Management Review

The IS auditor verifies:

• All changes are formally requested and documented (RFC)
• Changes are approved by appropriate authority before implementation
• Testing is completed and documented before production deployment
• Segregation of duties between development and production is maintained
• Emergency changes are documented after the fact and reviewed
• Unauthorized changes are detected through change log review
• Rollback/backout procedures exist and are tested

Release & Deployment Management

Release management controls the build, testing, and deployment of releases to the production environment. Key controls: release packages (bundled changes), release testing in staging environment, release calendar, back-out plans, and production deployment authorization.

Build vs. Buy Decision

COTS (Commercial Off-the-Shelf) Software Acquisition

When acquiring packaged software, the IS auditor reviews:

• RFP/RFI Process: Formal vendor selection with defined criteria
• Vendor Evaluation: Financial stability, security posture, support capabilities, references
• Contract Terms: SLAs, source code escrow, right to audit, data ownership, exit clauses
• Security Review: Vendor security certifications (ISO 27001, SOC 2), penetration testing results
• Configuration vs. Customization: Customizations increase complexity and maintenance risk

Source Code Escrow

An arrangement where the software source code is held by a neutral third party. Released to the customer if the vendor goes bankrupt or fails to maintain the software. Critical for business continuity.

Software Licensing Compliance

Organizations must ensure compliance with software licenses. Risks: legal liability for unlicensed use, audit by vendors (BSA), reputational damage. IS auditors review: license inventory, software asset management tools, and reconciliation of licenses purchased vs. deployed.

Open Source Software (OSS) Risks

• License compliance (GPL, MIT, Apache — different obligations)
• Vulnerability management (no vendor to issue patches)
• Support availability
• Supply chain security (malicious code injection in OSS libraries)

SaaS Acquisition Considerations

• Data residency and sovereignty requirements
• Security certifications (SOC 2 Type II, ISO 27001)
• Data portability and exit strategy
• Integration capabilities (API security)
• Shared responsibility model — who is responsible for what

Implementation / Cutover Strategies

Data Migration Controls

Moving data from old system to new requires rigorous controls:

• Data mapping: Map source fields to target fields
• Data cleansing: Correct data quality issues before migration
• Data conversion rules: Documented transformation logic
• Reconciliation: Record counts, totals match between source and target
• Validation testing: Sample verification of migrated data accuracy
• Migration trial runs: Test migrations before final cutover
• Rollback plan: Ability to revert if migration fails

Training & Change Management

User adoption is critical for implementation success. IS auditor reviews:

• Training needs assessment conducted
• Training materials developed and approved
• Training completed BEFORE go-live
• Help desk/support readiness
• User documentation and quick reference guides available

Go-Live Readiness Checklist (IS Audit Perspective)

• All critical defects resolved or formally accepted
• UAT formally signed off by business users
• Data migration completed and reconciled
• Security configuration reviewed and approved
• Access rights provisioned and reviewed
• Rollback plan documented and tested
• Operations team trained and ready
• Contingency plan in place

Post-Implementation Review (PIR)

PIR evaluates whether the implemented system achieved its stated objectives and business case. Key PIR activities:

• Assess achievement of functional requirements
• Measure performance against non-functional requirements (response time, availability)
• Evaluate benefits realization vs. business case projections
• Review actual costs vs. budgeted costs
• Assess user satisfaction and adoption
• Identify lessons learned for future projects
• Document outstanding issues and improvement opportunities

Benefits Realization Management

IT investments should deliver measurable business benefits. Benefits types:

System Maintenance & Ongoing Controls

After implementation, the system enters maintenance phase. IS auditor focuses on:

• Change management controls continue to apply to all maintenance changes
• Patch management: timely application of vendor security patches
• Access control reviews: periodic review of user access rights
• System performance monitoring and capacity management
• Backup and recovery testing

End-of-Life (EOL) Planning

When a system reaches end-of-life, IS auditors review: migration or decommission plan, data retention and archival, data sanitization before disposal, regulatory compliance for record retention, and contract termination controls.

DevOps & Continuous Integration/Continuous Deployment (CI/CD)

DevOps breaks down silos between development and operations, enabling faster, more reliable delivery.

• Continuous Integration (CI): Developers frequently merge code; automated builds and tests run
• Continuous Delivery (CD): Software always in deployable state; deployment is manual decision
• Continuous Deployment: Every passing change automatically deployed to production

DevSecOps — Security in DevOps

"Shift Left" — integrate security testing early and throughout the development pipeline:

• IDE Plugins: Security checks during coding
• SAST: Static code analysis in CI pipeline
• DAST: Dynamic testing in staging environments
• Container Security: Image scanning (Snyk, Trivy)
• Infrastructure as Code (IaC) scanning: Security policies in Terraform/Ansible templates
• Secrets Management: Prevent credentials in source code (HashiCorp Vault)

Cloud-Native Development

• Containers (Docker): Lightweight, portable application packaging
• Container Orchestration (Kubernetes): Managing containerized applications at scale
• Serverless: Functions-as-a-Service (AWS Lambda) — no server management
• Infrastructure as Code (IaC): Terraform, CloudFormation — infrastructure defined in code

Artificial Intelligence & Machine Learning in IS Development

• AI-assisted coding: GitHub Copilot, code generation tools — new risk of AI-generated vulnerabilities
• Low-code/No-code platforms: Business users build applications; IS auditor must assess governance and security
• Algorithmic accountability: AI decision-making must be explainable, auditable, and free from bias
• Model risk management: Validation of AI/ML models before production use

Robotic Process Automation (RPA)

Software robots automate repetitive, rule-based tasks. IS auditor considerations:

• Bot access controls and privileged access management
• Change management for bot modifications
• Exception handling and human-in-the-loop controls
• Audit logging of bot activities
• Business continuity if bots fail

API Security

Modern applications rely heavily on APIs. Key security controls: Authentication (OAuth 2.0, API keys), Rate limiting, Input validation, Encryption (HTTPS/TLS), API gateway for centralized control, and API versioning/deprecation management.