A code scanning tool needs access to your most sensitive asset, your source. Your RFP should ask exactly what the tool reads, where that data goes, how long it stays, and how you get out. Ask for written answers, then verify at least three of them in the trial.
Source code access
- Does the tool need read access to full repositories, or can it scan from a build step without storing source?
- What permissions does it request on our source control system? Provide the exact scopes.
- Can access be limited to chosen repositories, and can we revoke it instantly?
- Does any source code, snippet, or file path leave our network? If so, to which systems?
Compare the permission list in the vendor's answer with what the tool actually requests during installation. Mismatches are common, and they tell you how carefully the vendor documents things.
Storage and retention
- What do you store: source, dependency lists, findings, metadata? Break it down by type.
- How long is each type retained, and can we set the period?
- How do you delete our data when we ask, and how do we confirm it?
- Is customer data used to train or tune any model? If yes, can we opt out, and is the default opt in or opt out?
Question 8 matters more each year as vendors add AI features. Get the answer in the contract, not only in a questionnaire.
Deployment options
- Which deployment models exist: vendor hosted, hosted in our cloud account, self managed, or a hybrid where scanning runs locally and only results are sent?
- Which features are unavailable in each model?
- Can scanning run on a network with no outbound internet access, and how are vulnerability databases updated in that case?
Teams often discover late that the self managed edition lacks the feature that drew them to the product. Ask for a feature by deployment table.
Access control and audit
- Do you support single sign-on and role based access, and how granular are roles?
- Is there an audit log of who viewed or changed findings and policies, and can we export it?
- How are API keys scoped and rotated?
Incident and exit terms
- How and when would you notify us of a security incident affecting our data?
- What do we get on exit: findings history, SBOMs, policy configuration, in what formats?
- Which subprocessors do you use, and how do you tell us about changes?
How to verify
Pick three answers and test them. Install the tool in a sandbox organization, read the permission screen, and compare it with answer 2. Ask for the data deletion procedure and watch a deletion on a test project. Request the audit log export and open the file.
For AI features, ask for the vendor's written statement on training and retention, and have your legal team read it. Do not treat a marketing page as a contract term.
Scoring
Make data handling a pass or fail gate for the items you cannot compromise on, then score the rest. A vendor that offers a local scan mode or a self hosted option may deserve extra credit if your environment is restricted. See how to structure the RFP for where gates sit.
Safeguard offers a command line tool and IDE integrations in addition to the hosted platform, so ask any vendor, ours included, to document exactly what each surface sends.
Quick check
Can a scanner work without storing our source code?
Some can, by scanning in your pipeline and sending only findings or dependency data. Ask each vendor to document what leaves your network.
Should data handling be scored or pass or fail?
Use pass or fail for hard limits such as residency, then score the rest, so a strong demo cannot outweigh a deal breaker.
Last reviewed: 19 October 2026.
