Start with the decision the report must support
An audit scope should begin with the decision you need to make: open a paid pilot, approve a release, acquire a product or prioritise remediation. “Review our code” does not tell a reviewer which consequences matter. Write the decision and the deadline in the proposal. Then identify the customer journeys that could change that decision. This makes the engagement assessable even when the codebase is unfamiliar.
Name the boundaries and exclusions
List repositories, deployed services, environments, user roles and external integrations. Distinguish the source being reviewed from the configuration actually running. If mobile clients, infrastructure or payment workflows are excluded, state that visibly. A founder comparing two prices should be able to see that one includes production configuration and the other does not. Exclusions are useful when they are deliberate, not discovered after the report arrives.
Use a concrete example to test the scope
Consider an appointment service with customer booking, staff administration and payments. Ask whether the review follows one reservation through all three components. Does it examine who can change the appointment and what happens when payment confirmation is delayed? A review of the React interface alone cannot answer those questions. The proposal should explain which evidence will be available and where conclusions will necessarily be limited.
Agree what findings must contain
Request an affected component, observed behaviour, reproduction evidence, consequence and recommended next action. Ask how the reviewer separates confirmed findings from hypotheses. OWASP ASVS can help express verification requirements, but a reference to the standard is not proof that every requirement will be tested. Specify the version and selected coverage when a proposal relies on it. Agree whether retesting is included or separately priced.
Leave the scoping call with a short record
Retain the agreed boundaries, access owner, start conditions, delivery dates and acceptance criteria. Record what happens if access is delayed or the product changes during the engagement. A useful scope lets both parties identify whether the work was delivered. It also helps the engineering team prepare evidence without sharing unnecessary customer data. If a proposal still cannot explain what decision its report supports, clarify it before commissioning the work.
Sources & further reading
Reference material for the guidance and examples above. Where included, community discussions provide context rather than verified incident evidence.
Prepared with AI assistance. Examples are illustrative and are not client case studies.
About CodeSignOff Editorial
CodeSignOff Editorial publishes engineering guidance for founders evaluating AI-built software. CodeSignOff is a product of Avi Root Info Solutions, led by Shekhar Juneja, whose software career began in 1998 and includes architecture for UK mortgage and credit-rating systems. This organisational byline does not indicate a personal review of this article by Shekhar.
Engineering background and editorial approach · Shekhar’s professional profile ↗
Evidence to take into your own review
Define the code revision and scope. For each finding, record the affected flow, the steps that reproduce it, its business consequence and the evidence for the next action. After a fix, repeat the check and record what remains uncertain. An audit delivers a verdict; remediation and verification are separate steps.
This article is general engineering guidance. It does not establish the security or compliance of your application. Contact us with a correction or a question about the guidance.