Governance and standards

Fleet Control's governance controls in one place, and how they relate to concepts from IEC 62443-3-3, IEC 61850, IEC 61400-25 and NERC CIP. A mapping for your review, not a certification.

This page brings Fleet Control's governance controls together, then sets them beside the standards that operations and OT security teams usually ask about. It is written to help your team review Fleet Control against your own obligations.

This page is a mapping, not a certification or a compliance statement. Fleetera does not claim that Fleet Control conforms to, satisfies or is equivalent to any requirement of IEC 62443, IEC 61850, IEC 61400-25 or NERC CIP, and it does not claim any IEC 62443 security level. Requirement numbers below name review topics so your team can find them in the standard. Whether your deployment meets a standard depends on your whole system, and the assessment is yours.

Governance controls in Fleet Control

People and roles

Control	How it works
Built-in roles	Viewer reads. Operator reads, sets up commands and sends them. Admin can also approve critical commands, change the two-person approval setting and set local control. See Who can do what
Checked on the server	Fleetera's services check the role on every request, from the app and from the API alike. Hiding a button is never the only control
Own accounts	Each person signs in with their own account, and every record names the person who requested, approved or declined

Before a command is sent

Control	How it works
Declared commands only	Only commands declared on a template and bound to an address can be sent. There is no free-form write to an arbitrary point
Risk levels	Low and Standard are sent when the person confirms. High and Critical need the command's exact name typed, and Fleetera checks it on the server. See Risk levels
Two-person approval	An organization setting, off unless an admin turns it on. When it is on, a critical command sent to one asset waits for an approver other than the requester. A request nobody decides within 24 hours expires. Turning the setting off does not send requests already waiting. See Critical commands and approval
Approval bound to the request	At approval, Fleetera checks that the command, its risk and its binding are still the ones requested. If any changed, the approval is refused and nothing is sent. The parameters are frozen when the request is made
No critical commands in bulk	Critical commands are refused in bulk runs, whatever the approval setting
Readiness checked at send time	A command is refused, with its reason, when it is not bound to a connector its gateway runs, when the gateway is offline, when a method call goes to a gateway that has not reported it can run one, or when the site or gateway is under local control. Commands are never queued for later: a refused command is not sent when the cause clears
Local control	An admin can hold a site or a gateway under local control, and a person at the gateway can switch the gateway's local control on. While it is on, every command to the affected assets is refused before anything is sent
Staged rollout	A bulk run goes out canary first, in batches, and aborts when failures pass the threshold you set. It can be paused, resumed or aborted. See Bulk Runs
No safety functions	Emergency stops and other safety functions are never commandable through Fleetera

After a command is sent

Control	How it works
Execution record	Every request has a record: who requested it, any approval decision, the parameters as sent, the gateway, each step's time, the result, and the read-back. See Command History
Read-back	After a write, the gateway reads the point back, and the record says Verified, Mismatch or Unverified with its reason. See Read-back verification
Origin	Each record says whether the request was made in the app or through the API, as the request declared it
Export	Command History exports the matching records as CSV, up to 50,000 rows per file
Retention	Command records are kept with no expiry date. The analytics copy keeps 365 days
Setting changes	Changes to the two-person approval setting are recorded with who made them and when. Local-control changes are recorded with their reason. A gateway's local-control change made at the gateway is recorded when the gateway reports it, without the name of the person at the gateway

IEC 62443-3-3

IEC 62443-3-3 sets out system security requirements for industrial automation and control systems. The topics below are the ones reviewers most often raise about a command path. Each row says what Fleet Control does and where your responsibility starts.

