In a regulated company, check four approvals before a security tool trial: data handling, vendor risk intake, access and legal terms. Exact requirements depend on your own policies and regulators, so ask your risk and legal teams. Start the requests early, because approvals often take longer than the trial.
This post is operational guidance, not legal advice.
Why trials need approval at all
A trial can look informal, but it often sends code, metadata or credentials to a third party. Many organisations treat that as a normal vendor engagement, even without a purchase. Skipping the process can create findings in your next audit and, worse, delay the real purchase when the process catches up.
The four approvals
1. Data handling
Decide what data the trial may touch.
- Source code, or only dependency manifests and SBOMs?
- Production data? Almost certainly not.
- Where is it processed, and in which region?
- How long is it kept and how is it deleted?
One way to reduce the review is to scope the trial to non sensitive repositories, or to metadata only. Record the decision.
2. Vendor risk intake
Most regulated organisations have a process for onboarding any third party. Ask whether a trial counts and whether there is a lighter path for evaluations. Prepare the usual items: the vendor's security documentation, data flow description and any attestations they offer. Read them carefully, as described in how to read a vendor SOC 2 report, and never assume an attestation says more than it does.
3. Access
List every credential and grant the trial needs and request the narrowest versions. See least privilege access for a scanner pilot. Record who approved each one and when it will be revoked.
4. Legal terms
Ask whether an agreement is needed, even a short one. Common items include confidentiality, data use limits, deletion obligations and the status of any trial output. See a mutual NDA for a tool evaluation and what to put in a pilot agreement. Your legal team decides the wording.
A request pack
Send one package so reviewers are not chasing answers.
| Item | Contents |
|---|---|
| Purpose | What decision the trial supports |
| Scope | Repositories, systems, people, dates |
| Data | Categories, location, retention |
| Access | Grants, scopes, expiry |
| Vendor documents | Security and privacy documentation |
| Exit plan | Revocation and deletion steps |
Timeline
Put approvals on the calendar as the first task. A reasonable plan is to submit the request pack two to four weeks before the planned start, though your own process may be faster or slower. Ask reviewers how long they usually take and plan around their answer.
Things not to do
- Do not start with a personal account or a company card to avoid process.
- Do not upload real customer data to see how the tool copes.
- Do not let a vendor push you to start before your reviews finish.
- Do not describe the trial as approved in front of the vendor until it is.
Build the audit trail
Keep the approvals, scope, evidence log and close out record together. An auditor or examiner may ask later how you evaluated a tool and what you did with the data. See what to do with your data when the trial ends.
Safeguard's free scan can be a useful first step for teams that want to see output on a non sensitive project while approvals for a deeper trial proceed.
Quick check
Does a free trial need vendor risk review?
Often yes, if it touches code or credentials. Ask your risk team whether an evaluation path exists.
Can I trial on a public repository to avoid approvals?
It can reduce data concerns, but you still need to check your policies, and a public repository may not represent your real code.
Last reviewed: 19 October 2026.
