AUDITING THE SDLC
For the Non-IT Auditor
Victoria Silver, CISA
group1solutions
Audit & Compliance for Accounting & IT
The 35,000 Ft. View
Systems / Software
Development
Life Cycle
“….the internal auditor should expect to see some type
of development life cycle and will need to determine
whether it is appropriately followed. ” (p. 11)
SDLC vs. Project Management
The First SDLC Model
Evolution of the SDLC
The Waterfall Model
Generic
SDLC Model
Requirements Quality vs.
Average Project Overruns
Auditing the
Requirements Phase
Controls provide reasonable
assurance that the business and IT
have identified and agreed upon the
functional and technical
requirements in sufficient detail to
achieve the expected outcome.
Requirements
Activities
Exist?
Reasonable
Detail?
Appropriate to
Size /
Experience?
Appropriate
Involvement?
Appropriate
Level?
Exist?
Reasonable
Detail?
Requirements Completeness:
Areas to Consider
 Functional (i.e. what is does)
 Compliance (i.e. legal restrictions)
 Usability (i.e. how users interact with it)
 Reports (e.g. audit, logging)
 Security & Controls
 Interfaces (i.e. how it works with other systems)
 Performance (e.g. volume, capacity, speed)
 Support (e.g. error checking, recovery)
 Environmental (e.g. hardware & software)
Auditing the Design Phase
Controls provide reasonable
assurance that design specifications
are created that accurately represent
requirements and can be built in a
timely and cost effective manner.
Design
Activities
Exist?
Traceable?
Complete?
Approved?
Appropriate
Involvement?
Expected Design Content









Definition of inputs & outputs
Screen designs
Report designs
Program logic by module
Data designs
Error Handling
Access controls
Audit Trails
System Interfaces
Traceability to
Requirements
is Critical!
Auditing the Build Phase
Controls provide reasonable
assurance that code is developed in
accordance with design
specifications, development
standards and quality requirements.
Segregated
Environment?
Version
Control?
Exist &
Followed?
Coding &
Unit Test
Activities
Independent?
Appropriate
Detail?
About Code Reviews
 Types of Reviews
 Automated Code Analysis
 Peer Reviews
 Subjects of Review:





Security
Delivery of requirements
Well designed interfaces
Maintainability / documentation
Follows standards
Other Phase “Builds”
 Data Conversion Plan
 Maintenance Plan
 Training Materials
 User & Systems Documentations
 Disaster Recovery Plans
 Test Plans
Auditing the Testing Phase
Controls provide reasonable
assurance that the system has been
validated as fit for use, free from
errors and will work without major
problems after installation.
Expected Test Coverage
Other Types
• Performance
• Disaster
Recovery
• Regression
Minimum
testing level?
Test
Planning
Activities
Appropriate
approvals?
Exist?
?
Traceable?
Sample Test Case
Function
Tested
Initial State
Input
Expected
Output
Actual
Result
Tester /
Date
Result
System asks customer to choose an
account to deposit to
Menu of transaction types is being displayed
Choose Deposit transaction
System displays a menu of account types
Account types appeared on menu.
J. Smith 4/1/2011
Pass
Independent?
Complete?
Testing Activities
Separate,
Complete,
Verified?
Complete &
reviewed?
Fixed &
retested?
All
Stakeholders?
Auditing the Implementation Phase
Controls provide reasonable
assurance that the new production
system is working as expected and
has been approved for production
use.
Expected Implementation Plans
 Deployment schedule with assignments
 Contact list
 Communications to end users
 Data conversion cut-over plans
 Infrastructure migration tasks
 Parallel testing plans
 Go / No Go decision points
 Failover / recovery plans
 Appropriate stakeholder go live sign-offs
Implementation
Activities
Complete?
Correct?
Errorfree?
Appropriate
approvals?
Types of SDLC Audits
AFTER
•What went wrong?
•How can they be corrected for future projects?
•Is the SDLC being followed?
DURING •Are risks being mitigated effectively?
•Do they have an SDLC?
BEFORE •Is the SDLC model appropriate?
Evolving SDLC Models:
Decreasing Degrees of Control
More PlanDriven
More
Adaptive
The Iterative Model
Repetitive
prototypes
build on each
other as
functionality is
added in each
iteration.
Key Points to Consider
Test against the chosen methodology.
Different models have different uses / risks
General risk and controls still apply
Validate deliverables against requirements
Do key components exist? (security, performance)
Accuracy & boundaries drive cost & schedule
Look for traceability from requirements to testing
Consider security in ALL environments
Look for configuration management
For requirements / design documents
For code /build versions
Questions?
I’LL NEED TO KNOW
YOUR REQUIREMENTS
BEFORE I START TO
DESIGN THE SOFTWARE.
I WON’T KNOW WHAT
I CAN ACCOMPLISH
UNTIL YOU TELL ME
WHAT THE SOFTWARE
CAN DO.
FIRST OF ALL,
WHAT ARE YOU
TRYING TO
ACCOMPLISH?
TRY TO GET THIS
CONCEPT THROUGH YOUR
THICK SKULL: THE
SOFTWARE CAN DO
WHATEVER I DESIGN
IT TO DO!
I’M TRYING TO
MAKE YOU DESIGN
MY SOFTWARE.
I MEAN WHAT ARE
YOU TRYING TO
ACCOMPLISH WITH
THE SOFTWARE?.
CAN YOU DESIGN
IT TO TELL YOU
MY REQUIREMENTS?
Victoria Silver, CISA
vsilver@group1solutions.com
m: 503-516-1277
www.group1solutions.com
group1solutions
Audit & Compliance for Accounting & IT