Review topic	What Fleet Control does	Limits and your responsibilities
SR 1.1, human user identification and authentication	Each person uses their own account, and every record names the requester and any approver	Fleetera does not ask for a second sign-in factor, or a fresh sign-in, before a command is sent. Do not share accounts: a shared account makes the record name the wrong person
SR 2.1, authorization enforcement	Permissions come from the person's role and are checked by Fleetera's services on every request. Only admins can approve. The requester cannot approve their own request	There are three built-in roles. Assigning them, and turning on two-person approval where your rules need it, is up to you
SR 2.8, auditable events	Requests, approval decisions, sends, results and read-backs are recorded per command. Approval-setting and local-control changes are recorded	The records cover what happens through Fleetera. Changes made at the controller, in a SCADA system or on the device itself are not seen. Records reach your own monitoring only when you export them
SR 2.11, timestamps	Each step of a record carries the time Fleetera recorded it	A record shows when Fleetera recorded each step, not when the equipment acted
SR 2.12, non-repudiation	Requester and approver are named on the record, and an approval applies only to the request as it was made	An application record on its own does not provide non-repudiation. Records are not signed or chained so that tampering would be evident

IEC 61850 and IEC 61400-25 control concepts

IEC 61850 describes communication for power utility automation, including how controls are operated and reported, and IEC 61400-25 applies it to wind power plants. Your engineers may know the concepts below from substation and wind plant control. Fleet Control does not implement either standard: it writes to the OPC UA nodes and Modbus registers you bind. The table sets each concept beside the closest Fleet Control behavior and says how they differ.

Concept	Closest Fleet Control behavior	How it differs
Direct operate and select-before-operate	Low and Standard commands are sent when confirmed. High and Critical commands need the typed name, and a Critical one can wait for an approver	The typed name is a confirmation by a person in Fleetera, not a select on the device. Fleetera does not select or reserve a point before it writes, and the 24-hour approval window is not a device select timeout
Command termination and its cause	The record holds the gateway's answer, and a read-back verdict with its reason	A read-back is one reading taken straight after the write. It is not a protocol command termination, and it does not show that the plant responded or kept the value
Originator category	Each record carries an origin: App or API	Origin is what the request declared, not something Fleetera verified, and it has none of the station, maintenance or automatic categories
Local and remote authority	Site and gateway local control refuse every command from Fleetera	This is Fleetera's own setting. Fleetera does not read a local or remote switch on the device or the controller, and an admin can clear a gateway's local control from Fleetera. Keep your controller-level local and remote switching and interlocks
IEC 61400-25 control of wind power plants	A command such as an active-power curtailment cap is a value you declare and bind	Fleet Control commands are not mapped to IEC 61400-25 information models or logical nodes

NERC CIP

The NERC Critical Infrastructure Protection standards apply to BES Cyber Systems in North America according to how those systems are categorized. That categorization, and whether and how CIP requirements apply to your use of Fleetera, are for you and your compliance team to determine. Fleetera does not make that determination and does not claim that Fleet Control satisfies any CIP requirement.

CIP-005, electronic security perimeters. Its requirement R2 covers Interactive Remote Access: an intermediate system, encryption and multi-factor authentication, and controls on vendor remote access. NERC's Glossary of Terms defines Interactive Remote Access and excludes system-to-system process communications from it. How these definitions apply to people using Fleet Control, and to Fleetera's connection with its gateways, depends on your deployment.
CIP-007, systems security management. Its requirement R4 covers security event monitoring: which events are logged, alerting, log retention and review. Fleet Control's execution records and CSV export can be one input to that work. A command ledger and its retention period do not meet the requirement on their own.

What stays with you

Safety functions stay in the plant's local safety chain. Fleetera never carries an emergency stop.
Controller limits and interlocks stay in your controllers. Fleet Control is supervisory: it sends a setpoint or an action, and the controller decides what the equipment does.
Local and remote control at the plant stays with your plant's own switching. Fleetera's local control is an additional hold, not a replacement.
Risk levels, roles and the approval setting are yours to choose, and to review as your fleet changes.
Reviewing and keeping records beyond what Fleetera retains, including exporting them to your own systems, is yours to arrange.

Sources

The standards are published by their owners. Read the current editions that apply to you:

IEC 62443-3-3:2013, System security requirements and security levels
IEC 61850-7-2, Basic information and communication structure, abstract communication service interface (edition 2.1)
IEC 61400-25-1:2017, Communications for monitoring and control of wind power plants, overall description of principles and models
NERC CIP standards, including CIP-005-7 and CIP-007-6
NERC Glossary of Terms

Governance and standards

On this page