Cybersecurity

API Security RFP Template (Free): Requirements and Scoring

Paste-ready API security requirements (discovery of shadow and zombie APIs, posture, runtime protection, CI/CD testing), vendor questions that separate products, and a weighted scoring rubric.

14 pages Microsoft Word ★ 4 of 5 13318 downloads Updated October 9, 2026
Download Template
API Security Solutions RFP Template

Preview the first pages

See the structure before you download. The Word file has every section listed below, ready to fill in.

Open preview Give feedback

What's inside

The sections in the document, in order.

  1. How to run an API Security RFP
  2. API Security RFP requirements
  3. Questions to ask API Security vendors
  4. Scoring rubric
  5. Frequently asked questions
  6. Related RFP templates

Use this API security RFP template when you need a platform that finds every API you expose, including undocumented shadow APIs and forgotten zombie APIs, assesses their security posture, detects and blocks attacks at runtime, and tests APIs for flaws before they ship.

API security is now sold both as standalone platforms and as modules of web application and API protection (WAAP), cloud-native application protection (CNAPP) and API management products, so the requirements are written to compare all of them on the same terms.

It's written for the application security, security operations and platform engineering team running the evaluation, and it covers the whole process: when to issue an RFI first, the requirements to send, the questions that separate vendors, and how to score the answers.

What’s inside this template

  • A step-by-step plan for running the evaluation, with an example schedule and advice on when an API security RFI should come first
  • Requirements for API discovery and inventory, posture management, runtime detection and blocking, and API security testing in CI/CD, each marked Must-have or Nice-to-have
  • Coverage of the OWASP API Security Top 10, with particular attention to authorization flaws such as broken object level authorization (BOLA)
  • Questions that test how complete a vendor's API inventory really is, what happens to your payload data, and which features are still on the roadmap
  • A weighted scoring rubric with 1-to-5 definitions
  • An editable Word RFP with response codes, a pricing table and a timeline

Download the editable Microsoft Word version below. Every requirement, vendor question and scoring weight on this page is in the document, ready to tailor and send.

How to run an API Security RFP

An API security evaluation involves application security, security operations, platform engineering and the teams that build and own APIs, and every shortlisted product will need to see some of your API traffic, code or cloud configuration. Agree on scope and data handling before vendors get involved. The example schedule in this template runs about 12 weeks from kickoff to contract award; allow more if the proof of value covers several clouds, gateways or business units.

  1. Map where your APIs live and how traffic reaches them (weeks 1-2). List your API gateways, load balancers, ingress controllers, service meshes, CDN and WAF, the cloud accounts and Kubernetes clusters that host APIs, and the code repositories and CI/CD pipelines that build them. Note which APIs are public, partner-facing or internal, and which handle personal or payment data. Record the numbers vendors will price against, such as known APIs, monthly API calls and environments, and tell vendors you expect discovery to find APIs that aren't on your list.
  2. Assemble the buying team. Include application security, security operations, platform or DevOps engineering, API owners and architects, and whoever runs your gateway and WAF, plus procurement and legal. Bring in privacy early: API security products inspect request and response payloads that can contain personal and payment data, so decide what may leave your environment and where it may be stored before any vendor connects to live traffic.
  3. Decide whether you need an RFI (weeks 2-4). Products in this category start from different places: some began with traffic-based discovery and runtime detection, some with API security testing, and others are modules of WAAP, CNAPP or API management platforms. If you're unsure which approach fits, whether testing belongs in the same purchase, or your long list has more than five vendors, issue a short RFI first. Ask how each vendor collects traffic, which of your gateways and platforms it supports, where payload data is processed, and how it prices.
  4. Tailor and issue the RFP (weeks 4-7). Delete requirements that don't apply, adjust priorities, and add your environment details and traffic sources to Section 1. Give vendors three weeks to respond, with a written question-and-answer window in the first week.
  5. Score the responses (weeks 7-8). Have each evaluator score independently against the rubric before comparing notes, and set aside any vendor that misses a Must-have. Check every 'yes' for whether it needs a separate module, a specific traffic source or a feature still in preview.
  6. Run a proof of value with two or three vendors (weeks 8-11). Connect each shortlisted product read-only to the same traffic sources, repositories and a pre-production environment. Compare the inventories side by side: how many APIs and endpoints each one found, how many you didn't know about, and how accurate the sensitive-data and authentication labels are. In a test environment, have one test user request another test user's records and see which products detect it, how quickly, and how clearly the alert explains it. Call references of a similar size.
  7. Negotiate and award (weeks 11-12). Pin down the license metric and what happens when discovery finds more APIs or traffic than you estimated. Settle renewal caps, add-on pricing, data deletion and exit assistance before you sign, not after.

