Connect981 – Content Dev

RSC Cluster: NIST 800-53 Security Controls: Practical Guides, Mappings, and Industrial Use

  • processor

    In privacy and data protection contexts relevant to industrial and regulated environments, a processor commonly refers to an organization or individual that processes personal data on behalf of another party that determines why that data is processed.

    Core definition

    A processor is an entity that:

    • Processes personal data only on documented instructions from another party that decides the purposes and main means of processing (often called a controller or similar role in various frameworks).
    • Uses technical and organizational measures to handle the data, such as collecting, storing, transmitting, analyzing, or deleting it.
    • Does not independently decide new purposes for the data outside the instructions it receives.

    In industrial settings, a processor could be, for example, a cloud provider hosting production and quality data that includes personal data, an MES or ERP service provider operating a managed service, or an analytics vendor processing sensor and operator data for a manufacturer.

    Operational meaning in manufacturing and OT/IT

    Within manufacturing and industrial operations, the processor role appears in scenarios such as:

    • Hosted MES, historian, or quality systems where a service provider processes operator IDs, batch records, or deviation data on behalf of a plant or company.
    • Third-party monitoring, predictive maintenance, or OT security platforms that ingest log files, badge IDs, or IP information from production networks.
    • External HR, training, or access management tools integrated with shop-floor systems that handle personnel identifiers and access logs.

    Contracts and data processing agreements typically define what the processor is allowed to do with the data, retention expectations, sub-processing, cross-border transfers, and security measures. The organization that decides the purposes for using the data is responsible for ensuring that the processor is appropriately selected and managed.

    Relation to NIST 800-53 and GDPR

    Under GDPR, a processor is specifically defined as an entity that processes personal data on behalf of the controller. NIST SP 800-53 does not use the same legal terminology, but it provides control families that can be used by processors and controllers alike to manage privacy and security risks.

    In industrial environments, a service provider acting as a processor might implement NIST 800-53 security and privacy controls to support a manufacturer that has obligations under GDPR or similar privacy laws. The legal role (processor vs controller) comes from the applicable law and contracts, while frameworks such as NIST 800-53 help organize supporting controls.

    Common confusion

    • Processor vs controller: The controller (or similar role under other laws) decides the purposes and main means of processing. The processor follows those instructions and does not repurpose the data independently.
    • Processor vs joint controller or co-operator: If two organizations jointly decide purposes and essential means, they may both be considered controllers under some laws, not a controller and processor.
    • Processor (privacy role) vs CPU/processing hardware: In industrial automation, “processor” can also mean a CPU, PLC processor, or microprocessor that executes instructions. In privacy and compliance discussions, the term almost always refers to the data protection role, not the hardware component.

    Secondary meaning in industrial systems

    Separately from privacy terminology, in OT and IT engineering a processor can mean the hardware or logical component that executes instructions:

    • A central processing unit (CPU) in a server hosting an MES or historian.
    • The processing unit in a PLC, DCS controller, or embedded device on the shop floor.

    In this technical sense, a processor is part of the computing infrastructure and is not a legal role in data protection.

  • privacy-by-design

    Privacy-by-design is an approach to engineering systems, processes, and products so that privacy and data protection requirements are considered and integrated from the earliest stages of design and throughout the full lifecycle. It contrasts with treating privacy as an after-the-fact add-on or a single compliance step.

    In industrial and regulated manufacturing environments, privacy-by-design commonly refers to how organizations plan, implement, and document controls around personal data in IT and OT systems such as MES, ERP, QMS/LIMS, maintenance systems, and connected equipment platforms.

    Key characteristics

    Privacy-by-design typically includes:

    • Proactive consideration of privacy before deploying new systems, integrations, or analytics that use personal data (for example, HR data, operator IDs, training records, access logs, or customer data tied to serialized products).
    • Integration with system and process design, such as role-based access control, data minimization, pseudonymization or aggregation of data, and clearly defined retention and deletion behaviors.
    • Lifecycle view, covering requirements, design, implementation, validation/qualification, change control, operation, and decommissioning of systems that handle personal data.
    • Documented controls and traceability across policies, procedures, risk assessments, and technical configurations in systems like MES, DCS/SCADA, historians, and quality systems.
    • Alignment with security controls, where security standards and control catalogs (for example, NIST SP 800-53 or similar) are used to support but not replace documented privacy requirements and design decisions.

    Operational meaning in manufacturing

    In practice, privacy-by-design in industrial operations may appear as:

    • Conducting a privacy or data protection impact assessment when introducing new shop-floor monitoring, traceability, or workforce analytics tools.
    • Configuring MES or historian systems so identifiable operator data is only visible to specific roles and is logged in a way that supports audits without unnecessary exposure.
    • Defining how personal data is captured in batch records, deviation reports, training logs, or maintenance systems, and how long it is retained.
    • Integrating privacy controls into change control workflows, validation documentation, and configuration management for regulated environments.

    Common confusion

    Privacy-by-design is commonly confused with:

    • Security-by-design: Security-by-design focuses on protecting systems and data from unauthorized access or modification. Privacy-by-design overlaps with security but emphasizes how personal data is collected, used, retained, and exposed, including data minimization and purpose limitation.
    • A single regulation or standard: Privacy-by-design is a design and governance approach, not a specific law, certification, or framework. Organizations often use standards and control catalogs (such as NIST SP 800-53, ISO-based frameworks, or internal policies) as reference points to implement and evidence privacy-by-design.

    Relation to control catalogs such as NIST SP 800-53

    Control catalogs like NIST SP 800-53 provide structured security and privacy controls, terminology, and mappings that can support privacy-by-design. In many organizations, selected controls are tailored and mapped into existing QMS, ISMS, validation, and change control documentation to demonstrate how privacy requirements are designed into systems and processes. The catalog itself is not a turnkey privacy-by-design framework; it is used as input to a broader design and governance approach.

  • NIST Risk Management Framework

    The NIST Risk Management Framework (NIST RMF) is a structured, repeatable process defined by the U.S. National Institute of Standards and Technology for managing information security and cybersecurity risk to systems and organizations. It provides a life cycle approach for selecting, implementing, assessing, authorizing, and monitoring security and privacy controls for information systems.

    Core concept

    NIST RMF links system-level security and privacy activities to organizational risk management. It is commonly used for federal information systems in the United States and by many private-sector organizations that want a rigorous, control-based risk process.

    The framework is organized as a sequence of steps that apply across the life of a system. In its modern form, these steps commonly include:

    • Prepare: Establish context, roles, risk management strategy, and governance.
    • Categorize: Define the impact level of a system and the information it processes.
    • Select: Choose appropriate security and privacy controls from a catalog (often NIST SP 800-53), tailoring them to the system.
    • Implement: Put the selected controls into operation and document how they are used.
    • Assess: Evaluate if the controls are correctly implemented and effective.
    • Authorize: Management formally accepts residual risk and authorizes the system to operate.
    • Monitor: Continuously track control performance, system changes, and emerging risks, updating earlier steps as needed.

    Use in industrial and manufacturing environments

    In industrial and manufacturing contexts, NIST RMF is often applied to information systems and operational technology (OT) that handle production data, quality records, or connectivity between plant-floor systems and enterprise IT. Typical examples include:

    • Applying RMF steps to manufacturing execution systems (MES), historians, or SCADA/PLC networks that interface with regulated production.
    • Using NIST SP 800-53 controls under the RMF to define security baselines for plant systems that store batch records, electronic device histories, or other regulated data.
    • Aligning authorization and monitoring activities with internal governance, quality, and audit-readiness processes.

    RMF does not prescribe a specific technology stack. Instead, it provides a structure for integrating cybersecurity and privacy controls into system life cycle management, including design, commissioning, change control, and decommissioning of OT and IT systems used in manufacturing.

    What it includes and excludes

    NIST RMF includes:

    • A defined sequence of risk management steps for systems.
    • Guidance on selecting and assessing controls, often using NIST SP 800-53.
    • A governance-oriented process that ties technical decisions to organizational risk tolerance.

    It does not include:

    • An official certification program for organizations, plants, or systems.
    • Detailed configuration standards for specific vendors or products.
    • Industry-specific regulatory rules, although it can be mapped to them.

    Relationship to NIST SP 800-53 and similar documents

    NIST RMF is a process framework. NIST Special Publication 800-53 is a catalog of security and privacy controls that is often used within this framework during the “Select,” “Implement,” and “Assess” steps. Many organizations apply the RMF using 800-53 controls as building blocks for their security baselines.

    Organizations can implement RMF and align to NIST 800-53 controls, and can seek independent assessments of that implementation, but there is no official NIST-issued certification that a system or site is compliant with RMF or 800-53.

    Common confusion

    • NIST RMF vs. NIST CSF: The NIST Cybersecurity Framework (CSF) is a higher-level, outcome-focused framework that organizes cybersecurity activities into functions such as Identify, Protect, Detect, Respond, and Recover. NIST RMF is more system-focused and control-driven, often used where formal authorization and detailed control assessment are required.
    • NIST RMF vs. control catalogs: RMF is the risk management process. Control catalogs such as NIST SP 800-53 provide the individual controls that are applied within that process.
    • NIST RMF as a standard vs. certification: RMF is guidance for risk management, not a certifiable standard. It can inform internal policies, audits, and vendor requirements, but references to being “certified to RMF” are typically informal or inaccurate.

    Operational perspective in regulated manufacturing

    In regulated manufacturing environments, NIST RMF is often used as one of several reference frameworks for managing cyber risk to systems that impact product quality, data integrity, or safety. It may be:

    • Mapped to internal quality and validation processes used for commissioning and modifying OT/IT systems.
    • Integrated with change control so that security impacts are evaluated when modifying control systems or MES configurations.
    • Referenced in audits to explain how security controls around electronic records, access management, and data transmission are selected and overseen.

  • Personally Identifiable Information

    Personally Identifiable Information (PII) commonly refers to any data that can be used to identify a specific individual, either directly on its own or indirectly when combined with other information. PII is a core concept in privacy, information security, and regulatory compliance across many industries, including manufacturing.

    What Personally Identifiable Information includes

    PII typically includes, but is not limited to:

    • Direct identifiers such as full name, government-issued ID numbers, employee IDs, photos, or biometric data
    • Contact details such as home address, personal phone numbers, and personal email addresses
    • Identifiers that can single out a person in context, such as login IDs linked to a named employee, badge numbers, or machine/operator IDs tied to HR records
    • Data that becomes identifying when combined with other information, such as date of birth, job title, or location plus other attributes

    In regulated manufacturing environments, PII often appears in HR systems, training records, access control logs, visitor logs, supplier contact databases, and engineering or quality workflows where individual users are recorded as reviewers, approvers, or operators.

    What Personally Identifiable Information does not include

    Information is generally not treated as PII when it has been de-identified so that individuals cannot reasonably be re-identified. Examples include:

    • Aggregated production statistics that do not reference specific employees
    • Anonymized quality or safety metrics where operator IDs have been removed or irreversibly masked
    • Equipment identifiers (such as machine IDs) that are not linked to named individuals or HR records

    Whether information is considered PII can depend on the context and on applicable privacy or data protection laws. The same data element may be non-identifying in one context and identifying in another if it can be linked back to a person.

    Operational relevance in manufacturing and industrial systems

    In industrial and manufacturing settings, PII interacts with operational technology and information systems in several ways:

    • Access control and logging: Badge systems, MES user accounts, and audit trails often record which specific operator performed a step, creating PII in event logs.
    • Training and qualification records: Systems that track who is qualified to run certain equipment or perform certain procedures store PII linked to job roles, training dates, and performance history.
    • Supplier and customer contacts: Names and contact details of supplier engineers, quality contacts, and customer representatives are maintained in ERP, QMS, and collaboration tools.
    • Incident and deviation records: Corrective action, nonconformance, and safety incident records may reference specific individuals involved in a manufacturing event.
    • Remote access and monitoring: Logs from remote maintenance, OT security tools, and IT service management systems often include user identifiers that qualify as PII.

    Organizations typically define governance around where PII is stored in MES, ERP, QMS, LIMS, OT security platforms, and document control systems, and align handling practices with internal policies and applicable regulations.

    Relationship to NIST SP 800-53 and control families

    In the context of NIST SP 800-53, PII is specifically addressed in the PT (Personally Identifiable Information Processing and Transparency) control family. These controls focus on how organizations:

    • Collect, process, store, and share PII
    • Minimize PII and define its purpose of use
    • Provide transparency about PII handling practices
    • Integrate privacy considerations with security controls

    In regulated manufacturing environments, this typically applies to HR data flows, supplier and customer records, engineering and collaboration tools with user identity data, and monitoring or logging systems that capture employee activities.

    Common confusion

    • PII vs. personal data: Many data protection frameworks use the term “personal data” or similar. In practice, these concepts overlap heavily with PII, although specific legal definitions and scope can differ by jurisdiction.
    • PII vs. PHI: Protected Health Information (PHI) is a subset of personal information related to health status or care in certain regulatory frameworks. PII is broader and is not limited to health data.
    • PII vs. user credentials: Usernames and IDs may or may not be PII depending on whether they can be tied back to an identifiable person in a given context.

    Because definitions and regulatory scope can vary, organizations often document their own operational definition of PII and how it applies across their manufacturing and IT/OT systems.

  • overlay

    An overlay in industrial and regulated environments commonly refers to an additional layer of requirements, controls, or configuration rules that is applied on top of a standard baseline. It is used to adapt a generic standard, policy, or control set to a particular context, such as a specific facility, system type, or regulatory regime.

    General meaning

    More broadly, an overlay is any secondary layer that modifies, constrains, or augments an underlying base. In operations and manufacturing systems, this often appears as:

    • A set of extra cybersecurity controls that sit on top of a baseline control catalog.
    • Site-specific operating procedures layered onto a corporate standard.
    • Additional configuration or parameter sets applied over default system settings.

    Overlays in cybersecurity and control baselines

    In the context of documents like NIST SP 800-53, an overlay commonly refers to a structured set of added or tailored controls that refine a baseline (such as Low, Moderate, or High). For example, an industrial control system (ICS) overlay might add or adjust controls to better reflect OT constraints, safety considerations, or uptime requirements, without redefining the entire baseline.

    Operationally, this means that a security team may:

    • Select a baseline control set appropriate for the system impact level.
    • Apply an overlay that adds, enhances, or clarifies specific controls for the environment.
    • Document how the overlay modifies the baseline for governance, implementation, and audit purposes.

    Other operational uses

    Outside formal security frameworks, overlays also appear as:

    • Configuration overlays: Files or profiles that override default settings for a plant, line, or product family.
    • Visualization overlays: Additional information layers on HMI/SCADA or MES screens, such as alarm states, quality status, or maintenance indicators drawn on top of a base layout.
    • Process overlays: Extra checks, approvals, or documentation steps required for certain product classes or customers, layered over standard work.

    What an overlay is not

    • It is not the original baseline, standard, or default configuration.
    • It is not a complete replacement for the underlying set of rules; it assumes the base remains in force unless explicitly changed.
    • It is not inherently a certification or approval; it is a descriptive layer of additional or modified requirements.

    Common confusion

    • Overlay vs. baseline: A baseline is the starting set of standard controls or requirements; an overlay modifies or extends that baseline for specific circumstances.
    • Overlay vs. profile or template: A profile or template may define a complete configuration or policy set. An overlay usually assumes an existing profile or baseline and only specifies differences or additions.

    Tie to NIST SP 800-53 context

    When discussing the difference between NIST SP 800-53 and 800-53B, overlays are often mentioned as a way to adapt generic control baselines to particular system types or sectors, including industrial and OT environments. In that usage, an overlay is a documented, repeatable way to select, refine, or add controls on top of the baseline while keeping traceability back to the original catalog.

  • controls

    In industrial and regulated environments, controls are specific, intentional measures used to manage risk, enforce requirements, and ensure that processes and systems operate within defined limits. They can be technical, procedural, or organizational, and they are usually documented, implemented, and monitored as part of a broader management system.

    What controls include

    Controls commonly refer to:

    • Technical controls: Configuration settings, system functions, or automated mechanisms, such as access control rules in a MES, network firewalls for OT systems, sensor interlocks, or automated validation checks in an ERP/MES integration.
    • Procedural controls: Documented procedures, work instructions, standard operating procedures (SOPs), or checklists that direct how tasks must be performed, reviewed, and recorded.
    • Organizational controls: Governance structures, defined roles and responsibilities, segregation of duties, approval workflows, and training requirements.

    In information security and standards like ISO 27001, controls are selected and applied to treat identified risks and to protect the confidentiality, integrity, and availability of information. Examples include password policies, backup procedures, change management processes, and supplier security requirements.

    How controls show up in operations

    Within manufacturing and industrial operations, controls typically appear as:

    • Configured system rules (for example, enforcing electronic signatures or limiting who can release batches).
    • Quality and compliance procedures (for example, in-process inspection steps and deviation handling workflows).
    • Physical safeguards (for example, machine guards, badge readers, or restricted access areas).
    • Monitoring and review mechanisms (for example, audit logs, exception reports, and periodic access reviews).

    Controls are often tied to specific risks, requirements, or standards. They are usually traceable, with evidence that they are defined, implemented, and operating as intended.

    What controls are not

    • They are not guarantees that incidents or nonconformities will never occur.
    • They are not the same as the overall management system; they are elements within that system.
    • They are not limited to IT or cybersecurity; they also cover production, quality, safety, and supplier-related processes.

    Common confusion

    • Controls vs. policies: Policies set high-level intent and expectations. Controls are concrete mechanisms that implement or enforce those policies.
    • Controls vs. procedures: A procedure can be a control when it is specifically designed to manage a defined risk or requirement, but not every procedural step is necessarily a control.
    • Controls vs. control systems: In automation, a control system is the hardware and software that regulates a process (such as a PLC or DCS). Within that system, individual settings, logic blocks, and interlocks act as controls in the risk and compliance sense.

    Relation to ISO 27001 and similar frameworks

    In frameworks like ISO 27001, controls are cataloged options that organizations select and tailor based on risk assessment results. In industrial and OT contexts, this often includes:

    • Access, authentication, and authorization controls across MES, historian, and shop-floor systems.
    • Change and configuration management controls for production recipes, control logic, and system patches.
    • Monitoring controls, such as log collection and review for both IT and OT assets.

    These controls support structured, evidence-based management of information and operational risks across existing systems and suppliers.

  • controller

    A controller is a device, system component, or organizational role that directs how a process behaves according to defined logic, rules, or policies. In industrial and regulated environments, the term is used both for technical control devices and for governance roles in data protection and compliance.

    Technical meaning in industrial and OT systems

    In operations and manufacturing, a controller commonly refers to a hardware or software component that monitors inputs, applies control logic, and issues outputs to manage a process or piece of equipment.

    Typical examples include:

    • PLC (Programmable Logic Controller): Executes control programs to operate machinery, interlocks, and safety functions on the shop floor.
    • DCS controller: Manages continuous or batch processes, often coordinating multiple loops and units.
    • Motion or drive controller: Controls motors, positioning systems, or drives in packaging, robotics, or material handling.
    • Embedded or device controller: Built into instruments, tools, or skids to manage localized functions.

    These controllers typically:

    • Read signals from sensors, HMIs, or higher-level systems (MES, SCADA, ERP).
    • Apply programmed logic, recipes, or setpoints.
    • Send commands to actuators, drives, or other devices to maintain desired operating conditions.

    A controller in this sense is part of the operational technology stack and is distinct from business systems like MES or ERP, although it may exchange data with them.

    Data protection and privacy meaning

    In data protection and privacy frameworks, a controller commonly refers to the organization or entity that determines why and how personal data is processed.

    Within regulations such as GDPR and control catalogs like NIST SP 800-53, the controller typically:

    • Defines the purposes and means of processing personal data (for example, employee data, quality records, or access logs).
    • Chooses which systems, processors, and technical controls are used to handle that data.
    • Is accountable for implementing appropriate privacy and security controls and for honoring applicable rights and obligations.

    In industrial settings, the controller in this regulatory sense is usually the operating company that owns or operates the manufacturing environment, even if certain processing activities are outsourced to service providers or cloud platforms.

    Common confusion

    • Controller vs processor (privacy context): A controller decides the purposes and essential means of processing personal data. A processor processes data on behalf of the controller, following the controller’s documented instructions.
    • Controller vs MES/SCADA (technical context): A controller operates at the equipment or process-control level. MES, SCADA, and ERP operate at higher levels, orchestrating workflows, visualization, and business processes rather than directly driving I/O.
    • Controller vs control: A controller is the device or role implementing or directing behavior. A control is the specific safeguard, rule, or mechanism used to manage risk or enforce a requirement.

    Relation to NIST 800-53 and GDPR

    When mapping NIST SP 800-53 privacy and security controls to legal frameworks like GDPR in an industrial environment, the term controller is often used in its data protection sense. The organization acting as controller must decide how 800-53 controls are applied in practice across OT, IT, MES, and related systems to support privacy obligations, while recognizing that technical controls alone do not establish legal compliance.

  • OLIR

    OLIR stands for Online Informative References, a NIST program and catalog used to publish structured mappings between cybersecurity frameworks, standards, guidelines, and regulations. It provides a common, machine-readable way to express how one set of security or cybersecurity controls relates to another.

    What OLIR includes

    In practice, OLIR most often refers to the NIST Online Informative References catalog, which:

    • Contains mappings between the NIST Cybersecurity Framework (CSF) and other documents such as NIST SP 800-53, sector guidelines, or industry standards.
    • Uses a standardized data format so mappings can be consumed by tools that support compliance, risk management, or control implementation tracking.
    • Is maintained by NIST, with contributions from organizations that define or maintain referenced documents.

    How OLIR is used in industrial and regulated environments

    For manufacturing, OT, and other regulated operations, OLIR commonly appears in:

    • Control mapping exercises: Relating NIST CSF outcomes to detailed controls in NIST SP 800-53 or other security standards used in plants and industrial networks.
    • Policy and standard alignment: Showing how internal cybersecurity policies, OT security baselines, or supplier requirements align with external frameworks.
    • Tool configuration: Feeding mappings into GRC, risk, or compliance tools that help track implementation status of controls across IT and OT systems.

    OLIR mappings are informational. They help with alignment and traceability of controls, but they do not replace plant-specific risk assessments, control design, implementation, or validation.

    Common confusion

    • OLIR vs NIST CSF: The Cybersecurity Framework (CSF) is the framework itself. OLIR is the catalog and model NIST uses to publish mappings between CSF and other documents.
    • OLIR vs a standard or regulation: OLIR is not a standard, regulation, or certification scheme. It is a structured reference model and catalog that describes relationships between them.

    Context: mappings between CSF and NIST SP 800-53

    Authoritative mappings between the NIST Cybersecurity Framework and NIST SP 800-53 controls are published by NIST using the OLIR format and catalog. These mappings can support alignment of OT and IT cybersecurity programs with both documents, but they must be interpreted and tailored for each specific industrial environment.

  • control

    A control in industrial and regulated environments is a specific safeguard, requirement, or mechanism put in place to manage risk, enforce a policy, or ensure a process behaves within defined limits. Controls can be technical, procedural, or organizational, and they are usually written in a way that makes them testable and auditable.

    Types of controls in manufacturing and industrial systems

    In this context, the term “control” commonly refers to two closely related areas:

    • Operational and process controls: Actions, rules, or mechanisms that keep a manufacturing or industrial process within specified limits. Examples include equipment interlocks, recipe parameter limits in an MES, approval steps before batch release, and documented work instructions that must be followed.
    • Governance, risk, and compliance controls: Discrete requirements defined in standards, internal policies, or regulations that address specific risks, such as access control, change control, data integrity, or cybersecurity. These often appear as numbered controls in a framework or standard.

    Across both areas, each control is typically associated with:

    • A stated objective (what risk or behavior it addresses)
    • A description of how it is implemented (system configuration, procedure, training, or combination)
    • Evidence that it exists and is used (records, logs, signatures, audit trails, or system settings)
    • A way to verify effectiveness (reviews, tests, audits, or monitoring)

    Control vs. control family

    In many security and compliance frameworks, a control family is a logical grouping of related individual controls, such as a set of access control requirements or data integrity safeguards. An individual control is one specific, testable requirement within that family, such as enforcing unique user IDs or logging all changes to critical process parameters.

    In regulated manufacturing, implementation, validation, and evidence collection typically happen at the individual control level, while reporting, mapping to standards, and risk discussions often happen at the control family or framework level.

    Operational meaning

    Practically, a control shows up in daily operations as something that constrains or governs behavior. Examples include:

    • A system configuration that prevents starting a batch unless raw material inspections are complete.
    • A requirement that all recipe changes be approved and electronically signed by authorized roles.
    • A network rule that restricts remote access to OT equipment to specific secure pathways.
    • A documented procedure that defines how deviations are recorded, reviewed, and closed.

    Each of these is a distinct control that can be documented, tested, and audited.

    Common confusion

    • Control vs. policy: A policy states intent or direction (for example, “all changes must be approved”), while controls are the specific mechanisms and steps that enforce that intent.
    • Control vs. process: A process describes end-to-end activities. Controls are specific points within that process that ensure certain conditions are met or risks are addressed.
    • Control vs. controller: In automation, a controller is a device (such as a PLC or DCS). A control is the logical requirement or safeguard that may be implemented in that device, in software, or procedurally.