CISA · Domain 3
Information Systems Acquisition, Development and Implementation
About 12% of the exam
Project governance
- Business case justifies the investment
- Project charter authorizes scope and sponsor
- Steering committee oversees, sponsor owns benefits
- Function points size software objectively
- Scope changes go through change control
- Auditor reviews the project, not manages it
- Benefits realization checked after go-live
Feasibility and requirements
- Feasibility study comes first
- Requirements signed off by business users
- Poor requirements cause costly rework
- Security and privacy requirements from the start
- Threat modeling during requirements and design
- Traceability matrix links requirements to tests
- Auditor checks requirements, not code style
The most expensive defect is a requirement missed before design
SDLC phases
- Feasibility
- Requirements
- Design
- Development
- Testing
- Implementation
- Post-implementation
- Design translates requirements into architecture
- Development follows secure coding standards
- Testing proves requirements were met
- Implementation converts data and users
- Post-implementation review closes the loop
Development approaches
- Waterfall
- sequential, heavy documentation
- Agile
- iterative, working software over documents
- Agile audit risk
- thin documentation, weak audit trail
- Prototyping
- prototype slips into production uncontrolled
- RAD
- fast iterations, strong user involvement
- DevOps
- automated pipeline, continuous deployment
- Low code
- business users build, needs cataloging
Testing ladder
- Unit
- Integration
- System
- User acceptance
- Regression
What each proves
- Unit
- one module works alone
- Integration
- interfaces exchange data correctly
- System
- whole system meets specification
- UAT
- business confirms it meets requirements
- Regression
- nothing old broke after change
Security testing
- SAST
- static, on source code, early
- DAST
- dynamic, on running application
- Code review
- peer inspection before merge
- Penetration test
- before production exposure
- Test data
- masked, never live PII
UAT is the business signing off; QA cannot accept on their behalf
Application controls
- Input
- range, format, reasonableness, check digit
- Processing
- run to run totals, exception reports
- Output
- distribution, reconciliation, retention
- Batch totals
- record count, hash total, dollar total
- Sequence check
- missing or duplicate records
- Edit checks
- reject invalid before storage
- ETL validation
- transform rules tested, reconciled
Input controls prevent, processing controls detect, output controls confirm
Change and release control
- Request, assess, approve, test, deploy, review
- Developers never touch production directly
- Separate development, test, production environments
- Emergency changes approved after the fact
- Version control on code and IaC templates
- Pipeline needs approval gate before production
- Policy as code enforces configuration
- Rollback plan for every release
Implementation strategies
- Parallel
- old and new together, lowest risk
- Phased
- module by module or site by site
- Pilot
- one location first
- Direct cutover
- big bang, highest risk
- Canary
- small user share, quick rollback
- Blue green
- two environments, switch traffic
Parallel costs the most and risks the least; direct cutover is the reverse
Data migration and PIR
- Validate completeness and accuracy of migrated data
- Reconcile record counts and control totals
- Legacy business logic is often undocumented
- Fallback plan if conversion fails
- Post-implementation review after stabilization
- PIR asks: were business objectives achieved
- PIR captures lessons for the next project
- Independent party, not the project team
Acquiring software
- RFP built from defined requirements
- Fit to requirements beats price or brand
- Heavy COTS customization blocks future upgrades
- Escrow protects source if vendor fails
- Contract: SLA, ownership, exit, right to audit
- Reference checks and proof of concept
- Technical debt plan for legacy code
- Cloud exit plan avoids lock-in
Emerging technology audit
Cloud and DevOps
- Shared responsibility model first
- IaaS gives customer most control
- Public storage buckets are customer misconfiguration
- Data residency across jurisdictions
- Multi-tenant isolation, hypervisor risk
- Serverless: ephemeral, hard to log
- Kubernetes: RBAC, default certificates, root containers
AI, RPA, blockchain, IoT
- AI: bias, explainability, model validation
- Shadow AI and generative AI data leakage
- Autonomous decisions need limits and escalation
- RPA bots hold excessive privilege, replicate errors
- Smart contracts audited before deployment
- IoT: default credentials, no patching, segment
- OT prioritizes availability and safety
- Quantum threatens RSA and ECC, plan now
New technology, old questions: who owns the risk, where is the data, what control proves it works
Know the order
- Business case
- Feasibility
- Requirements
- Design
- Build
- Test
- Convert
- PIR
- Test: unit, integration, system, UAT
- Cutover risk: parallel, phased, pilot, direct
- Security: threat model, SAST, DAST, pentest
- Change: request, approve, test, deploy, review
Rapid recall
- UAT
- business confirms requirements met
- PIR
- did it deliver the objectives
- COTS
- commercial off the shelf package
- Escrow
- source code held by third party
- SAST
- static analysis during coding
- IaC
- infrastructure defined in versioned code
- CI/CD
- automated build, test, deploy pipeline
- Function point
- size by user visible functions
Reference strip: lifecycle, controls, testing, cutover, emerging tech
Lifecycle models
- Waterfall, V model, spiral
- Agile, Scrum, Kanban
- Prototyping, RAD, DevOps, DevSecOps
- Object oriented, component based, microservices
Application control types
- Input: validation, authorization, edit checks
- Processing: totals, exception handling
- Output: reconciliation, distribution, retention
- Interface controls between systems
Testing vocabulary
- Unit, integration, system, UAT, regression
- Black box, white box, gray box
- SAST, DAST, IAST, fuzzing
- Sociability, interface, pilot, parallel
Cutover approaches
- Parallel: lowest risk, highest cost
- Phased: gradual by module or site
- Pilot: one site proves it
- Direct: highest risk, one shot
Emerging tech checklist
- Cloud: shared responsibility, residency, exit
- AI: bias, transparency, model governance
- IoT and OT: segmentation, patching, safety
- Blockchain: smart contract code review
- APIs: central gateway, authentication, rate limits
Quick exam traps
- Trap: Developers may fix production code directly if it is urgent
- Trap: QA can perform user acceptance testing for the business
- Trap: Direct cutover is the lowest risk implementation approach
- Trap: The post-implementation review checks whether the project finished on budget
- Trap: In IaaS the cloud provider patches the guest operating system
- Trap: Agile removes the need for documentation an auditor can rely on
- Trap: A publicly readable cloud bucket is the provider's fault
- Trap: Extensive customization of a COTS package carries no long-term risk
cybercertprep.com · original revision sheet written from the public body of knowledge