# Detailed SASE RFP — fictional manufacturing example Fictional manufacturing example. No customer project, supplier response or procurement outcome is represented. Nothing in this demonstration is published to the Opportunity Board. ## Original buyer brief We are a manufacturing company with 15 sites: 10 in the UK and five in Germany. We have 600 users, including 30 remote users. We want a managed SASE solution to replace our existing VPN and protect access to cloud applications. Please provide a proposal and pricing. ## Example buyer decisions and response instructions Example buyer decision: use the existing Entra ID directory for identity, MFA and device posture. Require ZTNA, SWG, CASB, FWaaS and DLP, with logging exported to the existing SIEM. Suppliers must identify unsupported devices and application dependencies. Example buyer decision: protect production continuity with an IT/OT segmentation boundary. Contractor access must be individually approved, time-bound and audited. SASE must not be assumed to replace plant safety controls. Example buyer decision: request regional PoP coverage, availability SLA and latency evidence, plus a failover test. Exact bandwidths and maximum tolerable outage remain to be confirmed by each plant; suppliers must state assumptions separately. Example buyer decision: require a managed service, 24/7 incident support, escalation contacts and a RACI defining policy ownership. Request data residency, retention and sub-processor details for UK and German operations; retention periods remain a buyer decision. Example buyer decision: plan phased migration within six months, with a pilot, approved cutover windows, rollback and training. The dates and acceptance thresholds require buyer confirmation before contract award. Example buyer decision: compare a 36-month contract term in GBP using one pricing table for one-off and recurring charges, licences, total cost, exclusions and exit/data-return terms. This is an illustrative evaluation basis, not a supplier quote. Example evaluation rule: mandatory identity integration, the IT/OT boundary and a rollback plan are pass/fail. Score compliant bids on security fit (30%), resilience (25%), operations (20%), implementation (10%) and total cost (15%). Require dated evidence within the last 12 months, current certificates and expiry dates. Buyers must adapt these example weights and evidence periods. Response format: answer each question by ID with compliance, delivery method, limitations, evidence reference and price impact. Separate confirmed capability from roadmap commitments. These supplier answers have not been provided in this demonstration. ## Identity and private application access SASE-ZTNA-001 Describe how your platform enforces zero trust access to private applications. Evidence requested: Architecture diagram; Policy example; Identity provider integration list Reason: Private application access is a core SASE use case and should be controlled by identity, device and application context rather than broad network access. SASE-ZTNA-002 Which identity providers do you support natively, and which protocols (SAML, OIDC, SCIM)? Evidence requested: Supported IdP list; Protocol matrix Reason: Native IdP integration determines whether identity, group and lifecycle data drive access decisions in real time. SASE-ZTNA-003 How is device posture evaluated and used in access decisions? Evidence requested: Device posture signal list; Sample posture-based policy Reason: Device posture lets buyers enforce different access rules for managed, unmanaged and high-risk devices. SASE-ZTNA-004 Describe step-up authentication and continuous session validation. Evidence requested: Step-up trigger list; Session validation cadence Reason: Continuous validation reduces the risk of stale sessions being used after the risk context changes. SASE-ZTNA-005 Describe how third-party and contractor access is managed. Evidence requested: Third-party access workflow Reason: Third-party access is a common breach vector and needs tight, audited control. ## Web, SaaS and threat protection SASE-SWG-001 Describe your secure web gateway, including TLS inspection and URL category coverage. Evidence requested: SWG architecture; TLS inspection approach; Category list Reason: The SWG is the primary control plane for web traffic and must inspect TLS to be effective. SASE-SWG-002 Describe browser-based isolation options and use cases. Evidence requested: Isolation architecture Reason: Isolation is a useful control for risky categories without blocking access. SASE-CASB-001 Describe your inline and API-based CASB coverage for sanctioned and shadow SaaS. Evidence requested: List of API-integrated SaaS; Inline vs API coverage matrix Reason: CASB visibility is needed to control data movement to SaaS and to detect shadow SaaS use. SASE-DLP-001 Describe your DLP capabilities, policy templates and incident workflow. Evidence requested: Sample DLP policy; Incident workflow; Template list Reason: DLP is the primary control for preventing accidental and malicious data egress and must be content-aware. SASE-DLP-002 How is policy kept consistent across managed and unmanaged devices? Evidence requested: Unmanaged device coverage approach Reason: Unmanaged devices are a common data egress channel and need consistent controls. SASE-FW-001 Describe your cloud-delivered firewall, including layer-7 application controls. Evidence requested: FWaaS architecture; Layer-7 application list Reason: FWaaS replaces branch firewalls and must provide consistent layer-7 controls. SASE-IPS-001 Describe your IPS, anti-malware and sandboxing stack and update frequency. Evidence requested: Signature update cadence; Sandbox file type list; Threat intel sources Reason: Threat protection effectiveness depends on inline inspection and timely intelligence. SASE-FW-002 How is policy kept consistent across branch, roaming and cloud egress traffic? Evidence requested: Unified policy diagram Reason: Inconsistent policy planes create gaps and operational overhead. SASE-FW-003 Describe DNS-layer security and its integration with the rest of the stack. Evidence requested: DNS security policy example Reason: DNS-layer controls catch threats early and protect off-network devices. ## Branch integration and resilience SASE-SDWAN-001 Describe how SD-WAN integrates with your SSE stack. Evidence requested: Reference architecture; Integration mode list Reason: Tight SD-WAN and SSE integration determines branch user experience and policy consistency. SASE-SDWAN-002 How are SASE PoPs selected for each branch and how is performance measured? Evidence requested: PoP map; Latency expectations; Telemetry samples Reason: PoP selection drives branch latency and user experience. SASE-SDWAN-003 Describe link failover behaviour, including 4G/5G or LTE failover. Evidence requested: Failover decision tree; Convergence times Reason: Failover behaviour determines store, plant and clinic uptime during link events. SASE-SDWAN-004 Describe direct internet breakout behaviour at branches. Evidence requested: Breakout policy example; Trust model Reason: Local breakout reduces backhaul cost but must keep security policy consistent. SASE-SDWAN-005 Describe segmentation options for OT or sensitive networks at branch and plant sites. Evidence requested: Segmentation reference design Reason: Segmentation between OT and IT is essential in industrial environments. ## Logging and data residency SASE-LOG-001 Which log types are captured and what retention options are available? Evidence requested: Log schema; Retention options Reason: Log coverage and retention drive audit, investigation and regulatory reporting. SASE-LOG-002 How can logs be exported to our SIEM or storage? Evidence requested: List of SIEM integrations; Sample export Reason: Buyers need logs in their own SIEM for correlation and long-term retention. SASE-LOG-003 How are administrative actions audited? Evidence requested: Admin audit log sample Reason: Admin audit trails are required for regulatory and forensic purposes. SASE-LOG-004 How are user-experience metrics collected and shared? Evidence requested: UX telemetry sample Reason: UX telemetry helps prove SASE delivers a better user experience. SASE-DR-001 Where are customer data, logs and metadata stored and processed? Evidence requested: Data flow diagram; Region list Reason: Data residency drives regulatory compliance and contractual obligations. SASE-DR-002 List your sub-processors and their locations. Evidence requested: Sub-processor list with regions Reason: Sub-processor disclosure is required for many regulated buyers. SASE-DR-003 Describe support access controls and the regions from which support operates. Evidence requested: Support access model Reason: Support access can introduce cross-border data exposure if not controlled. SASE-DR-004 Describe support for customer-managed encryption keys. Evidence requested: CMK approach Reason: CMK can be a requirement for highly regulated workloads. ## Managed service and responsibilities SASE-SVC-001 Describe your service model, including managed, co-managed and self-managed options. Evidence requested: Service description Reason: The service model defines the split of responsibilities and informs operational cost. SASE-SVC-002 What SLAs apply to support response, restoration and change requests? Evidence requested: SLA matrix; Credit regime Reason: Operational SLAs matter more than platform availability for day-to-day experience. SASE-SVC-003 How are service reviews structured and how often do they occur? Evidence requested: Sample monthly service report Reason: Regular reviews keep the service aligned with buyer priorities. SASE-SVC-004 Describe escalation paths, including out-of-hours. Evidence requested: Escalation matrix Reason: Escalation matters most when incidents occur outside business hours. ## Migration and acceptance SASE-DEP-001 Describe a typical deployment plan for an estate of our size. Evidence requested: Reference deployment plan Reason: A credible deployment plan reduces project risk and surprises. SASE-DEP-002 How is configuration automated for sites, users and policy? Evidence requested: Automation tooling description Reason: Automation drives rollout speed and consistency across multi-site estates. SASE-DEP-003 How are changes tested and rolled back? Evidence requested: Test plan template; Rollback runbook Reason: Tested change and rollback procedures reduce outage risk. SASE-DEP-004 How are user agents and clients distributed and updated? Evidence requested: Agent lifecycle approach Reason: Agent updates impact user experience and security posture. ## Pricing and contractual terms SASE-COM-001 Describe your pricing model and what is included. Evidence requested: Pricing schedule Reason: Clarity on the pricing model drives like-for-like supplier comparison. SASE-COM-002 Provide a worked example for our user and site count. Evidence requested: Worked example with assumptions Reason: Worked examples expose hidden charges and reveal true unit cost. SASE-COM-003 How are growth and reductions handled within the term? Evidence requested: Flex terms Reason: Flex terms determine commercial exposure if estate size changes. SASE-COM-004 List all items priced separately, including professional services. Evidence requested: Add-on list Reason: Add-ons drive total cost of ownership and must be transparent. ## Supplier evidence SASE-VE-001 Provide your current certifications and expiry dates. Evidence requested: Certification list; Expiry dates Reason: Current certifications support regulated buyer due diligence. SASE-VE-002 Share recent independent test results relevant to SASE. Evidence requested: Test report references Reason: Independent test results reduce reliance on vendor claims. SASE-VE-003 Provide customer references in our sector. Evidence requested: Reference list Reason: Sector-specific references increase confidence in fit. SASE-VE-004 Provide details of any recent security incidents and your handling of them. Evidence requested: Incident summary Reason: Incident handling history shows operational maturity. ## Bespoke buyer question BUYER-OT-001 How will you revoke a maintenance contractor’s access to a legacy production application during an identity outage without disrupting production or bypassing the IT/OT boundary? Evidence requested: Proposed test procedure, access-revocation behaviour, audit trail and rollback plan ## Still to confirm Site bandwidths, application inventory, outage tolerances, retention periods, acceptance thresholds and approved migration dates. This coverage check does not resolve those decisions or certify technical correctness.