You're reviewing a vendor's security questionnaire. They've answered "Yes" to encryption in transit. You check the box and move on. Then 157 gigabytes of factory schematics, badge request forms, and passport scans end up on a public server because someone left an rsync instance wide open.
The decision you're facing isn't whether to care about data-handling utilities. It's how deeply you audit the configuration of file-transfer protocols your vendors use to move your sensitive data. This guide walks you through the choice between three audit depths: self-attestation, configuration review, and live verification.
Key Factors That Affect Your Choice
Four variables determine which path fits your arrangement:
Data sensitivity. Factory floor plans, VPN access forms, and employee PII demand different scrutiny than marketing collateral. If exposure would enable facility access, sabotage, or identity theft, you're in high-sensitivity territory.
Vendor technical maturity. A vendor with mature change management and secure deployment processes earns more trust than a small integrator running ad-hoc backup scripts. Ask: do they have standardized deployment checklists for utilities like rsync, SFTP, or S3 buckets?
Criticality classification. ISO 27036 and SR 23-4 both tie oversight intensity to vendor criticality. If the vendor supports a critical or important function, you need evidence, not assertions.
Your contractual leverage. Can you require configuration audits as a condition of the arrangement? If your Right to Right to Audit allows technical reviews, use it. If not, you're limited to self-attestation and indirect signals.
Path A: Accept Self-Attestation
Choose this when:
- The vendor handles only low-sensitivity data (public marketing assets, anonymized analytics)
- You lack contractual audit rights and the vendor refuses configuration disclosure
- The vendor demonstrates mature security practices elsewhere (SOC 2 Type II, ISO 27001 certification, documented change control)
- The data set is small and easily replaceable
What you require:
- Written confirmation that file-transfer utilities restrict access by IP and require authentication
- Evidence of secure configuration baselines (link to their internal standards or deployment runbooks)
- Confirmation that the utility is included in their vulnerability scanning and patch management scope
The risk you accept: Self-attestation doesn't catch misconfigurations. The Level One Robotics exposure was discovered on July 1st, 2018 and secured by July 10th, 2018 after external notification. The vendor likely believed their setup was secure. You're trusting process over proof.
Mitigating controls:
- Add the vendor to your Continuous Monitoring of Active Arrangements program with external attack surface scanning
- Require Incident Escalation procedures that include a 24-hour Notification Timeline for data exposures
- Schedule annual re-attestation tied to contract renewal
Path B: Require Configuration Review
Choose this when:
- The vendor handles moderate-to-high sensitivity data (customer records, proprietary schematics, employee PII)
- You have contractual audit rights or the vendor agrees to transparency as a competitive differentiator
- The vendor's security maturity is unproven (startup, recent security incidents, no third-party certifications)
- You're onboarding the vendor and can set expectations during Pre-Contractual Assessment
What you require:
- Screenshots or configuration exports showing IP restrictions, authentication requirements, and access logging for all file-transfer utilities (rsync, SFTP, cloud storage)
- Documentation of who has administrative access to these utilities and how that access is reviewed
- Evidence that the configuration is version-controlled and subject to change approval
- Confirmation that default or "convenience" settings (no password, public read/write) are explicitly prohibited in deployment standards
The verification process: During Vendor Intake or annual review, request a configuration walkthrough. Don't accept "it's secure", ask to see the rsync.conf file, the S3 bucket policy, or the SFTP user table. Compare what you see against your own secure configuration checklist.
When to escalate to Path C: If the vendor resists, claims configurations are proprietary, or provides incomplete documentation, move to live verification or reconsider the arrangement.
Path C: Perform Live Verification
Choose this when:
- The vendor handles critical data whose exposure would create material operational or reputational risk (facility access credentials, trade secrets, financial account details)
- The vendor has demonstrated configuration drift or past security lapses
- Regulatory expectations demand evidence-based assurance (EBA Outsourcing Guidelines for financial institutions, CSRD Reporting for supply chain due diligence)
- You're managing Fourth and Nth Party Management risk and the vendor's sub-processors also transfer your data
What you require:
- A scheduled technical audit where your team (or a third-party assessor) connects to a test instance or reviews live configurations in a controlled environment
- Penetration testing or vulnerability assessment that includes file-transfer utilities in scope
- Real-time demonstration that unauthorized clients cannot access the data set
- Log review showing access attempts, authentication events, and configuration changes over the past 90 days
The trade-off: Live verification is resource-intensive. Reserve it for your top-tier vendors or those with prior incidents. For scale, consider automated attack surface monitoring tools that continuously probe for exposed rsync, FTP, or misconfigured cloud storage.
Contractual foundation: Your Right to Right to Audit must explicitly permit technical configuration reviews, not just policy and process audits. If the vendor balks, add it during contract negotiation or renewal.
Summary Matrix
| Audit Depth | Best For | Evidence Required | Risk Level |
|---|---|---|---|
| Self-Attestation | Low-sensitivity data, mature vendors, limited leverage | Written confirmation, baseline references | Accept configuration unknowns |
| Configuration Review | Moderate-to-high sensitivity, contractual rights, unproven maturity | Config exports, access lists, change logs | Verify settings, trust implementation |
| Live Verification | Critical data, regulatory requirements, past incidents | Technical audit, pen test, log review | Demand proof under realistic conditions |
The Principle Behind the Choice
The Level One incident wasn't caused by a zero-day exploit or a sophisticated attack. It was an rsync server configured without IP restrictions or authentication requirements. The exposure included passport scans, badge request forms for Boeing, and non-disclosure agreements that explicitly outlined confidentiality expectations.
Your decision tree starts with a simple question: if this vendor misconfigures a file-transfer utility, what's exposed? If the answer includes anything that enables facility access, competitive harm, or identity theft, self-attestation isn't enough.
Don't let "encryption in transit" on a questionnaire substitute for knowing whether the transit endpoint is locked down. Configuration is where policy meets reality. Audit accordingly.
