Software development and secure development audit program.
How to audit whether software is developed with defined security requirements, reviewed and tested, and whether source code and environments are protected.
Last updated: 13 October 2026 · Sample, not legal advice
Download the sample as PDF 8 pages, no sign-up
Download as Excel template with columns for result and notes, no sign-up
Audit objective
The audit assesses whether the organisation runs a development process that takes security into account from the start: requirements, architecture principles, secure coding, review and testing before release, protection of source code and development environments, and governance of outsourced development. It also assesses whether vulnerabilities in own software are handled.
Scope
- In-house developments and customised software, including web applications, interfaces and operational scripts
- Development, test and deployment processes, tools and environments
- Outsourced development by service providers
- Out of scope: standard software without customisation and change control in operations, which is covered in a separate sample
Audit program
| No. | Criterion | Reference | Audit procedure | Expected evidence |
|---|---|---|---|---|
| 1 | A framework for the development process with security requirements for each phase is defined, approved and applied. | ISO/IEC 27001:2022 Annex A 8.25; BSI CON.8 | Read the process description and check on two projects whether the security requirements per phase were implemented. | Development policy, project documents of the sample |
| 2 | Security requirements are gathered at the start for each application, agreed and tracked, including for interfaces and data. | ISO/IEC 27001:2022 Annex A 8.26; BSI APP.3.1 | Review the requirements documents of three applications for security requirements and their implementation. | Requirements documents, traceability to testing |
| 3 | Architecture and engineering principles for secure systems are defined and are applied and reviewed for new systems. | ISO/IEC 27001:2022 Annex A 8.27 | Read the architecture guidelines and trace their application for two new systems. | Architecture guidelines, design documents, decision notes |
| 4 | Binding rules exist for secure coding, which developers know and apply; training is evidenced. | ISO/IEC 27001:2022 Annex A 8.28 | Review the coding guideline, training records and examples from code review. | Coding guideline, training records, code review records |
| 5 | Changes to source code are reviewed by a second person before they reach the main branch; static analysis tools are in use. | ISO/IEC 27001:2022 Annex A 8.28 and 8.29 | Select ten changes and check that review by a second person and a run of the analysis tools are evidenced. | Extract of change requests, results of analysis tools |
| 6 | Security testing is part of development and acceptance: testing for vulnerabilities, dependencies and configuration before release. | ISO/IEC 27001:2022 Annex A 8.29; NIS2 Directive Art. 21(2)(e) | Check test plans, results and handling of findings for two releases. | Test plans, test reports, release records |
| 7 | Known vulnerabilities in libraries and components are detected, assessed and fixed; the components in use are recorded. | NIS2 Directive Art. 21(2)(e); § 30(2) no. 5 BSIG | Review the procedure for recording and checking dependencies and trace the handling of findings of the last six months. | Component list, dependency check reports, action list |
| 8 | Development, test and production are separated, and production data is not used in tests or only in protected form. | ISO/IEC 27001:2022 Annex A 8.31 | Check environments and access rights and establish whether test environments contain production data. | Environment overview, authorisation extract, procedure on test data |
| 9 | Access to source code and development tools is limited to authorised people and logged; credentials and keys are not stored in source code. | ISO/IEC 27001:2022 Annex A 8.4 | Read permissions on repositories and build systems and search source code for stored credentials. | Authorisation extract, result of secret search, logs |
| 10 | Deployment to production follows a controlled flow with approval, not direct intervention by individuals. | ISO/IEC 27001:2022 Annex A 8.32; BSI CON.8 | Compare deployment logs of the last three months with approvals. | Deployment logs, approvals, rights on production systems |
| 11 | For outsourced development, security requirements are fixed by contract, compliance is monitored and the result is checked. | ISO/IEC 27001:2022 Annex A 8.30 | Check contracts and acceptances of two outsourced developments, in particular audit rights and rights to source code. | Contracts, acceptance records, audit reports |
| 12 | Vulnerabilities in own software are reported, assessed and fixed; there is a way to receive reports from outside. | NIS2 Directive Art. 21(2)(e) | Check the procedure for handling reported vulnerabilities and how the latest reports were processed. | Procedure, reporting channel, vulnerability register |
Documents to request
- Policy on secure development and the development process
- Coding guideline and training records
- Requirements documents of the sample with security requirements
- Architecture guidelines and design documents
- Extract of change requests with review notes
- Test plans, test reports and release records
- Authorisation extract for repositories and build systems
- Contracts and acceptances of outsourced development
Typical findings
- Security requirements are considered only shortly before release, not at the start.
- Changes reach the main branch without review by a second person.
- Credentials and keys are stored in source code.
- Known vulnerabilities in libraries are not detected systematically, and the components in use are not recorded.
- Test environments contain unchanged production data.
- Contracts with development providers regulate neither audit rights nor rights to source code.
Note on references
The references point to laws, regulations and standards so that you can read the requirement in the original. No normative text is reproduced. Criteria and procedures are original wording and replace neither the text of the provisions nor legal advice. Whether and to what extent a provision applies to your organisation should be clarified before the audit.
The complete package
This sample shows the objective, the audit steps and the document list on one page. For your own audit topic, ProAuditMap creates the complete package: audit plan, audit program per audit dimension, document request list, interview guides, schedule, communication and report template. You review the draft, approve it and export to Excel and Word.
Create account View a complete sample package View pricing