Implementing OT Security in Thailand: RFP and FAT/SAT Acceptance

When introducing OT security measures at a factory in Thailand, if you decide what to purchase based solely on firewall or monitoring product model numbers, you will quickly run into roadblocks after ordering—such as “How do we test equipment that cannot be stopped?”, “Who approves exceptions?”, and “How do we restore remote access for maintenance vendors?”. What procurement teams must determine first are: the production processes to protect, unacceptable downtimes, constraints of existing equipment, required evidence, and pass/fail criteria. This article is a practical guide for converting those requirements into an RFP (Request for Proposal) and FAT/SAT (Factory/ Site Acceptance Test) plan. It is intended for plant managers, engineering/maintenance, IT/OT staff, and procurement professionals at manufacturing companies operating in Thailand who use any of the following: PLCs, HMIs, SCADA, industrial PCs, cameras, measuring instruments, MES connectivity, or remote maintenance connections.

On September 21, 2026, the US NIST released the Initial Public Draft of “Guide to Operational Technology (OT) Security” SP 800-82 Rev.4, with a comment period open until November 30, 2026. The draft expands on OT asset management, network monitoring/detection, protection of management functions, and zero trust principles. However, as of this writing, Rev.4 is not finalized. When specifying reference documents in your requirements, base them on the final Rev.3 (2023) and NIST CSF 2.0, and list discussion points from the Rev.4 draft separately. Note that NIST documents are not laws uniformly applicable to all factories in Thailand. Always check customer contracts, industry requirements, and any regulations applicable in Thailand for each project.

Deliverables You’ll Take Away from This Article

By the end of this article, you should have: (1) a one-page scope diagram, (2) an RFP table to provide consistent requirements to all bidders, (3) FAT/SAT test sheets, and (4) an operations handover and exception management table. Rather than competing on the number of product features, you will compare whether each proposal can be safely implemented and validated on your actual production line. The tables and questions below can be copied into your internal procurement documents, but replace example values like allowable downtime or configuration settings with those measured and agreed upon at your site.

1. First, Define the “Lines to Protect” and the “Permissible Scope of Changes”

The scope of OT is not determined by the number of endpoints alone. If a PLC stops the packaging line, it impacts upstream work-in-progress, downstream inspection, and ERP records. At the start of your RFP, list not only the equipment, but also the processes each device supports, normal communications, maintenance contracts, and the impact of downtime. Do not simply declare unknown devices as “out of scope”—distinguish them as “to be investigated.” For methods and priorities in collecting asset information, see OT Asset Management for Factories in Thailand. This article focuses not on creating the asset register itself, but on using it as procurement criteria and acceptance evidence.

During a site walkdown, physically trace control panels, PLCs and I/O, HMIs, engineering workstations, industrial switches, line servers, historians, maintenance routers, and wireless access points. On logical diagrams, include not just IP addresses, but also who manages each device, when it connects, and which processes are affected by downtime. If wiring diagrams and actual equipment differ, check change management records and postpone implementing communication-blocking rules until site approval is obtained. For network design and segmentation, see Industrial Network Construction Explained.

In the RFP scope, clearly distinguish between “items to be implemented in this bid,” “items to be designed only,” and “existing items to be monitored as-is.” If you ambiguously include configuration changes that could void equipment warranties, legacy devices lacking authentication, or safety systems that cannot be stopped, each vendor will estimate based on different assumptions. Even for out-of-scope items, if there are connection points, leave them on the boundary diagram so bidders cannot overlook them. On the factory side, list the names of production, maintenance, quality, IT, and procurement contacts, and ensure they can attend evaluation meetings.

2. How to Use the Rev.4 Draft in Your RFP

The release of the Rev.4 draft is an opportunity to review your existing procurement documents. NIST’s summary of the draft indicates a direction of strengthening asset management, network monitoring, and protection of management functions, while maintaining OT-specific performance, reliability, and safety requirements. However, the wording and structure of the draft may change before finalization. Therefore, do not simply state “fully compliant with Rev.4”—instead, express the required outcomes as concrete tests. For example, “Maintenance access must be pre-approved, use individual IDs, be time-limited, session-logged, and disabled after use” is clear for procurement regardless of which version is referenced.

