Writing Security Requirements
Into Your SCADA RFP

Back to Blog

Part of our SCADA security guide library - 60+ articles on securing industrial operations.

Why Most SCADA RFPs Fail on Security

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.

How to Structure the Security Section

Structure determines whether answers are comparable across vendors. Five rules:

• One control per numbered requirement. Compound requirements ("the vendor shall provide MFA, encryption, and audit logging") let a vendor comply with one clause and claim all three. Number each requirement (SEC-01, SEC-02, ...) so scoring, demos, and contract exhibits can reference them precisely.
• Classify each requirement as mandatory or weighted. Mandatory requirements are pass/fail gates; weighted requirements contribute to the score. Say which is which in the RFP so vendors know where deviation is fatal.
• Name the acceptable evidence per requirement. "Compliance will be verified by live demonstration" reads very differently to a vendor than a blank response field - and honest vendors will tell you early where they cannot demonstrate.
• Require a compliance statement per requirement: Comply / Comply with deviation (explain) / Do not comply / Roadmap (with date). Ban bare yes/no.
• Ask open questions alongside the shall-statements. A requirement verifies a control exists; a question like "describe how tenant isolation is enforced at the database layer" reveals whether the vendor understands their own system. Our 50-question vendor security question bank pairs directly with the requirement language below.

Copy-Paste Requirement Language by Control Family

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.

1. Identity and Authentication

• The vendor shall support multi-factor authentication for all user accounts, including TOTP and phishing-resistant FIDO2/passkey methods, enforceable by administrative policy for every remote login.
• The vendor shall provide role-based access control with granular roles and site-level authorization, such that a user's visibility and control permissions can be restricted to named facilities.
• The vendor shall enforce configurable session expiry, concurrent-session limits, and administrative session revocation, and shall support step-up re-authentication for high-risk workflows.
• The vendor shall detect brute-force authentication attempts and apply persistent account lockout pending administrative review.

2. Tenant Isolation (Cloud/Multi-Tenant)

• The vendor shall enforce tenant isolation at the database layer (for example, row-level security), not solely in application code, and shall describe how the database request context is bound to the authenticated tenant and protected from tampering.
• The vendor shall log attempted cross-tenant access as a security event and support alerting on such attempts.
• The vendor shall demonstrate, during evaluation, that an authenticated session in one tenant receives an authorization denial when requesting another tenant's records.

3. Telemetry Integrity

• The vendor shall cryptographically sign telemetry at the device or gateway using per-device keys, and shall verify signatures before data is accepted into the historian.
• The vendor shall include sequence numbers, timestamps, and payload digests sufficient to detect replayed, reordered, or altered samples, and shall reject detected replays.
• The vendor shall buffer telemetry at the edge during connectivity outages (store-and-forward) and backfill on reconnection without gaps or duplicates.

4. Control and Write Safety

• The vendor shall restrict control writes to an explicitly configured allowlist of writable tags; all tags not on the allowlist shall be read-only.
• The vendor shall validate setpoints against configured engineering bounds before dispatch and shall reject out-of-bounds commands.
• The vendor shall make commands idempotent against duplicate submission, track command state (pending, applied, verified, failed, expired), and perform read-back verification where the underlying protocol supports it.
• The vendor shall record an audit entry for every control action, including the named issuer, target tag, prior value, commanded value, and outcome.

5. Encryption and Data Protection

• The vendor shall encrypt all data in transit, including device and gateway links, using TLS 1.2 or later, and shall state supported versions and cipher policies on request.
• The vendor shall encrypt sensitive application data at rest, use modern adaptive password hashing, and store reset and registration tokens only in hashed form.
• The vendor shall describe how encrypted identifiers remain searchable (for example, blind indexes) without storing them in plaintext.

6. Audit Trails

• The vendor shall maintain tamper-evident audit records for security-relevant events - logins, failed logins, permission changes, configuration changes, and control actions - attributed to named accounts, using an immutable or cryptographically chained store.
• The vendor shall provide tooling to verify audit-chain integrity and shall support export of audit records for retention and regulatory review.

7. Network Architecture

• The vendor shall require zero inbound firewall rules into the OT network; all gateway connectivity shall be initiated outbound over TLS.
• The vendor shall not require a vendor-managed VPN or remote-desktop path into the control network, and shall document all required outbound destinations and ports.
• Where policy requires, the vendor shall offer an on-premise or air-gapped deployment option and describe the feature differences.

8. API Security

