This article outlines the Cequence-recommended sequence for rolling out Risk Posture, Discovery, and Remediation in the Cequence Unified API Protection (UAP) platform, release 9.1. It accompanies the Cequence UAP platform 9.1 Release and Upgrade Guide.

The Cequence UAP platform ships with more than 260 risk rules across roughly 25 categories, and it can ingest traffic from as many sources as you connect. That breadth is a strength once you tune it. Turned on all at once, on day one, it tends to produce more noise than signal: false positives from authentication types you have not finished configuring, drift findings on specs you have not kept current, and duplicate endpoints you have not parameterized yet.

This article lays out the order that works best for new and upgrading customers alike. It is not a one-time checklist. It is a loop you cycle through as your traffic, specs, and risk coverage mature. Think of it less as a list of steps to finish and more as a rhythm to settle into.

The playbook follows seven phases, summarized here and detailed in the sections that follow.

1. Start narrow: enable only the two default Security Posture rules.
2. Maximize discovery coverage across all traffic sources.
3. Calibrate what counts as a valid endpoint.
4. Build and maintain API definitions, or specs.
5. Expand risk coverage one category at a time.
6. Operationalize remediation through ticketing.
7. Keep inventory and issues tidy with Clear Risk.

Phase 1: Start narrow

Begin with only the two rules enabled by default in the Security Posture category: No Authentication Detected and Sensitive Data Exposure.

These two rules are foundational. Most other categories, including the OWASP API Top 10, depend on you configuring authentication types and sensitive data expressions correctly first. Enabling everything at once before that groundwork is done tends to misfire and erodes trust in the platform early, which is the opposite of what you want. Triage findings from these two rules, get authentication and sensitive-data detection right, and treat everything else as a deliberate, later step. See Expand risk coverage gradually, later in this article.

Phase 2: Maximize discovery coverage

Risk Posture is only as good as the traffic feeding it. Connect as many relevant traffic sources as you have, including Defender, eBPF, Network Sensor, cloud API gateways, and any other supported integration. Treat this as ongoing, not a one-time setup.

• Continuously look for new sources of APIs as your environment changes, and keep adding them as they appear.
• Use the Integrations Traffic Sources UI to verify and monitor that traffic is actually flowing from each source. A connected source that is not sending data gives you false confidence in your coverage.

Phase 3: Calibrate what counts as a valid endpoint

Decide which response codes should count as a real, reachable endpoint for your environment. By default, Documented endpoints (matched to a spec) accept any response code, while Shadow and Undocumented endpoints only count 2xx or 3xx responses as valid. This keeps scanners and probes hitting nonexistent paths from polluting your inventory.

These defaults work well for most environments, but they are tunable. Adjust them if your APIs commonly return other codes as part of normal, legitimate behavior.

Phase 4: Build and maintain API definitions (specs)

How you approach this depends on where your specs come from.

If you generate and upload your own specs

• You can upload specs regardless of whether the platform is currently seeing traffic to those APIs.
• Because only the Security Posture rules are enabled by default, the platform does not fire on Drift or Shadow API detection out of the box. This is by design, not a gap.
• Once you address the Security Posture findings, turn on documentation-based risks such as Drift and Shadow. Sequencing it this way gives you quick wins first, while avoiding false positives that come from incomplete configuration.
• Once you upload specs, scope risk rules to those approved specs only, to minimize false-positive propagation. For example, an Undocumented risk can misfire on every endpoint that lacks an associated spec. Scoping it to only endpoints with an approved or validated spec (Shadow or Documented) avoids that noise.
• APIs change over time. Keep specs updated periodically so Drift and Shadow findings stay accurate rather than accumulating false positives as your APIs evolve.

If Cequence generates your specs

• For each traffic source, once traffic starts flowing, monitor the inventory to identify enumerated endpoints that you can parameterize.
• The platform offers several parameterization approaches, including position-based, pattern-based, preceding-element-based, and host-based, to match the shape of your APIs.
• This step is crucial. It keeps your inventory clean, manageable, and representative of your real API footprint, without losing visibility into the risks inherent in those endpoints. Good parameterization hygiene can reduce your endpoint count by as much as 100 times.
• Verify that your parameterization rules have the effect you expect before you generate specs from the result.
• Once you generate a spec, scope risk rules to those approved specs only. The same false-positive-avoidance principle described earlier in this section applies here too.

Phase 5: Expand risk coverage gradually

Once you address the Security Posture risks, expand into additional categories, including the OWASP API Top 10 and GRC-driven categories such as PCI DSS, HIPAA, or GDPR, depending on your compliance obligations.

Enable one category at a time. Turning on everything relevant at once is tempting, but a single category's worth of findings is a much more manageable, sustainable unit of triage and remediation than an entire risk surface arriving simultaneously.

Phase 6: Operationalize remediation through ticketing

Use the platform's built-in ITSM integrations (Jira and ServiceNow) or your own third-party integrations through the API to drive remediation, rather than triaging issues solely inside the platform UI.

• Once you validate an issue by reviewing its evidence, create a ticket assigned to the right team, with the context they need to act on it.
• By default, the platform attaches an api-security label to tickets created this way, which is especially useful in Jira for filtering and reporting. Use the equivalent construct in other ticketing systems, such as tags, categories, or custom fields, to preserve the same auditability (who created the issue and when) and to support ROI conversations with stakeholders down the line.

Phase 7: Keep inventory and issues tidy

Use the Clear Risk capabilities as routine maintenance, not just cleanup after a mistake.

• When you update a risk rule that may have misfired, clearing keeps the issue count manageable while you retune, rather than leaving stale false positives in the queue.
• When you delete endpoints that do not need to exist in inventory, this keeps both inventory and issue data clean.
• When you delete specs that do not need to exist, the same principle applies. Hygiene in your specs keeps hygiene in your issues.

None of this is meant to be perfectly sequenced on the first try. Traffic patterns shift, new APIs appear, and specs drift out of date. Treat these seven phases as a loop you return to periodically, not a project you complete once. Your Cequence Customer Success contact is glad to walk through this playbook with your team and help tailor the pace to your environment.