Customer security questionnaires often arrive late in a sales cycle, with broad questions and short deadlines. Small SaaS teams can end up scrambling for screenshots, policy extracts and explanations that should have been prepared earlier.
The goal is not to create a glossy document that overstates your security posture. The goal is to prepare accurate evidence that shows what is already in place, what is being improved, and who owns the remaining risk.
1. Start with the questions buyers usually ask
Most customer questionnaires ask variations of the same themes:
- Who can access production?
- Is privileged access reviewed?
- Are logs collected and retained?
- Are backups performed and tested?
- Are vulnerabilities and patches managed?
- Is data encrypted?
- Are cloud security alerts monitored?
- Is there an incident response process?
Before collecting evidence, map these themes to the AWS controls and operational processes you actually use.
Our AWS security review checklist is a useful place to start.
2. Keep the evidence tied to claims
Every evidence item should support a specific claim. If you say CloudTrail is enabled, keep evidence showing the trail configuration, coverage, log destination and retention. If you say backups are tested, keep evidence of restore checks, not just backup schedules.
This avoids a common problem: collecting lots of screenshots that look impressive but do not answer the customer’s question.
3. Prepare IAM and access evidence
Access control is usually high on the customer’s list. Evidence should prove the control exists without exposing secrets, full user lists or implementation details that do not need to leave the business.
It is acceptable and expected to redact (blur or black out) sensitive details like exact IP addresses or specific usernames from screenshots.
Useful evidence includes:
- SSO or identity-provider configuration;
- MFA requirements;
- administrative role list;
- access review notes;
- joiner, mover and leaver process notes;
- examples of role-based access rather than shared users.
4. Prepare logging and monitoring evidence
For AWS environments, customers may ask about CloudTrail, GuardDuty, Security Hub, AWS Config, alert routing and incident triage. Useful evidence should show that logging and detection are operational, not merely enabled. If findings go to a mailbox nobody reads, that is weak evidence. If findings are routed to a ticket queue, chat channel or managed process with ownership, that is stronger.
Useful evidence includes:
- CloudTrail configuration showing multi-region and global events enabled;
- log retention policies or lifecycle rules;
- screenshots of alert routing (e.g., EventBridge rules sending alerts to a Slack channel or Jira);
- a sample of an anonymised, resolved security ticket.
Redact hostnames, account IDs, user identifiers, IP addresses and any customer data before sharing this evidence externally.
5. Prepare backup and recovery evidence
Backup claims are easy to overstate. Customers increasingly ask whether restores are tested and whether recovery objectives are defined. If restore testing is not mature yet, say so and provide the improvement plan.
Useful evidence includes:
- backup policy settings (e.g., AWS Backup plans);
- database or block storage snapshot configuration;
- restore test notes or tickets demonstrating a successful test;
- retention settings and documentation on who owns recovery actions.
Do not share raw backup contents or recovery logs that expose sensitive system, customer or credential details. The evidence should show that the control works, not disclose the environment.
6. Separate completed controls from planned improvements
Do not blur the line between “implemented”, “partially implemented” and “planned”. Enterprise customers can usually tell when an answer is padded.
A stronger response is:
This control is implemented for production AWS accounts. Non-production account coverage is being added as part of the next security uplift, due by a specific date.
That is more credible than claiming everything is complete when the evidence says otherwise.
7. Maintain a reusable evidence pack
After the first questionnaire, keep a reusable evidence pack. It should include approved wording, current screenshots or exports, dates, owners and notes about what can be shared externally.
For more detail on what to include, see our guide on what to collect before an AWS security review.
Review it quarterly or whenever important AWS controls change. Out-of-date evidence creates its own risk, especially if sales teams keep reusing old answers.
What good evidence looks like
Good evidence is accurate, current and scoped. It helps customers understand your security posture without forcing your team to reveal unnecessary detail. It also helps internal leadership see where investment is still needed.
The best outcome is a calmer sales process: fewer last-minute escalations, fewer vague answers and a clearer path from customer pressure into practical remediation.