If using ISA/IEC 62443, do not just state “62443 compliant”—specify whether you require the asset owner’s program, service provider operations, system requirements, or component requirements, and from whom. Even if a device is certified to a standard, it does not automatically ensure the entire factory’s network design, access control, or recovery procedures are met. NIST CSF 2.0 organizes outcomes into six functions: Govern, Identify, Protect, Detect, Respond, and Recover. In procurement tables, it is easier to compare if you attach “who must show what for acceptance” to each row, rather than just listing function names as headings.

3. RFP Chapter 1: Current State, Design Constraints, and Responsibility Boundaries

The first chapter should include not only the factory name and number of lines, but also process flow, operating calendar, existing topology, presence of serial connections, vendor remote maintenance, MES/ERP interfaces, backup status, and known change-freeze periods. If diagrams are highly confidential, it is acceptable to distribute them only after NDAs are signed, but ensure all bidders receive the same version and share Q&A responses. If connection paths are unverified, state so and include site surveys in the bid scope.

In the responsibility matrix, clarify who is responsible for what: e.g., equipment vendors for PLC programs and safety logic, network contractors for wiring and switches, security vendors for policies and monitoring, and the factory for downtime approval and final acceptance. For incidents spanning multiple vendors, decide who does initial troubleshooting and who restores settings. If operators work in Thai and managers approve in Japanese/English, specify the language for alert names, procedures, and escalation contacts. Since translation alone may not suffice, include a read-through by local staff as an acceptance item.

4. RFP Chapter 2: Write Required Security Outcomes by Function

Boundaries and Communications: Separate communications within lines, between lines, with factory IT, and with external maintenance. Require bidders to propose allowed sources, destinations, and protocols. Include a monitoring period in observation mode, and require a step-by-step process to enable blocking policies only after current communications are understood. Confirm device compatibility with industrial protocols, impact on broadcast and time sync, and behavior during redundancy failover. Designs that immediately block undocumented communications risk halting production.

Maintenance Access: Avoid shared IDs; require individual identification, approval, connection time limits, operation logging, emergency procedures, and revocation upon resignation or contract end. If placing a jump host before PLCs needing remote maintenance, verify that required tools actually work there and that this does not violate vendor support terms. Do not assume always-on direct internet connections to control devices. Record temporary connections with request numbers, target equipment, and end times.

Monitoring and Detection: Use passive traffic monitoring as the default; specify mirror port or network TAP locations, time synchronization for logs, storage destinations, alert responsibilities, and handling of false positives. If active scanning is to be performed, require prior vendor approval, defined scope, downtime windows, and validation in a test environment. Avoid unverifiable marketing claims like “detects all anomalies”—instead, acceptance tests should confirm that unauthorized maintenance connections, configuration changes, and known test traffic are logged as expected.

Recovery: Specify who backs up and restores PLC programs, HMI settings, switch configs, firewall rules, licenses, keys, and virtual machines, and in what order. Existence of backup files alone is insufficient. Include compatibility of restore targets, separation of storage locations, permissions, and actual restore procedures in the test sheet. For safety or production systems, do not force tests on live equipment—use backup units, test environments, or downtime windows.

5. Require Bidders to Submit “Comparable Responses”

So that all bidders can answer on the same lines, have them select for each requirement: “Standard feature,” “Achievable with additional configuration,” “Customization needed,” “Not supported,” or “Requires site survey.” Each answer should be accompanied by supporting documentation, assumptions, tasks required from the site, and how it will be proven in FAT/SAT. Screenshots or product catalogs alone are not proof that it will work with your existing PLCs and operating conditions.

Scoring should consider not only price, but also production downtime risk, compatibility with existing equipment, maintainability, quality of evidence, and handover to local teams. Weightings should be set before procurement and not changed after proposals are opened. Initial and ongoing costs should be broken down by license, hardware, installation, validation, maintenance, log storage, and on-site support. This article does not specify market prices or budgets, as costs vary by line configuration, downtime windows, existing contracts, and required standards.

6. What to Check in FAT: Safety Before Bringing to Site

