Peer Reviews of Critical and Security-Related Software Components
Have a second qualified developer review all critical and security-related parts of your software before they go live.
Plain language
This control means that whenever your developers write or change the most important parts of your software, or any part that affects security, another developer must check that work before it is used. A peer review is simply a second set of expert eyes looking over the code to catch mistakes, weaknesses, or risky shortcuts. It matters because one person working alone can easily miss a flaw that lets an attacker break in or causes the system to fail.
Framework
ASD Information Security Manual (ISM)
Control effect
Preventative
Classifications
NC, OS, P, S, TS
ISM last updated
June 2026
Control Stack last updated
18 June 2026
E8 maturity levels
N/A
Guideline
Guidelines for software developmentOfficial control statement
Peer reviews are conducted on all critical and security-related software components.
Why it matters
If critical or security-related code goes live without a second expert review, undetected flaws can let attackers break in or cause important systems to fail, leading to breaches, outages and lost customer trust.
Operational notes
Keep the list of critical and security-related components up to date as the software changes, and review the peer review records periodically to confirm the practice is being followed for every relevant change.
Implementation tips
- The development team lead should agree a written list of which software components count as 'critical' (the parts the business depends on) and 'security-related' (anything handling passwords, logins, payments, encryption or access control), so everyone knows exactly which work must be peer reviewed.
- Each developer should require a second, suitably skilled developer to review their changes to those listed components before the change is allowed to go live, and the original author should never be the one who approves their own work.
- The IT manager should set up the code repository (the place where software is stored) so that changes to critical or security-related components cannot be merged or released until a reviewer has formally approved them, making the review a mandatory gate rather than an optional step.
- The reviewer should follow a short checklist when reviewing, covering security basics such as how user input is handled, how errors are dealt with, and whether secrets like passwords are exposed, and should record any issues found and confirm they were fixed before approving.
- The development team lead should keep a dated record of each peer review (what was reviewed, who reviewed it, what was found and what was fixed) so the organisation can later show that the review actually happened for every critical and security-related change.
Audit / evidence tips
- Askthe organisation's documented definition of which software components are classified as 'critical' and 'security-related'Look atwhether the list is specific and currentGoodis a maintained list that clearly names the relevant components rather than a vague statement that 'important code' is reviewed
- Askhow a code change to a critical or security-related component is technically prevented from going live without a peer reviewLook atthe repository or pipeline settings that enforce reviewer approvalGoodshows the review is a mandatory, system-enforced gate, not just an honour system
- Askrecords of recent peer reviews covering critical and security-related changesLook atwhether each record names the author, a separate reviewer, the date, and any issues raisedGoodshows the reviewer is always someone other than the author and that comments were genuinely actioned
- Askwhat reviewers actually check for during a security-related peer reviewLook ata checklist or guidance covering things like input handling, access control and exposed secretsGoodshows reviewers look for security flaws specifically, not just whether the code runs
- Askthe auditor to trace one recent critical or security-related release back to its peer reviewLook atwhether a matching, approved review exists for that exact changeGoodis an unbroken trail from the live change to a completed review by a qualified peer
Cross-framework mappings
How ISM-2061 relates to controls across ISO/IEC 27001, ISO/IEC 42001, Essential Eight, and ASD ISM.
ISO 27001
| Control | Notes | Details |
|---|---|---|
layersPartially meets(1)expand_less | ||
| Annex A 8.28 | ISM-2061 requires developer-supported, security-focused peer reviews to be conducted on all critical and security-relevant software compo... | |
sync_altPartially overlaps(1)expand_less | ||
| Annex A 8.29 | ISM-2061 requires developer-supported security-focused peer reviews on critical and security-focused software components to identify secu... | |
linkRelated(1)expand_less | ||
| Annex A 8.25 | Annex A 8.25 requires secure development rules to be established and applied across the lifecycle | |
These mappings show relationships between controls across frameworks. They do not imply full equivalence or certification.
Related ASD ISM controls in Software development
See all Guidelines for software development controls, or browse the full ASD ISM library.