API Security RFP requirements

Each line is written to paste straight into your RFP. Must-have means a vendor that cannot meet it is out; Nice-to-have earns extra points. Change the priorities to fit your situation, and delete what doesn't apply.

Functional

ID Requirement Priority
F1 Continuous discovery of APIs and endpoints from live traffic, building an inventory that records each endpoint's host, path, method, parameters, authentication method, and whether it is internet-facing, partner-facing or internal. Must-have
F2 Identification of shadow APIs (live but undocumented or unmanaged) and zombie APIs (deprecated or old versions still receiving traffic), showing the evidence used to classify each one and when it was last called. Must-have
F3 Import of API specifications in OpenAPI 3.x and 2.0 (Swagger) format, comparison against observed traffic, and alerts for drift: endpoints, parameters or response fields that don't match the specification. Must-have
F4 Generation of an OpenAPI specification from observed traffic for APIs that don't have one, for review by the owning team. Nice-to-have
F5 Discovery of APIs defined in source code and specification files in our repositories, so new APIs appear in the inventory before they are deployed. Nice-to-have
F6 Classification of sensitive data in API requests and responses, including personal data, payment card data, credentials and tokens, with support for custom data types we define. Must-have
F7 Posture assessment for each API that flags unauthenticated endpoints, weak authentication (such as API keys in query strings or tokens without expiry), sensitive data in URLs, responses returning more data than the client needs, verbose error messages and weak TLS settings, with a risk score that reflects exposure and data sensitivity. Must-have
F8 Findings mapped to the OWASP API Security Top 10 (currently the 2023 edition), including broken object level authorization (BOLA), broken authentication, broken object property level authorization and broken function level authorization, with reports we can use as audit evidence. Must-have
F9 Runtime detection of attacks and abuse against our APIs, based on a learned baseline of normal behavior for each API: attempts to access other users' objects (BOLA), credential stuffing and account takeover, enumeration and data scraping, injection attempts and unusual data volumes in responses. Must-have
F10 Correlation of related requests into one incident by user identity, token, API key, IP address or client, so an analyst sees the full sequence of an attack rather than isolated alerts. Must-have
F11 Configurable response per policy: alert only, or block or rate-limit the offending user, token, API key or IP address through our gateway, WAF or CDN, or inline. State which actions require an inline deployment. Must-have
F12 Detection of abuse of sensitive business flows (OWASP API6), such as automated buying, account creation or reservation hoarding, that tells automated clients apart from normal users. Nice-to-have
F13 API security testing that generates test cases from our OpenAPI specifications and observed traffic, covering authentication, authorization (including BOLA and function-level tests run with two or more test identities), injection, mass assignment and resource-consumption flaws. Must-have
F14 Authenticated testing with our authentication schemes (OAuth 2.0 flows, JWT bearer tokens and API keys), with test credentials stored securely and safeguards that stop destructive test cases running against environments we mark as production. State support for mutual TLS. Must-have
F15 Remediation guidance for each finding, showing the affected endpoint, a masked example request and response, and how to fix it, plus the option to accept or suppress a finding with a recorded reason and an expiry date. Must-have
F16 Security checks on API specifications in repositories and pull requests, flagging issues such as missing security schemes, undefined input limits and unbounded arrays before code is merged. Nice-to-have
F17 Discovery of calls our applications make to generative AI and LLM APIs, and of Model Context Protocol (MCP) servers in our environment, with the tools and data each one exposes. Nice-to-have

Technical and architecture

