Answer with specifics: what you test, how often, in which environment, as which accounts, using which methods, and what is not covered. Offer evidence you can share. Avoid absolutes like fully tested or secure, which no scan can support, and never describe a plan as something already done.
What the asker wants to know
A buyer's security team reading this question is trying to learn four things. Do you test at all? Is it routine or one-off? Does it cover authorization, which is where API breaches tend to come from? And will you be straight about limits? The OWASP 2023 API list puts broken object level authorization first, broken authentication second, and property and function level authorization after that, so a good answer shows you test those, not only injection and headers.
A template you can fill in
Copy this and replace each bracket with a fact that is true today.
"We test our APIs [on every release / monthly / quarterly] in a [seeded test environment / staging]. Testing uses [two ordinary accounts and N role accounts] to check object level and function level access. Automated scans run in [passive / active] mode, and [manual testing / an external penetration test] covers business logic [frequency, or 'is planned for DATE']. Findings are tracked in [system] with owners and retest dates. We do not currently test [list gaps, for example WebSocket messages or partner-only versions]. We can share [a summary of scope and results] under NDA."
Every bracket is a place where a vague answer would raise a question. Filling it with a fact removes the question.
Wording to use and avoid
| Prefer | Avoid |
|---|---|
| "Automated scans run on each release" | "Our APIs are fully tested" |
| "Two-account checks for object access" | "We test the OWASP Top 10" with nothing behind it |
| "Penetration test planned for Q1" | "Penetration tested" when it is only planned |
| "We maintain an inventory of API hosts and versions" | "We have no shadow APIs" |
| "Findings are retested after fixes" | "No vulnerabilities" |
Do not state a certification or attestation unless you hold it. If an audit is underway, say that it is underway.
Backing it up
Have these ready, redacted:
- A one-page test summary with scope, date, accounts, mode and findings counts.
- The inventory fields: hosts, versions, environments and access level.
- The ticket trail showing a finding, a fix and a retest.
The OWASP inventory guidance is a good model for the first two: it lists environment, who can reach each host, API version, authentication, rate limiting and CORS policy among the details to track.
When the honest answer is "not yet"
Say so, and give the plan with dates you will keep: "We do not yet test authorization with role accounts. We will add it by [date], starting with the billing API." Buyers generally respond better to a dated plan than to a claim that falls apart in a follow-up call.
Keep the answers consistent
If sales, support and engineering each answer in different words, someone will notice. Keep one approved paragraph in a shared file, with the date it was last verified, and update it when practice changes.
Worked example: three teams, three honest answers
Here are three imaginary companies answering the same question. Each answer is true for that company and specific enough to check.
Company A: a five person startup with automated scans only.
"We run an automated API scan on every release in a staging environment seeded with synthetic data. The scan logs in as two ordinary users and one admin and checks object and function level access. We do not yet include manual testing of business logic or an external penetration test. We plan to add a manual review in the first quarter of next year and will update this answer when it is done. We can share a redacted summary of the latest scan on request."
Why it works: it states the method, the accounts, the environment and the gap, and gives a dated plan.
Company B: a mid-size SaaS with a mixed program.
"API testing is part of our release process. Automated scans run nightly against staging as three roles in two tenants. Each quarter an engineer performs a manual review of authorization and usage limits on new endpoints. An external penetration test of the API was completed in the spring, and the report is available under NDA as a summary. Findings are tracked in our ticket system with owners and retest dates. We do not currently test WebSocket messages and have that on our roadmap."
Why it works: it separates what is automated from what is manual and from what is external, and names a gap.
Company C: a company still building the process.
"We review API changes in code review and run dependency checks in CI. We have not yet performed dedicated API security testing against a running environment. We have scoped a first test for next month, covering authentication, object access and rate limits, and will share a summary when it is complete."
Why it works: it does not pretend. A buyer who reads this can decide whether the risk is acceptable and may ask for compensating details.
What the three have in common
| Element | A | B | C |
|---|---|---|---|
| Says what is done today | Yes | Yes | Yes |
| States environment or scope | Yes | Yes | Partly |
| Names accounts or roles | Yes | Yes | No |
| Names a gap | Yes | Yes | Yes |
| Offers evidence | Redacted summary | Summary under NDA | After first test |
| Uses absolutes | No | No | No |
None of them says "fully tested", "no vulnerabilities" or implies a certification. Each can be defended in a follow-up call, which is the standard to hold every answer to.
Checking your own draft
Read your answer aloud and underline every claim. For each underlined claim, ask whether you could show something to support it by Friday. If you cannot, soften the claim or turn it into a plan with a date. Then ask a colleague outside security to read it. If they cannot tell what is covered and what is not, rewrite it.
Keeping answers current
Review the shared answer after each test and after each change in process. Put the date of the last review on it. An answer that was true last year and is now stale is a bigger problem than a modest one that is current.
Try it yourself
Open the demo and look at how controls and evidence are connected. Think about which evidence you would attach to each claim in your own answer.
Click through it at your own pace, or open it full screen.
Quick check
Can I say we follow OWASP?
Say what you actually do, for example that you test against the OWASP API risk categories using two-account checks. A bare claim of following a list invites follow-up questions you may not want to answer.
What if our testing is only automated?
Say so. State that business logic is not covered by automation, and add what you do about it, or when you plan to.
Can we reuse one answer for every customer?
You can keep one approved base answer and adapt the detail. Never change the facts between customers. If a customer asks about something you do not do, say so and give the plan.
Sources
Last reviewed: 19 October 2026.