FAT is performed before shipment or in a lab environment to verify that functions work as designed. For items that cannot be replicated on actual equipment, state “Not performed in FAT, to be checked in SAT” rather than marking as passed. Fix the agreed configuration version, settings files, device models/firmware, simulated PLCs/HMIs, test data, and expected results in the test sheet. At minimum, check authentication/authorization, allowed and blocked communications, time sync, log output, backup and restore, device failure behavior, and rollback procedures.

For example, in a blocking test, separate items such as “test terminal can communicate with allowed HMI,” “communications from unauthorized paths are blocked,” and “block events are logged with timestamps.” Finally, revert to pre-test settings and measure time to resume production connections. Do not perform stress tests on PLCs or use live production data without approval from the equipment vendor and the factory. FAT records should include operator, date/time, config version, results, evidence files, unresolved issues, and retest conditions.

7. What to Check in SAT: Can It Be Operated on Actual Lines in Thailand?

SAT is the on-site acceptance after installation. It is performed under factory-approved downtime windows and rollback conditions. Even products that passed FAT may behave differently on site due to unexpected communications, old firmware, network loops, time drift, or vendor-specific maintenance software. Compare the current on-site configuration to the latest diagrams, record differences, and only then apply settings. Do not approve security alone without also passing quality and safety checks for the process.

In SAT, select representative scenarios from “normal operation,” “changeover,” “shutdown/restart,” and “failure/rollback.” For monitoring alerts, test that local staff can read notifications, identify affected equipment, distinguish false positives from real incidents, and escalate appropriately. If using Thai-language procedures, confirm that local staff can reproduce steps in their own words. The plant manager should verify throughput and quality impacts after switchover, and not accept based solely on IT-side success screens.

Acceptance criteria must be signed by both purchaser and vendor before execution. For example: “Process continues under normal conditions,” “Approved maintenance connections are logged,” “Unauthorized connections are rejected,” “Simulated alerts reach designated staff,” and “Settings can be reverted to agreed state”—all observable conditions. Numeric thresholds should be based on actual process measurements, not generic figures from articles. For test failures, classify responses as corrective action, retest, temporary measures, or purchaser-approved exceptions, and specify who does what by when.

8. Post-Go-Live Contracts: Include Alerts, Changes, and Recovery

Passing acceptance at go-live is only the starting point for operations. The RFP should include monitoring hours, first responders, conditions for contacting equipment vendors, periodic review of remote maintenance privileges, rule change approvals, patch/vulnerability information handover, backup verification, and rollback support during incidents. Do not impose 24/7 monitoring requirements on all factories indiscriminately. However, for lines operating nights or holidays, ensure notification contacts are always covered. Service levels should not be set mechanically as “within X minutes,” but tailored to risk, internal structure, and feasible support contracts.

Change management is especially critical. When new machines are connected, maintenance vendors change, or MES data integration is added, decide who updates communication rules and the asset register. Avoid situations where only the security device’s admin panel has the latest info, and equipment diagrams or maintenance contracts are outdated. Change tickets should include purpose, scope, risks, test method, rollback plan, approver, and post-implementation diagram updates. For exceptions, set expiration and review dates—do not allow them to become permanent loopholes.

9. 10 Questions for On-Site Meetings Before Ordering

1. Which equipment on this line cannot be stopped, and what are the permissible downtime windows?
2. Who has final approval over PLC, HMI, and industrial PC configurations?
3. Are there any countermeasures that conflict with equipment vendor warranties or support terms?
4. How many remote maintenance paths are actually used, and who approves them?
5. Do IT/OT boundaries and inter-line communications match the diagrams?
6. How will you handle design changes and additional quotes if unknown devices are discovered?
7. For items not reproducible in FAT, who will test them in SAT and during which downtime windows?
8. If allowed communications are blocked, who will review which information to decide on rollback?
9. In which languages (Thai, English, Japanese) will operational records and emergency communications be maintained?
10. After go-live, who will update assets, privileges, communication rules, and recovery procedures?

If your team cannot answer any of these internally, it is better to mark them as “requires site survey” in the RFP rather than letting bidders make their own assumptions. Separate deliverables from survey findings and proposal assumptions, and specify the process for contract changes if the scope increases later.

10. Common Pitfalls and How to Prevent Them in Procurement Documents

