SDLC Phases: What the IS Auditor Checks
Every SDLC phase ends with a sign-off. Here's what the auditor checks before each one.
The system development life cycle (SDLC) is the fixed sequence an organisation follows to build or buy an application: decide whether to do it, define what it must do, design it, build it, test it, put it live and then keep it running. Each phase ends with a deliverable or a sign-off, which is exactly what makes it auditable.
DISA Module 3 treats the IS auditor as someone who checks each phase while the project is still running, not only after go-live. The questions it asks are less about programming and more about whether the right people approved the right document at the right time, and whether controls were designed in rather than bolted on.
You save ₹450
- Full-length timed mocks
- Module-wise practice
- Emerging-tech coverage
One payment, no subscription · Valid for 2 months
The Phases and What the Auditor Checks
ICAI's Module 3 material numbers analysis and design as 3a and 3b, so the list reads as seven phases with eight steps.
1. Feasibility study
What happens
Technical, economic and social feasibility; costs, benefits and expected return feed the business case
What the IS auditor checks
Whether the business need exists, the cost-benefit is reasonable, and the build-or-buy choice and alternatives were justified
2. Requirements definition
What happens
Users state functional, service and quality requirements
What the IS auditor checks
Affected users were represented; the requirements document is accurate and complete
3a. System analysis
What happens
Existing process mapped against new requirements
What the IS auditor checks
Management approved the project and cost; for acquisition, enough vendors were asked for proposals; embedded audit routines were requested where useful
3b. Design
What happens
Specifications baselined: modules, interfaces, hardware, database, security
What the IS auditor checks
Input, processing and output controls and audit trails are in the design; a change process stops uncontrolled new requirements
4. Development
What happens
Programs coded to the design under coding standards
What the IS auditor checks
Documentation complete; QA reports on coding standards; bugs found in testing go back for rework
5. Testing
What happens
Quality assurance testing, then user acceptance testing (UAT)
What the IS auditor checks
Test plans complete, users took part, conversion totals reconciled, parallel run results reviewed, access tests run
6. Implementation
What happens
Roll-out by cut-off, phased, pilot or parallel changeover
What the IS auditor checks
Formal acceptance signed; installed under change control; data conversion confirmed by user departments before final sign-off
7. Maintenance
What happens
Support, changes and post-implementation review
What the IS auditor checks
Objectives and benefits achieved; changes authorised; emergency changes and emergency IDs controlled
| Phase | What happens | What the IS auditor checks |
|---|---|---|
| 1. Feasibility study | Technical, economic and social feasibility; costs, benefits and expected return feed the business case | Whether the business need exists, the cost-benefit is reasonable, and the build-or-buy choice and alternatives were justified |
| 2. Requirements definition | Users state functional, service and quality requirements | Affected users were represented; the requirements document is accurate and complete |
| 3a. System analysis | Existing process mapped against new requirements | Management approved the project and cost; for acquisition, enough vendors were asked for proposals; embedded audit routines were requested where useful |
| 3b. Design | Specifications baselined: modules, interfaces, hardware, database, security | Input, processing and output controls and audit trails are in the design; a change process stops uncontrolled new requirements |
| 4. Development | Programs coded to the design under coding standards | Documentation complete; QA reports on coding standards; bugs found in testing go back for rework |
| 5. Testing | Quality assurance testing, then user acceptance testing (UAT) | Test plans complete, users took part, conversion totals reconciled, parallel run results reviewed, access tests run |
| 6. Implementation | Roll-out by cut-off, phased, pilot or parallel changeover | Formal acceptance signed; installed under change control; data conversion confirmed by user departments before final sign-off |
| 7. Maintenance | Support, changes and post-implementation review | Objectives and benefits achieved; changes authorised; emergency changes and emergency IDs controlled |
The Number of Phases Varies
ICAI's material says an SDLC typically has seven phases but that the count depends on the project's milestones. An in-house team may fold UAT into testing; for outsourced or acquired software, UAT is a separate signed-off milestone. Read a question for the phase it describes, not for a number.
Where Controls Get Built In
The cost of a missing control rises with every phase it slips past. The points where the material expects controls to appear:
- check_circleRequirements definition: security requirements are first considered here, alongside functional needs
- check_circleAnalysis and design: request embedded audit modules or an integrated test facility now, while they are cheap to add
- check_circleDesign: input validation, processing checks, output controls and audit trails are specified and reviewed
- check_circleTesting: access tests confirm that the designed security works, and conversion totals are reconciled
- check_circleImplementation: the move to production follows the organisation's change control procedures
Quick practice on audit concepts. No signup.
Independence: How Close the Auditor Can Get
An auditor reviewing a project in flight is useful only while still independent of it. Module 3's own chapter-end answer takes a clear line: an auditor who designed, selected or implemented the security controls can no longer audit that system, because they would be reviewing their own work. Building an integrated test facility does not cause the same problem, since it is an audit tool, not a control.
In practice, a firm advising a bank's core banking upgrade can review the requirements and test results and give an opinion before go-live, but should not write the access matrix it will later test.
How the DISA Assessment Test Tests This
Expect short scenarios that ask which phase something belongs to, or what the auditor should check first. Patterns visible in ICAI's own chapter-end questions:
- check_circleA build-or-buy decision is an outcome of the feasibility study, not of analysis or design
- check_circleThe go or no-go decision rests on the business case, which pulls together benefits, costs and feasibility
- check_circleSecurity controls are first considered at requirements definition; candidates often pick design
- check_circleA reason to start a new SDLC project is a business driver (a competitor's new service), not spare budget or a faster server; a regulator asking for extra reports is usually a change request
- check_circleThe trap: choosing the answer that is true but belongs to a different phase
FAQs
What are the phases of SDLC in DISA?expand_more
ICAI's Module 3 lists feasibility study, requirements definition, system analysis and design (3a and 3b), development, testing, implementation and maintenance, with post-implementation review in the last phase.
In which SDLC phase should security be considered first?expand_more
Requirements definition. Security requirements are part of what the system must do, so they are defined before design turns them into specific controls.
What is the role of an IS auditor in SDLC?expand_more
To review each phase's deliverables and approvals, check that controls and audit trails are designed in, and give management an opinion before go-live, without designing or implementing the controls themselves.
Can an IS auditor be part of the SDLC project team?expand_more
They can advise and review. If they design, select or implement controls, they lose the independence needed to audit the system later.
Next steps
- SDLC Modelsarrow_forward
- Post-Implementation Reviewarrow_forward
- Acquisition & Vendorsarrow_forward
- Syllabusarrow_forward
Assessment Test format, timed and scored.