ID Requirement Priority
T1 Traffic collection without changes to application code, from sources such as API gateways, load balancers, ingress controllers, service meshes, CDNs, cloud traffic mirroring and Kubernetes node sensors. List the sources supported for our environment [list gateways, clouds and platforms]. Must-have
T2 Analysis that adds no latency to API calls, either out of band (on a copy of traffic or logs) or within a component already in our traffic path, such as our gateway or CDN. If any proposed feature needs a new inline component, state the latency it adds and whether its failure behavior (fail-open or fail-closed) is configurable. Must-have
T3 Support for REST and GraphQL APIs, including GraphQL-specific checks such as introspection left enabled and missing limits on query depth and complexity. State the level of support (discovery, posture, runtime detection, testing) for gRPC, SOAP, WebSocket and event-driven APIs. Must-have
T4 Coverage of APIs in each of our hosting environments [list: data centers, cloud providers and regions, Kubernetes, serverless], with one inventory across all of them. State any environment where only partial coverage is possible. Must-have
T5 One console and one inventory across discovery, posture, runtime detection and testing, so each endpoint's findings, alerts and test results appear in one place. Identify any capability that uses a separate console or product. Must-have
T6 A hybrid option in which payloads are analyzed by components hosted in our environment and only metadata is sent to the vendor's cloud. State which features are unavailable in that mode. Make this Must-have if payload data may not leave your environment. Nice-to-have
T7 Choice of the region where our data is processed and stored, to meet data-residency requirements. Must-have
T8 Published sizing and resource needs for any sensors or collectors we host, central health monitoring with alerts when a traffic source stops reporting, and upgrades we can schedule and stage. Must-have
T9 A fully self-hosted deployment, on premises or in our own cloud account, for environments that cannot use a SaaS service. Nice-to-have

Integration

ID Requirement Priority
I1 Single sign-on to the console via SAML 2.0 or OIDC, with user and group provisioning via SCIM. Must-have
I2 Integration with our API gateways, WAF or WAAP and CDN [list products] to collect traffic and to push blocking or rate-limiting rules. State, for each product, whether the integration supports collection, enforcement or both. Must-have
I3 CI/CD integration with [list pipelines] that runs API security tests and specification checks on pull requests or builds, with severity thresholds that can fail a build and results shown to developers in the pipeline. Must-have
I4 Streaming of alerts, findings and administrator audit logs to our SIEM via syslog, API or cloud storage in a documented schema, plus a REST API covering the inventory, findings, alerts and policies. Must-have
I5 Ticket creation for findings in our ITSM and developer issue-tracking tools, routed to the team that owns the API. State whether ticket status syncs both ways, so a finding closes when its fix is verified and reopens if the problem returns. Must-have
I6 Exchange of inventory data with our CMDB, API catalog or developer portal, including import of ownership data so each API has a named owning team. Nice-to-have
I7 Triggering of SOAR playbooks from runtime detections, and an API call that blocks a user, token or API key so our playbooks can act during an incident. Nice-to-have

Security and compliance

ID Requirement Priority
S1 A current SOC 2 Type II report and ISO/IEC 27001 certification covering the proposed services, available under NDA. Must-have
S2 Masking of sensitive values in captured requests and responses before they are stored or shown in the console, with rules we can configure, and a written statement of which traffic data is sent to the vendor's cloud and how long it is kept. Must-have
S3 Isolation of our tenant's data, encryption in transit and at rest, and a documented key-management approach. State whether customer-managed keys are supported. Must-have
S4 Administrator access through SSO with MFA, role-based permissions that can limit a team to its own APIs and restrict who can see captured payloads, and an audit log of every configuration and policy change. Must-have
S5 Least-privilege access for every connector to our cloud accounts, gateways and repositories, with the permissions documented per connector and read-only access unless a feature we enable needs more. Must-have
S6 Configurable retention for the inventory, findings and captured traffic samples, deletion on request, and export of all our data at any time in a usable format. Must-have
S7 A data processing agreement, a current list of sub-processors, and a contractual commitment to notify us of security incidents affecting our data within a defined time. State the time. Must-have
S8 A published vulnerability disclosure process and committed timelines for fixing security flaws in sensors and collectors, with direct notice when a fix needs action on components we host. Must-have
S9 FedRAMP authorization at the required impact level, or equivalent regional certifications for public-sector use. Make this Must-have if you are a public-sector buyer. Nice-to-have