If you “compare only product feature lists,” you miss alignment with existing equipment and operational structure. Attach test conditions and evidence to each function for comparison. If you “apply IT vulnerability scanning directly to OT,” you risk downtime or malfunctions. Obtain device-specific approvals and test in non-production environments first. If you “rush to block traffic,” include observation of current communications, exception identification, phased deployment, and rollback in the procurement scope. If you “treat FAT pass as SAT pass,” you overlook site-specific wiring and operational differences—keep separate test sheets for each.

It is also risky to assume “certification alone makes the whole factory secure.” Product certification is just one piece of evidence; boundary design, maintenance ID management, on-site training, and recovery feasibility must be separately verified. If you “fail to assign post-implementation responsibility,” alerts will be ignored and access permissions will proliferate. Specify handover meetings, asset registers, privilege matrices, and periodic reviews as deliverables in the purchase order.

11. If You Want to Complete in 90 Days, Focus on Decision Gates, Not Just Dates

The implementation period depends on factory downtime windows, vendor availability, and the number of lines. Here, 90 days is an example for planning roles and deliverables, not a guaranteed lead time. In the first phase, conduct site surveys, define scope, identify critical processes, and assign responsible persons, recording diagram discrepancies. In the second phase, compare RFP responses and safety, agree on final design, FAT scripts, and SAT downtime windows. In the third phase, conduct FAT, on-site installation, SAT, local training, and operations handover. Passing each phase requires not just “having documents,” but confirmation by the factory’s designated approver.

Even with tight schedules, do not skip site surveys, verification of existing communications, rollback design, or assignment of operational leads. If you must expedite procurement, limit the scope to a single line or maintenance path, and decide on further rollout after reviewing the first SAT results. This allows you to develop usable test methods and training materials first. For horizontal expansion, do not simply copy settings to all lines—reassess differences in devices, downtime conditions, and communication partners.

12. Practical Requirements Definition and Acceptance Procedures

The following is not a citation from a standard, but a sample text for the ordering party to fill in their own requirements. Replace the content in square brackets with actual line names, responsible persons, equipment IDs, or agreed values. If you issue the order with these fields left blank, the contractor will estimate price and schedule based on their own assumptions, making comparison and acceptance difficult. For values that the factory side cannot determine, clearly state “to be approved by the ordering party after on-site survey” to distinguish from the proposer’s estimates.

Scope of Work: The contractor shall cover control communications, maintenance connections, and monitoring paths for [target line/equipment ID], and assess the impact on existing equipment. Connection points deemed out of scope shall also be shown on the boundary diagram, with reasons for exclusion submitted. If any unidentified devices are discovered, the contractor shall not proceed with changes and must report to the ordering party’s [approval authority].

Safe Changes: Before applying any configuration changes, the contractor shall submit observation results of current communications, allow/deny rules, equipment manufacturer constraints, downtime windows, rollback procedures, and contact information for responsible persons, and obtain approval from the ordering party. Any changes affecting safety systems or product warranties require confirmation by the [equipment manufacturer or designated responsible person].

Maintenance Connections: External maintenance shall be limited to individuals with identifiable IDs and to pre-approved targets and timeframes. Records must be kept to track connection initiation, operations, termination, and denials. Upon contract termination, personnel changes, or emergency connections, privileges must be re-evaluated. Any necessary exceptions must be documented with reasons, expiration dates, alternative measures, and approvers.

Acceptance and Handover: For each FAT and SAT test, record the operation, expected result, evidence, actual result, pass/fail status, and person responsible for corrective actions. Items that cannot be tested during FAT shall be carried over to SAT. Items that fail during SAT must, in principle, be corrected and retested; if provisional operation is necessary, obtain written approval and a deadline from the ordering party. Before final acceptance, deliver as-built drawings, configurations, backups, recovery procedures, access rights tables, operation manuals, and training records.

Do not simply copy this sample text as-is; verify feasibility for each target. For example, if there are multiple external maintenance companies, list each company’s scope of work and the person responsible for ID revocation in a separate table. If only the equipment manufacturer can perform PLC backups, include their attendance and the method for receiving deliverables in the contract. If logs contain personal or business partner information, align storage location, access rights, and retention period with your company’s contracts and policies. Use a mutually pre-approved version of the FAT/SAT test sheets, and if changes are made during testing, record the change history and whether retesting is required. By aligning these details before contracting, you can select not only by price but also by the reliability of implementation and operation.