• The vendor shall issue scoped API keys with defined lifecycle and immediate revocation, and shall apply rate limits and request validation to all API surfaces.
• The vendor shall implement SSRF defenses on outbound connectors and webhooks, including destination restrictions and pinned-IP delivery with TLS validation against the original host.

9. Detection and SIEM Delivery

• The vendor shall monitor at runtime for cross-tenant denials, privilege probes, repeated authentication failures, and anomalous control activity, and shall generate security events for each.
• The vendor shall deliver security events to the customer's SIEM through a durable mechanism with retry and dead-letter handling, and shall state expected delivery timeliness.

10. Backup and Disaster Recovery

• The vendor shall state RPO and RTO targets, validate backup archives, and demonstrate a tested restore procedure.
• The vendor shall provide customer data export in documented formats and configurable retention, including complete export at contract end.

11. Software Supply Chain

• The vendor shall describe its secure development lifecycle, including dependency scanning, static analysis, and the current status of signed build provenance, and shall provide a software bill of materials on request.
• The vendor shall disclose third-party subprocessors and provide visibility into the deployed version (for example, build identifier) of the services processing customer data.

12. Vendor Security Program

• The vendor shall name a security owner, operate a vulnerability disclosure process, and maintain an incident response process with defined customer notification timelines.
• The vendor shall state the current status - certified, attested, readiness program, or not started - of its SOC 2, ISO 27001, and IEC 62443 alignment, and the scope and cadence of independent security testing.

Mandatory, Weighted, and Disqualifying: The Scoring Model

Not every requirement deserves equal weight, and some deserve no scoring at all - they are gates. Split your requirement set three ways:

• Mandatory (pass/fail): the non-negotiables. Failing any one removes the vendor from the evaluation regardless of price or features.
• Weighted (scored): the majority of requirements, scored per vendor and multiplied by a family weight.
• Informational: open questions that inform judgment but carry no score.

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:

• Any architecture requiring inbound firewall rules or a vendor VPN into the OT network.
• Shared logins as the only operating model, or control actions not attributable to a named user.
• No audit trail on control actions.
• Refusal to demonstrate tenant isolation (for multi-tenant cloud offerings).

Demand Proof, Not Promises

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.

Red-Flag Answers That Should Cost Points

Some responses tell you more than the vendor intended:

• "Unhackable," "military-grade," "100 percent secure." No serious security engineer writes these words. They signal a marketing department answering an engineering question.
• Refusal to demonstrate. A vendor who will not show tenant isolation or setpoint bounds operating live either cannot, or considers your evaluation beneath their process. Both are answers.
• Certification claims with no artifact. "We are SOC 2 compliant" with no report, period, or auditor named. Attestations produce documents; ask for them.
• Inherited-security answers. Responses that describe the cloud provider's data centers and compliance programs rather than the vendor's own application controls. Your risk lives in their code, not the hyperscaler's.
• Deviation hidden in prose. "Comply" statements whose explanation paragraph quietly describes something else. Score the paragraph, not the checkbox.
• Inbound-access requirements framed as convenience. Any answer that needs a hole in your OT firewall should trigger the disqualifier discussion immediately.

Running the Evaluation: Scripted Demos and Test Requests

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:

1. Enroll a new user with FIDO2 MFA; show the policy that enforces MFA on remote logins; trigger step-up re-authentication on a control action.
2. Attempt a setpoint write outside configured engineering bounds; show the rejection and the audit record it produced.
3. From an authenticated session in a test tenant, request another tenant's records; show the denial and the security event it generated.
4. Replay a captured telemetry message; show detection and rejection.
5. Deliver a security event to a SIEM endpoint; then break the endpoint and show retry and dead-letter behavior.
6. Walk through a restore from backup, including how the archive was validated.

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.

Contract Follow-Through: Making the Answers Stick

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:

• SLAs for uptime, support response, and security-event delivery, with remedies.
• Incident and breach notification timelines, severity definitions, and named contacts on both sides.
• Audit and evidence rights: the right to request current attestation reports, test summaries, and subprocessor lists at least annually.
• Data ownership, export, and offboarding terms - formats, timelines, and deletion confirmation.
• Material-change notice: the vendor must notify you if a committed control is removed or substantially altered.
• Roadmap commitments with dates for anything scored as a 1 that influenced the award.

Frequently Asked Questions

Sources & Further Reading

• ISA/IEC 62443 Series of Standards (International Society of Automation)
• NIST SP 800-82 Rev. 3 - Guide to Operational Technology (OT) Security (NIST)
• SOC 2 Reporting and the Trust Services Criteria (AICPA & CIMA)
• ISASecure - IEC 62443 Conformance Certification Program (ISA Security Compliance Institute)