Your software vendor says the application is ready. You have a delivery file, a green code-quality dashboard and a deadline. Before you recommend accepting it, can you tell whether the report covers the software your bank actually received?
A useful software vendor handover connects the delivered version to its code checks, test results, unresolved findings and approval. This checklist helps a bank application owner ask for that connection. Use our checklist alongside your bank's acceptance criteria.
Start with the version being delivered. Then work through these seven questions with your vendor.
1. Which exact version do these results cover?
Ask for the application name, release number, delivery date and source revision: the exact saved version of the code used to build the delivery.
Record those details beside the matching code-analysis run and test reports. Ask the vendor to explain any mismatch before you decide. NIST's Secure Software Development Framework covers retaining release files and their provenance, meaning information about their origin. Our recommendation is to keep that link visible in the handover record.
2. What was included, and what was left out?
Ask which parts of the application were analysed and tested. Include supporting services and vendor-developed integrations in the discussion. Record exclusions and anything the tool could not analyse.
The report should name the code covered, tests performed and exclusions. A summary for one component should not stand in for the entire delivery. Source review, automated code analysis and tests of the running application cover different ground. Our source code review versus penetration testing guide explains that split.
3. What does the green result mean?
A quality gate is a set of configured checks that produces a pass or fail result. Ask which checks applied and whether they covered the existing application, new changes, or both.
Keep the gate rules and configuration with the result. SonarQube pull-request analysis reports issues on new code; a pull request is a proposed code change. Its green result does not establish that the whole application has no outstanding issues. For an initial handover, request results covering the delivered application as well as checks on individual changes.
4. What is still unresolved?
Ask for open findings, their assessed impact, the person responsible and the planned action. Keep disputed findings visible, with the reason for the decision.
Show whether each finding is fixed, awaiting work or awaiting a decision. NIST recommends recording and triaging discovered issues: deciding their priority and treatment. A count alone leaves those decisions unexplained. Use your bank's release criteria to decide what must be resolved before acceptance.
5. Who reviewed the code and approved the release?
Ask who reviewed the code and when. Get their decision in writing. Separately identify the person authorised under your bank's process to approve the release.
The review record should identify what was examined, including relevant test results, and how unresolved findings affected the decision. An automated analysis is one input; NIST distinguishes tools analysing code from people reviewing it.
Bank Negara Malaysia's Risk Management in Technology policy (RMiT) requires adequate source-code review for changes to critical systems. It addresses independent review and approval of system changes separately.
6. Can we retrieve the evidence later?
Agree where the release record will be kept, who can access it and how long it must remain available under your bank's requirements.
Save the reports with the delivery record when you make the acceptance decision. SonarQube Enterprise's regulatory report describes the latest analysis of the selected branch, a line of development in the code repository. Downloading it months later may describe newer software. Export the relevant result at handover and record the source revision alongside it.
Also check retention settings. SonarQube housekeeping removes some historical analyses and branches. A live dashboard should not be your only archive.
7. Who owns the next fix and the next release?
Before sign-off, write down the contact for defects, how fixes will be assessed and which evidence the vendor must supply with future changes.
For vendors developing or maintaining a Malaysian bank's critical systems, RMiT paragraph 10.12 requires contractual provisions addressing secure development and continued source-code availability. See our RMiT source-code review guide for the regulatory detail. This handover checklist does not replace that contract.
For Singapore teams, the Monetary Authority of Singapore's Technology Risk Management Guidelines discuss traceable testing and signed test reports. They also discuss agreeing quality measures during planning. They are guidance; the checklist here is our practical suggestion.
A sample response to return for clarification
This example is fictional.
Incomplete: The vendor delivers version 3.3 and sends a link to a currently green dashboard. It does not identify the analysed version, explain outstanding findings or name the reviewer.
More useful: The vendor identifies delivery 3.3 and its source revision, attaches the corresponding analysis and test results, lists unresolved findings with owners, and provides the review and approval records. It explains that today's dashboard shows version 3.4 and files the earlier evidence separately.
Check those records against your acceptance criteria, including the functional, performance and recovery tests required for this delivery.
Where SonarQube helps
SonarQube can provide repeatable code-analysis results and quality-gate checks. For SonarQube Server, the relevant edition choices are:
- Developer or above: checks on proposed code changes and branches, the separate lines of development.
- Enterprise or above: regulatory reports and audit logs, which record activity in the system.
Check the features you need before choosing an edition. Automated analysis contributes evidence; your bank still needs to assess the delivery.
Our SonarQube editions guide covers that choice. If AI agents contribute code, read who reviews AI-generated code for the human responsibilities around automated checks.
Frequently asked questions
Is a green SonarQube result enough to accept vendor software?
No. It shows that the analysed code passed the configured gate conditions. Check the version, scope, unresolved findings, other test results and approval against your bank's acceptance criteria.
Should we ask for the vendor's latest report?
Ask for the report that matches the delivered release. A later report may cover newer code. Keep the relevant report with the release and source revision.
Does every SonarQube edition include regulatory reports?
No. SonarQube Server regulatory reports are available from Enterprise. Check the features needed for your handover before choosing an edition.
How long should we keep handover evidence?
Follow your bank's retention requirements and agreed contract. Set the archive location and access rules before acceptance; do not rely only on a dashboard whose history may be removed.
Can Anchor Sprint help set up the code checks?
Yes. We supply SonarQube licences and offer setup and developer training in Malaysia and Singapore. Ask us to scope that work around your applications and development process.
Make the next handover easier to assess
If your team needs repeatable checks, tell us your application languages, how software is built and which reports your reviewers need. We can quote SonarQube licences, setup and developer training in RM or SGD. Start with SonarQube Malaysia or SonarQube Singapore.
Your local Sonar reseller partner
Buy SonarQube from a local partner, in Ringgit or SGD
Tell us which company is buying, whether this is a new order or renewal, and where you need help.
- RM quotes for Malaysia and SGD quotes for Singapore
- Setup help, quoted separately
- Developer training if your team needs it
Sources
Product features and Anchor Sprint's service scope checked on 17 October 2026. Confirm the scope of your licence and services on the quote.
- NIST Secure Software Development Framework v1.1: release records, review, testing and decision evidence.
- OWASP Web Security Testing Guide v4.2: the different coverage of review and application testing.
- SonarQube regulatory reports: reporting scope and edition availability.
- SonarQube housekeeping: history removal and retention considerations.
- BNM RMiT policy document: critical-system development and vendor responsibilities.
- MAS Technology Risk Management Guidelines: software testing and quality assurance guidance.