In the minutes of the acceptance meeting, do not simply record “pass”; instead, include actual results, pass/fail status, unresolved exceptions, provisional operational restrictions, planned retest dates, and signatories for each test ID. The production department is responsible for process continuity and quality, the equipment department for safety and recovery, IT/OT staff for communications, access rights, and logs, and the procurement department for contractual delivery conditions. If a decision is made to start operation with some functions incomplete, the plant manager must understand the remaining risks, and a record of approval for deadlines and alternative measures is required. Do not store evidence only in the contractor’s report; hand over evidence to a storage location accessible to the ordering party.

Furthermore, when deploying to the next line, do not simply reuse the initial acceptance sheets. If PLC models, equipment manufacturer maintenance conditions, switch configurations, or operating hours differ, the permitted communications and safe downtime windows will also change. Use the initial test procedures as a template, add site-specific differences, and obtain re-approval. This approach preserves the benefits of a common design while ensuring that line-specific risks are not overlooked during testing.

13. Conclusion

What procurement leads must ultimately confirm is whether acceptance is based on more than just vendor self-reporting. The deliverables list should include current and completed diagrams, managed configuration versions, lists of allowed communications, admin and maintenance privilege matrices, raw FAT/SAT data, unresolved issues, backups, restore procedures, local-language operation manuals, and training records. Also decide in advance on file formats, storage locations, update permissions, and handover procedures at contract end. If monitoring devices are vendor-dependent, ask about log export formats and how to access them after contract termination. This avoids situations where you only review the contract scope after an incident occurs.

Another key point is to establish a post-acceptance improvement cycle. Unknown communications or exceptions found during initial SAT should not become just the vendor’s “homework”—register them in the factory’s change management. Record which process is affected, why the exception is needed, how long it is allowed, and how it will be resolved at the next review. As new equipment, factory Wi-Fi, cloud analytics, or outsourced maintenance are added after go-live, boundary conditions will change. In regular meetings, focus not on the number of alerts, but on whether any unauthorized connections remain, if privilege revocation is delayed, and whether recovery procedures match the current configuration. Since these cannot be maintained by products alone, clearly assign local responsible persons and budget owners.

For OT security implementation at factories in Thailand, it is crucial to fix process constraints and acceptance criteria before purchasing equipment. NIST SP 800-82 Rev.4 is an Initial Public Draft as of September 21, 2026; use the finalized Rev.3, NIST CSF 2.0, and, as needed, ISA/IEC 62443 or CISA guidance as references, and rewrite requirements into observable outcomes at your site. In the RFP, clarify responsibility boundaries and require evidence for proposals; in FAT, validate in a safe test environment; in SAT, verify on actual Thai production lines—covering allowed/blocked communications, maintenance access, detection, recovery, and operations handover. Manage exceptions with expiration dates, and only after assigning responsibility for ongoing updates does implementation become true operation.

Even if you are just starting to select target lines, organize RFP requirements, or draft FAT/SAT test sheets, you can contact TOMAS TECH for a consultation. We will help you clarify what needs to be confirmed before procurement, based on your existing equipment constraints and local team operations.

Primary References

• NIST SP 800-82 Rev.4 Initial Public Draft (September 21, 2026)
• NIST SP 800-82 Rev.3 Final (2023)
• NIST Cybersecurity Framework 2.0
• ISA/IEC 62443 Series Official Guide
• CISA Cross-Sector Cybersecurity Performance Goals
• CISA ICS Recommended Practices (includes procurement templates)

*Note: This article is based on public information as of October 2, 2026, and general procurement practices. It does not declare compliance with any standard, legal obligation, or performance guarantee.*

When using this document internally, replace the “facts to confirm” in the tables with your own line names, equipment IDs, responsible persons, and measured operating conditions. Assign deadlines and investigation leads for any unknowns. If you keep updating the same tables after acceptance, you can reuse the rationale for future line expansions.