DerpGRC

    Domain 3: Information Systems Acquisition, Development and Implementation

    CISA ยท about 12% of the exam

    How systems are justified, built or bought, tested, controlled and moved into production.

    Revising? All of this domain's slides in one deck. When you're done, take the domain quiz.

    Project management

    • Project Roles and Governance Who does what on an IT project, how a project is kept under control from start to finish, the three ways to organise a project team, and the auditor's place in it.
    • PMBOK Phases The five groups of project management activity, the scope-time-cost balancing act, and the project documents and controls an auditor looks for.
    • Gantt, PERT, Critical Path Three scheduling tools explained with one small project: Gantt charts to show the timeline, PERT to estimate uncertain tasks, and the critical path to find which delays really matter.
    • Function Point Analysis Estimating how big a system is from what it does for users, before any code exists, and why that beats counting lines of code for early estimates.
    • Earned Value and Project Risk Why 'we've spent half the budget' tells you nothing about progress, how earned value fixes that (with worked numbers), and how project risks are managed.
    • Business Case and Feasibility The document that justifies spending money on a project, the five feasibility questions, and why the business case gets checked again at every stage.
    • Benefits Realization Making sure a project actually delivers the value its business case promised, not just a working system: owners, baselines, measurement after go-live.

    Development

    • SDLC Phases Overview The life of a system from idea to review: the phases of the system development life cycle, the key control in each, and why controls belong at the very start.
    • Requirements Definition Writing down what a system must do and how well, making sure security and controls aren't forgotten, getting users to sign off, and tracing every requirement to a test.
    • System Design Turning agreed requirements into a blueprint: what design produces, why controls must be specified here, design reviews, and how design works when you buy software instead.
    • Waterfall vs. Iterative vs. Prototyping The traditional ways to run development (waterfall, V-model, iterative, spiral and prototyping), when each one fits, and the control risks the exam links to each.
    • Agile Building software in short sprints with constant user feedback: Scrum's roles and events, the control risks agile creates, and how an auditor adapts.
    • DevOps and DevSecOps Shipping small changes often through an automated pipeline: what CI/CD means, how segregation of duties survives when one team builds and runs, and how security gets built into every step.
    • RAD, CASE, Low-Code Tools and methods for building faster (rapid application development, CASE tools, 4GLs, low-code platforms and reusable components), and why the usual controls still apply.
    • Build, Coding Standards, Code Review The controls that apply while code is being written: coding standards, secure coding habits, version control, review by a second pair of eyes, and keeping production code locked down.

    Testing

    • Testing Levels: Unit, Integration, System, UAT The levels of testing from a single module up to user acceptance, who does each and what it proves, plus top-down versus bottom-up, load versus stress, and black-box versus white-box.
    • Regression, Sociability, Parallel, Pilot Testing Four tests the exam loves to mix up, what question each one answers, and how to spot the right one in a scenario.
    • Defect Management What happens to a bug once testing finds it: logging, severity versus priority, fixing and retesting, who gets to close it, and how open defects affect the go-live decision.

    Implementation

    • Data Migration and Conversion Moving data from the old system to the new one without losing or changing anything: mapping, cleansing, trial runs, reconciling the totals, and who signs off that the data is right.
    • Change-Over: Parallel, Phased, Abrupt The four ways to switch from an old system to a new one, how they trade risk against cost, and how to pick the right one from a scenario.
    • Go-Live Readiness and Acceptance What must be true before a system goes into production, who gets to say yes, and what the auditor checks in a pre-implementation review.
    • Post-Implementation Review Looking back once the dust has settled: what a post-implementation review checks, when it's done, who does it, and why an auditor who helped build the system shouldn't.

    Application controls

    • Input Controls Stopping bad data at the door: input authorisation, batch totals, the full set of validation edits with a way to spot each one in a scenario, and what happens to rejected data.
    • Processing Controls Keeping data right while the system works on it: run-to-run totals, recalculation, file reconciliation, extra care with master data, and audit trails.
    • Output Controls The last checkpoint before results leave the system: balancing output, sending reports only to the right people, guarding cheques and other valuable forms, and keeping or destroying output properly.
    • Data Integrity and ACID How databases keep data trustworthy: the four ACID properties explained with a bank transfer, what goes wrong when two users collide, integrity rules, and data integrity testing.
    • EDI and E-Commerce Controls Business documents sent machine to machine: how EDI works, what can go wrong without paper, the controls that replace it, and the risks and controls of selling online.