AutoQ content pack
Software Development Life Cycle Review
This review assesses whether the controls over how systems are approved, specified, built, tested, implemented and maintained are designed well and operating as intended.
The pack is a complete control questionnaire, ready to run on AutoQ Standalone or Enterprise Version 3.1 alongside your other reviews, with its own installer. Your team answers each control and records the evidence it inspected, and AutoQ writes the statement of fact, risk, effect and recommendation for every answer, rates each domain and produces the reports.
High-risk controls are those where a failure most directly lets an unauthorized, untested or incorrect change reach production.
Who it's for
- IT auditors testing IT general controls over program change
- Project and portfolio offices
- Internal audit teams reviewing a major system project
- External auditors relying on application controls
When to use it
- IT general controls testing for a financial audit
- A pre-implementation review of a significant project
- A review of how a development life cycle methodology is followed
What it covers
Project Governance and Planning
20 controls, 3 of them high risk
High-risk focus: approval before each phase, security and privacy considered from the start, and legal and regulatory requirements identified.
Examples of the controls:
- Each phase ends with a documented review, and the next phase starts only after approval by the sponsor or steering group.
- Information security and privacy requirements are assessed at project start, and the security and privacy functions are consulted at the key gates.
- A documented system development life cycle methodology defines the phases, deliverables, approvals and roles for every development project, whether delivered in sequential phases or iterations.
Requirements and Design
20 controls, 5 of them high risk
High-risk focus: documented and approved requirements, specified application controls, security assessment of the design, and approved user roles with segregation of duties.
Examples of the controls:
- Business, functional and non-functional requirements, including performance, availability, security and controls, are documented for each project.
- Requirements are reviewed and approved by the business owner before design or development of the affected scope starts.
- Each requirement is traced through design and testing, so every requirement is delivered and tested.
Development and Configuration
20 controls, 11 of them high risk
High-risk focus: version control, independent code review, authorized changes, segregation of development from production migration, no standing developer access to production, separate environments, secure development, secrets kept out of code, controlled configuration and emergency changes, and monitoring for unauthorized changes.
Examples of the controls:
- All source code, configuration, scripts and infrastructure definitions are kept in version control.
- Every change is reviewed and approved by someone other than its author before it is merged.
- Coding and documentation standards are defined for each language and platform, and code is reviewed against them.
Testing and Acceptance
20 controls, 5 of them high risk
High-risk focus: independent system testing, security testing, user acceptance testing with formal sign-off, and testing of application controls.
Examples of the controls:
- The complete system is tested against the requirements by testers other than the developers, and results are documented.
- Security testing, including vulnerability scanning and, for significant or internet-facing systems, a penetration test, is completed before go-live and findings are resolved or accepted.
- Each project has a test strategy defining the levels of testing, environments, data, responsibilities and exit criteria.
Implementation and Maintenance
20 controls, 8 of them high risk
High-risk focus: approval before go-live, planned and reconciled data migration, controlled deployment, access set up from approved requests, controlled maintenance changes, timely patching, and backup and recovery from day one.
Examples of the controls:
- Go-live is approved by the business owner and IT, based on test results, open defects and readiness.
- Data migration is planned with data mapping, cleansing, ownership, controls and reconciliation steps.
- Each go-live has a documented implementation plan with steps, responsibilities, timing, checkpoints and a back-out plan.
Frameworks
Every control carries references to COBIT 2019, ISO/IEC 27001:2022 Annex A and ISO/IEC/IEEE 12207:2017, so findings can be tied to the criteria your audit uses.
Criteria references mapped from COBIT 2019 (governance and management objectives and practices), ISO/IEC 27001:2022 Annex A and ISO/IEC/IEEE 12207:2017 (software life cycle process clauses). Verify against the editions your audit uses.
What's in the workbook
| Control Library | Every control with its domain and subdomain, the control assertion, type, nature, frequency and risk weight, the framework references, the suggested test procedure, the evidence to request, the statements of fact if true and if false, the effect if false and the recommendation. |
|---|---|
| Questionnaire | The working sheet the review team answers, control by control, with the evidence they inspected; AutoQ fills in the findings from the answers. |
| Domain Summary | The rating of each domain, weighted by risk, ready for the report. |
| Column Guide | What every column means and how it is used. |
| Sources | The framework editions the references were mapped from, with a column for the reviewer to record the date each reference was checked. |
Delivered with its own installer, which adds it to AutoQ as a new review (or as a .zip to add on the Admin tab). The questionnaire is an Excel workbook, so it can be adapted with your own controls and ratings.
The framework references were mapped from the published texts and should be checked by a qualified reviewer against the editions your audit uses. The pack supports a review; it does not replace professional judgement or the requirements of your regulator.