Evidence before eloquence: why cited answers matter more than polished ones
There's a temptation in security questionnaire responses to optimize for how an answer reads rather than whether it's true. A confident paragraph about encryption sounds professional. But if nobody on your team can point to the control, policy, or report that backs it up, you've just made a promise.
The examples below are hypothetical and labeled as such. They are not a customer case study, and they are not output from a finished Sorila product. They show the judgment we want the product to support.
A worked hypothetical
Hypothetical question
“Is all customer data encrypted at rest?”
Questions like this appear in buyer-built spreadsheets and in standardized instruments such as the Cloud Security Alliance’s Consensus Assessments Initiative Questionnaire (CAIQ), which maps to Cryptography, Encryption, and Key Management controls in the Cloud Controls Matrix.
Weak answer
“Yes, all customer data is encrypted using industry-standard encryption.”
Problems: “all” is absolute, “industry-standard” is undefined, and there is no citation. A buyer cannot verify scope (which systems?), algorithm (which cipher?), or ownership (who manages keys?).
Safer cited answer
“Production database storage is encrypted at rest using AES-256. See Data Security Policy v2.3, §4.1. File-upload object storage requires separate confirmation before we answer ‘all customer data.’”
Why this is safer: it names the system in scope, names a concrete algorithm defined in NIST FIPS 197 (AES), cites a specific policy section, and refuses to overclaim where evidence is incomplete.
Encryption at rest is also a common expectation under SOC 2 logical-access criteria. The AICPA Trust Services Criteria for CC6.1 include a point of focus that the entity uses encryption to protect data at rest when appropriate based on assessed risk, and that encryption keys are protected through their lifecycle. (AICPA 2017 Trust Services Criteria, CC6.1)
Where contradictions actually come from
In practice, the hard part is rarely writing a sentence. It is noticing that your sources do not say the same thing. A typical scramble looks like this:
- Internal policy: “Customer data at rest is encrypted with AES-256.” (Often written aspirationally, or only for production databases.)
- SOC 2 report: Describes encryption for systems in scope during the audit period. A report may support database encryption while saying nothing about a newer file-upload bucket added after the period ended.
- Last year’s questionnaire: Answered “Yes” to “all customer data” when the product still stored uploads on ephemeral disks, or before a region was added.
Copying the old “Yes” into this year’s sheet creates three failures at once: it contradicts the narrower SOC 2 scope, it overstates the policy, and it creates a commitment the engineering team may not be able to defend in a follow-up diligence call.
A safer process treats those three artifacts as inputs to reconcile, not as interchangeable sources of truth. When they conflict, the honest answer is scoped, cited, and flagged for human review.
What a good answer looks like
A strong security questionnaire answer usually has three parts:
- A clear, scoped response to the question (what is true, and for which systems)
- A citation to supporting evidence: policy section, SOC 2 criteria coverage, architecture note
- An explicit flag when evidence is missing, stale, out of scope, or contradictory
Why this matters more as drafting gets easier
Fluent draft text is getting cheaper. That raises the risk of polished-but-unsupported answers, especially when buyers also ask about AI systems and data use. NIST’s AI Risk Management Framework Generative AI Profile (NIST AI 600-1) explicitly recommends updating due diligence and procurement vendor assessments for generative AI to cover privacy, security, intellectual property, and related risks. Better questions from buyers make vague answers more dangerous, not less.
Human review is not optional. Any assisted drafting workflow should make uncertainty visible instead of hiding it behind confident language.
How Sorila is designed to treat this
Sorila is under active development. “Evidence before eloquence” is a product principle, not a claim about finished production performance.
The product is designed to help teams draft scoped answers, attach citations, and surface missing or conflicting evidence before a human approves what goes back to the buyer. See how that fits into Sorila's security questionnaire software at launch.
Join the design partner program if you want to help shape that review workflow with real questionnaires.
Sources
- Cloud Security Alliance, Cloud Controls Matrix and CAIQ
- NIST, FIPS 197, Advanced Encryption Standard (AES)
- AICPA & CIMA, 2017 Trust Services Criteria (with revised points of focus, 2022)
- NIST, AI 600-1, Generative AI Profile