Skip to content
Software development
ASD ISMISM-2061

ASD ISM 2061 Peer reviews of critical and security-related software components

What it says

Peer reviews are conducted on all critical and security-related software components.

Quoted as published. Everything else on this page is written by Control Stack.

What it means

In plain English

Have a second qualified developer review all critical and security-related parts of your software before they go live.

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.

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.

How to implement

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

Keep it running

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.

Evidence and audit

  1. Check 1 of 5What an auditor asks for

    Ask for

    the organisation's documented definition of which software components are classified as 'critical' and 'security-related'.

    Look at

    whether the list is specific and current.

    Good evidence

    is a maintained list that clearly names the relevant components rather than a vague statement that 'important code' is reviewed.

  2. Check 2 of 5What an auditor asks for

    Ask for

    how a code change to a critical or security-related component is technically prevented from going live without a peer review.

    Look at

    the repository or pipeline settings that enforce reviewer approval.

    Good evidence

    shows the review is a mandatory, system-enforced gate, not just an honour system.

  3. Check 3 of 5What an auditor asks for

    Ask for

    records of recent peer reviews covering critical and security-related changes.

    Look at

    whether each record names the author, a separate reviewer, the date, and any issues raised.

    Good evidence

    shows the reviewer is always someone other than the author and that comments were genuinely actioned.

  4. Check 4 of 5What an auditor asks for

    Ask for

    what reviewers actually check for during a security-related peer review.

    Look at

    a checklist or guidance covering things like input handling, access control and exposed secrets.

    Good evidence

    shows reviewers look for security flaws specifically, not just whether the code runs.

  5. Check 5 of 5What an auditor asks for

    Ask for

    the auditor to trace one recent critical or security-related release back to its peer review.

    Look at

    whether a matching, approved review exists for that exact change.

    Good evidence

    is an unbroken trail from the live change to a completed review by a qualified peer.

Mappings

Closest match in ISO/IEC 27001: A.8.28, Secure coding practices in software development, which this control covers in full and more.

ISO 27001

ISO/IEC 27001: 3 mappings

  • A.8.28Secure coding practices in software developmentBroader than
  • A.8.25Secure development lifecyclePartially meets
  • A.8.29Security testing in development and acceptancePartially overlaps

Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.