FillTrust

How to answer

Do you have protection against denial-of-service attacks?

Almost always a yes you inherit from your cloud provider. The part that is actually yours is the application layer, and that is the part reviewers probe.

A model answerConfirmed in your documents

Yes. All inbound traffic terminates at our CDN and load balancer, which provide always-on volumetric and protocol attack mitigation, and application-layer rate limiting is enforced per client at the edge and in the application.

FillTrust grades an answer like this confirmed in your documents when your documents support it.

Answered from
Your architecture documentation, and whatever your cloud or CDN provider does at the edge. Most of this answer is a description of infrastructure you did not build.
Evidence to attach
Rarely anything. Occasionally an architecture diagram showing where traffic terminates.
Where it is asked
SIG LiteBespoke vendor questionnaires

For most SaaS companies this is one of the easier rows, because the hard part is bought rather than built. Traffic arrives through a CDN or a managed load balancer, and volumetric mitigation is switched on by default at that layer. Say so, and name what terminates the traffic.

Then answer the half your provider does not cover. Edge scrubbing deals with floods of packets. It does not deal with a small number of well-formed, authenticated requests that each cost you a database scan, a model call or a report generation. That kind of exhaustion looks like ordinary traffic to a CDN and is the failure mode most likely to actually take a small SaaS product down. The answer worth writing describes per-client rate limiting, timeouts and quotas on the expensive paths, not just the network layer.

Say how you would find out. Reviewers who care about this ask a second question: what happens when it starts. Alerting on error rate and latency, an on-call rotation, and a documented escalation to your provider's support is enough. What fails is an answer implying the protection is autonomous and nobody watches it.

Keep it consistent with the availability rows. This question usually sits near uptime commitments and business continuity. If you claim strong DDoS protection here and have no availability target three rows down, the file reads as assembled rather than considered.

If you have no dedicated protection, describe the layers you do have: managed hosting, autoscaling, rate limits, a WAF if you run one. That is a real answer. Inventing an anti-DDoS capability is a poor trade, because it is one of the few claims a customer may end up testing by accident.

How this one goes wrong

Specific to this question, not general advice.

  • Answering with your provider's name and stopping. Naming a CDN says traffic passes through one, not that mitigation is enabled, tuned, or covering the endpoints that matter.
  • Covering the website and forgetting the API. Volumetric attacks hit the front door; the expensive requests are usually authenticated API calls, and those need rate limiting rather than edge scrubbing.
  • Describing mitigation but not detection. The follow-up question is how you would know, and an answer with no alerting behind it does not survive it.

There are another two hundred of these in the file.

FillTrust drafts every one from your own documents and shows the passage behind each answer, including the ones it refuses to answer.

Or write this answer down once and publish it on a Trust Center of your own, which costs nothing.