Implementation and support

ID Requirement Priority
M1 An onboarding plan covering connection of traffic sources, repositories and cloud accounts, review of the first inventory with our API owners, and assignment of owners to each API, with named roles and the effort expected from our side. Must-have
M2 A tuning phase in alert-only mode before any blocking is switched on, with vendor help to review detections, reduce false positives and agree the criteria for enabling blocking. Must-have
M3 Identification of who delivers the implementation (vendor, partner or both) and the named team's experience with environments like ours. Must-have
M4 A service-level agreement for availability of the service, with service credits. State how availability is measured and how problems with components we host are handled. Must-have
M5 24×7 support for critical issues, with response-time targets by severity. State your targets. Must-have
M6 Advance notice of changes to detections, test cases or sensors that affect alerts, blocking or performance, a public status page, and root-cause reports for incidents that affect us. Must-have
M7 Training for security analysts, platform engineers and developers, documentation, and a named customer success contact with periodic service reviews. Nice-to-have

Commercial and pricing

ID Requirement Priority
C1 Pricing broken down by module (discovery and posture, runtime protection, testing), metric (per API, per endpoint, per API call volume, per application or per environment) and term, showing list price, discount and net price. Must-have
C2 The terms that apply if discovery finds more APIs than we estimated or call volume grows, including whether overage is billed and how it is calculated. Must-have
C3 Prices for adding modules, environments or capacity mid-term, co-terminated with the main agreement. Must-have
C4 A cap on price increases at renewal. State the cap. Must-have
C5 A proof of value at no charge, in our environment, with the vendor's engineering support. Nice-to-have
C6 Exit terms covering export of the API inventory, generated specifications, findings and logs, deletion of our data, and transition assistance at the end of the contract. Must-have

Questions to ask API Security vendors

These questions are designed to separate vendors, not to collect brochure answers. Ask for evidence: a demo, a document or a reference.

  1. Which traffic sources would you use to build our API inventory [list gateways, clouds and Kubernetes clusters], and which of our APIs would you not see? How do you find APIs that bypass our gateways?
  2. In the proof of value, show how you classified each endpoint as documented, shadow or zombie. What evidence do you use, and how do you avoid counting the same endpoint many times when paths contain object IDs or version numbers?
  3. Show a broken object level authorization (BOLA) attempt being detected: one user requesting another user's records. How do you learn which objects belong to which user, how long the baseline takes to build, and what coverage does a newly released API get before then?
  4. Exactly which request and response data leaves our environment, in what form, and where is it stored? Show the masking configuration and an example of a stored, masked payload.
  5. Which detections and blocking actions work out of band, and which need an inline component? If inline, how much latency do you add, and what happens to our API traffic if your component fails?
  6. When you block an attacker, where is the block enforced (our gateway, WAF, CDN or your own component), how quickly does it take effect, and what stops it from locking out legitimate users or partners who share an IP address?
  7. Show a test run against our pre-production API that uses two test identities to check for BOLA and broken function level authorization, and the findings it produces.
  8. What safeguards stop your tests from changing or deleting data? Which test cases do you recommend never running against production, and how is that enforced?
  9. Show a GraphQL API in your inventory and the checks you run on it. For our gRPC, SOAP, WebSocket and event-driven APIs, which get discovery only, and which also get posture checks, runtime detection and testing?
  10. Which edition of the OWASP API Security Top 10 do you map to, and for each of the ten risks, can you detect it at runtime, find it through testing, or only flag it as a posture issue?
  11. Show an analyst investigating one runtime alert, from the first request to the attacker's full activity. How do you keep alert volume manageable, and what tuning did you do in the proof of value?
  12. How does a developer receive a finding: in the pull request, a ticket or your console? Show one finding from detection to verified fix, and how it closes automatically when the fix ships.
  13. Which capabilities in your proposal need a separate license or module: discovery from code, testing, inline blocking, business-flow abuse detection, or AI and MCP discovery?
  14. Which of your Y answers depend on a specific gateway, cloud, sensor version or a feature still in preview? Give general-availability dates for anything in preview, especially AI and MCP features.
  15. Provide a reference customer of similar size and architecture that uses your discovery and runtime protection in production. What did their first inventory find that they hadn't known about, and how long did tuning take before they enabled blocking?

