Most SCADA RFPs devote pages to tag counts, trend charts, and licensing - and one sentence to security: the system shall be secure. Vendors happily agree. Then the platform arrives with shared logins, an exposed remote-access path, and no audit trail on control actions, and the gap between what you assumed and what you bought becomes a risk you own for a decade. This guide gives you the security section your next RFP should contain: copy-paste requirement language across twelve control families, a scoring model that separates shipped controls from roadmap promises, the proof to demand for every claim, and the red-flag answers that should end a conversation early.
Part of our SCADA security guide library - 60+ articles on securing industrial operations.
RFP security sections fail in three predictable ways. First, vague language: requirements like "the system shall employ industry-standard security" or "the vendor shall follow security best practices" are unfalsifiable. Every vendor complies with them on paper, so they discriminate between nothing and select for the best marketing writer, not the best engineering.
Second, checkbox answers: RFPs that ask yes/no questions get yes/no answers. "Does the system support MFA?" - yes. Whether MFA is enforceable by policy, covers every remote account, or costs extra per user never surfaces, because the question never asked. A yes that cannot be verified is worth exactly as much as the paper it arrives on.
Third, no proof demands: most RFPs accept the vendor's written response as the final word. Nobody asks to see the control operate, nobody requests an architecture diagram or a test-report excerpt, and nobody calls a reference to ask about security specifically. The evaluation rewards confident prose over deployed capability.
There is also a structural cause: the security section is usually written by procurement, reviewed by nobody in OT or IT security, and scored last - after the shortlist has effectively been decided on features and price. Fixing the language only helps if security carries real weight in the score and a security-literate reviewer reads the answers.
Structure determines whether answers are comparable across vendors. Five rules:
The following requirements are deliberately vendor-neutral - lift them into your RFP and use them with any vendor. They track the control families that recur across the ISA/IEC 62443 series and NIST SP 800-82 Rev. 3. They describe controls that exist in shipping platforms today (Merobix, for example, ships device-signed telemetry and writable-tag allowlists as standard behavior), so none of this language is aspirational. Adjust bounds, timelines, and scope to your operation, and see our cloud SCADA security checklist for the reasoning behind each family.
Not every requirement deserves equal weight, and some deserve no scoring at all - they are gates. Split your requirement set three ways:
Score each weighted requirement on a 0–3 scale: 0 - absent, unanswered, or answered with marketing language; 1 - roadmap only, with a date; 2 - implemented, with documentary evidence provided; 3 - implemented and demonstrated live during evaluation. Then weight the families by the risk they carry for your operation. For cloud SCADA, tenant isolation and control-write safety typically carry the heaviest weights (3x), identity, telemetry integrity, and network architecture next (2x), with the remainder at 1x. A vendor cannot buy back a weak isolation story with a beautiful trend screen.
Define the hard disqualifiers before responses arrive, so nobody argues them down later. Four defensible ones:
The difference between a 2 and a 3 - and between a real control and a compliant sentence - is evidence. Accept four kinds, in ascending order of strength: architecture documentation and diagrams; test or audit evidence excerpts (under NDA where needed); customer references who will discuss security specifically; and live demonstration of the control operating. The table below shows the pattern applied to five common requirements:
| Topic | Weak RFP Language | Strong RFP Language | Proof to Demand |
|---|---|---|---|
| Authentication | "The system shall provide secure user login." | "The vendor shall enforce phishing-resistant MFA (FIDO2) on all remote accounts by administrative policy." | Live MFA enrollment and the policy screen that enforces it |
| Tenant isolation | "Customer data shall be logically separated." | "Isolation shall be enforced at the database layer; cross-tenant requests shall be denied and logged." | Live cross-tenant request test plus architecture diagram |
| Telemetry | "Data shall be transmitted securely." | "Telemetry shall be signed at the device; replayed samples shall be detected and rejected." | Replayed-message demonstration and the envelope specification |
| Audit trail | "The system shall log user activity." | "Tamper-evident audit records shall cover logins, configuration changes, and control actions, attributed to named users." | Exported audit sample plus chain-integrity verification |
| Security testing | "The vendor shall follow security best practices." | "The vendor shall disclose the scope, cadence, and remediation status of its security testing program." | Report summary or excerpt under NDA; named methodology |
On certifications, learn to read readiness versus certified honestly - the distinction matters more than the logo. (A SOC 2 report is an examination against the AICPA's Trust Services Criteria, not a certification, and IEC 62443 conformance is certified through accredited schemes such as ISASecure.) A vendor that says "we run a SOC 2 readiness program and map our controls to IEC 62443, and independent penetration testing is part of the validation program we are building" is giving you an auditable claim you can verify and contract against. That is exactly how Merobix answers this question, and it is a more useful answer than a vague "we are fully compliant" that dissolves when you ask for the report. Our guides to SCADA security certifications and verifying vendor security through pen tests and continuous validation cover how to weigh each claim.
Some responses tell you more than the vendor intended:
Written responses shortlist; demonstrations decide. Send finalists a scripted demonstration scenario list in advance, tied to requirement numbers, and run every vendor through the same script so scores are comparable:
Give vendors the script early - surprising them proves nothing, and prepared demonstrations of real controls are exactly what you want to see. A vendor confident in its architecture will welcome the format; you can pressure-test this entire script against Merobix in a guided demo, with the underlying design documented on our security architecture page.
An RFP answer has no legal weight unless it survives into the contract. Attach a security exhibit that lists, by requirement number, the controls the winning vendor committed to - the scored claims become obligations. Then add the operational terms:
Key takeaway: a SCADA RFP protects you only when every security requirement is specific enough to fail, weighted enough to matter, and verified by demonstration rather than prose. Write "the vendor shall" statements one control at a time, score them 0–3 with hard disqualifiers, demand live proof for the heaviest weights, and carry the winning answers into a contract exhibit. Vendors who welcome that process are the ones you want inside your OT network.
A SCADA RFP should include testable requirements across twelve control families: identity and MFA, tenant isolation, telemetry integrity, control-write safety, encryption, audit trails, network architecture, API security, detection and SIEM delivery, backup and disaster recovery, software supply chain, and the vendor security program itself. Each requirement should be phrased as a specific, verifiable statement - the vendor shall enforce phishing-resistant MFA on all remote accounts, for example - rather than a vague instruction to follow security best practices, and each should name the evidence that will be accepted as proof.
Score each requirement on a 0–3 scale: 0 for absent or unanswered, 1 for roadmap-only, 2 for implemented with documentary evidence, and 3 for implemented and demonstrated live. Multiply by a weight that reflects the risk each control family carries for your operation - tenant isolation and control-write safety typically weigh heaviest for cloud SCADA - and define hard disqualifiers up front, such as any architecture that requires inbound firewall rules into the OT network or shared operator logins. The weighted total ranks vendors; the disqualifiers remove them regardless of total.
Accept four kinds of proof, in ascending order of strength: written architecture documentation and diagrams, excerpts of test or audit evidence (shared under NDA where necessary), customer references who will discuss security specifically, and live demonstration of the control operating - an MFA enrollment, a rejected out-of-bounds setpoint, a denied cross-tenant request. A checkbox yes with no supporting evidence should score no higher than an honest description of a readiness program in progress, because an unverifiable claim tells you nothing about the deployed system.
The strongest red flags are: claims of being unhackable or military-grade, which signal marketing rather than engineering; refusal to demonstrate tenant isolation or control safeguards live; describing certifications the vendor cannot name a report or certificate for; answers that describe only the cloud provider's inherited security rather than the vendor's own application; and any architecture that requires inbound firewall ports or a vendor-managed VPN into your OT network. Vague answers to specific questions are themselves data - score them as absent.
Carry the winning RFP answers into a security exhibit attached to the contract, so the scored claims become obligations. Include: the specific controls the vendor committed to, uptime and support SLAs, breach and incident notification timelines with named contacts, audit and evidence rights such as the ability to request current test summaries or attestation reports annually, data ownership and export terms for offboarding, and a change clause requiring notice if a committed control materially changes. Without contract follow-through, RFP answers expire the day the deal closes.
Bring the requirement list from this guide - MFA enrollment, out-of-bounds setpoint rejection, cross-tenant denial, signed telemetry - and watch each control operate live.