Scoring rubric

Score each criterion from 1 to 5, multiply by its weight, and add the results. The weights below are a starting point; agree on your own before any proposals arrive so the scoring can't be bent around a favorite.

Criterion Weight What a strong response shows
Discovery and inventory 20% Finds APIs across all your traffic sources and code, labels shadow and zombie APIs with evidence, and keeps the inventory current and accurate in the proof of value.
Runtime detection and response 20% Detects the scripted BOLA test in the proof of value, groups related requests into one incident, and blocks through your existing gateway, WAF or CDN.
Posture management and testing 15% Findings mapped to the OWASP API Security Top 10, authorization tests run with multiple identities, and CI/CD results developers can act on.
Deployment and data handling 10% Traffic collection with no code changes and no added latency, payload masking before data leaves your environment, and a region you choose.
Integration and operations 10% Works with your gateways, WAF, SIEM, ticketing and pipelines; a usable API; and alert volume your team can handle after tuning.
Implementation and support 10% A credible onboarding and tuning plan, an experienced named team, and clear SLAs and support targets.
Commercials and total cost 15% A clear license metric, fair terms when discovery finds more than you expected, a renewal cap, and a three-year view of total cost.
Total 100%

Scoring scale

  • 5 Exceeds: meets every Must-have and most Nice-to-haves, shown in a demo or proof of concept, with a matching reference customer.
  • 4 Strong: meets every Must-have and some Nice-to-haves, with clear evidence.
  • 3 Adequate: meets most Must-haves; gaps have a credible workaround or a dated roadmap commitment.
  • 2 Weak: misses one or more Must-haves, or the answer is vague.
  • 1 Poor: does not meet the requirement, or no answer.

Frequently asked questions

What should an API security RFP include?

Your scope (the APIs, gateways, clouds, repositories and pipelines in play); requirements for discovery and inventory, posture management, runtime detection and response, and API security testing, marked Must-have or Nice-to-have; integration, security and data-handling requirements, including what payload data may leave your environment; support terms; a pricing table with a clear license metric; and the rubric you'll score with. This template includes all of them.

What is the difference between API security, a WAF and an API gateway?

An API gateway routes, authenticates and rate-limits traffic for the APIs placed behind it. A web application firewall (WAF), or a web application and API protection (WAAP) service, blocks known attack patterns at the edge. A dedicated API security platform adds an inventory of every API, including those that bypass the gateway, posture checks, behavior-based detection of authorization and business-logic abuse such as BOLA, and testing. Some WAAP and API management products now include API discovery and protection, so ask each vendor which of these it covers.

What are shadow and zombie APIs?

A shadow API is live but not documented or managed by the security or platform team, such as an endpoint a team deployed outside the gateway. A zombie API was meant to be retired, such as an old version, but still answers requests. Both are risky because no one is testing or monitoring them, and the OWASP API Security Top 10 lists this as improper inventory management (API9). Discovery from traffic and code is how an API security platform finds them, which is why this template makes discovery a Must-have.

Is API security bought as a standalone tool or as part of a platform?

Both. API security is sold as standalone platforms and as modules of WAAP, cloud-native application protection (CNAPP) and API management products. Whichever route you take, compare products against the same requirements: check which traffic sources and API types each one covers, whether it detects authorization abuse such as BOLA at runtime, and whether testing is included or sold separately.

How long does an API security RFP take?

The example schedule in this template runs about 12 weeks from kickoff to contract award, including three weeks for vendor responses and three to four weeks for a proof of value. Allow more time if privacy review of API payload data is new to your organization, or if traffic must be collected from several clouds and gateways.

Related RFP templates

Download Template

More cybersecurity templates