Connect981 – Content Dev

RSC Colour: Primary Blue

  • ISO 27002

    ISO 27002 is an international standard that provides a detailed code of practice for information security controls. It is designed to support the implementation and continual improvement of an Information Security Management System (ISMS), typically aligned with ISO 27001.

    What ISO 27002 includes

    ISO 27002 describes a broad set of information security controls and associated implementation guidance. These controls commonly cover areas such as:

    • Information security policies and governance
    • Organization of information security and roles
    • Human resource security (onboarding, offboarding, awareness)
    • Asset management and classification
    • Access control and user account management
    • Cryptography and key management
    • Physical and environmental security
    • Operations security, including backup and logging
    • Communications and network security
    • System acquisition, development, and maintenance
    • Supplier relationships and third-party access
    • Information security incident management
    • Business continuity aspects related to information security
    • Compliance-related controls and documented evidence

    In industrial and manufacturing environments, these controls are applied across IT and OT systems, including MES, SCADA, PLC networks, engineering workstations, and integrated ERP or quality systems.

    What ISO 27002 is not

    • It is not a management system standard; it does not define ISMS requirements in the same way ISO 27001 does.
    • It is not a certification on its own; organizations are typically certified against ISO 27001, not ISO 27002.
    • It is not specific to any single technology, vendor platform, or industry sector.

    Instead, ISO 27002 serves as a reference catalog of controls and guidance that organizations can select, adapt, and justify, for example as part of the ISO 27001 Statement of Applicability.

    Operational meaning in manufacturing environments

    In regulated, brownfield manufacturing settings, ISO 27002 is commonly used to:

    • Inform security baselines for production networks, plant-floor servers, and MES infrastructure.
    • Align information security policies with existing QMS, validation, and change control procedures.
    • Define access control, logging, and backup expectations for systems used in batch records, traceability, and quality investigations.
    • Structure evidence for audits by mapping implemented controls to ISO 27001/27002 control references.

    Organizations usually tailor ISO 27002 controls to legacy OT systems, vendor constraints, and existing safety or quality controls, documenting justifications where full technical enforcement is not practical.

    Relationship to ISO 27001

    ISO 27001 defines the requirements for establishing, implementing, maintaining, and improving an ISMS. ISO 27002 complements it by:

    • Providing detailed descriptions and guidance for many of the controls referenced by ISO 27001.
    • Helping organizations select, design, and document controls that address identified information security risks.
    • Supporting the development of policy, standards, procedures, and records within the overall ISO 27001 framework.

    In practice, an ISO 27001 project in a manufacturing organization often uses ISO 27002 as the main reference when writing detailed security standards and work instructions that affect plant-floor and enterprise systems.

    Common confusion

    • ISO 27002 vs ISO 27001: ISO 27001 sets ISMS requirements and is commonly used for certification. ISO 27002 provides supporting control guidance; it is not a standalone certification standard.
    • ISO 27002 vs internal policy: ISO 27002 is a public international standard, while a company’s information security policy framework is an internal set of documents that may draw on ISO 27002 but is specific to that organization.

    Link to the information security policy framework

    When designing an information security policy framework under ISO 27001, ISO 27002 is typically used as the primary reference for which controls should be considered and how they can be implemented. For manufacturing organizations, this often includes mapping ISO 27002 controls to plant procedures, validated systems, and IT/OT governance documents without implying that ISO 27002 adoption alone guarantees any regulatory or audit outcome.

  • software supply chain security

    Software supply chain security commonly refers to the set of practices, controls, and monitoring used to protect software and all of its components across their entire lifecycle, from initial sourcing through deployment and maintenance. It focuses on ensuring that the software running in an organization, including in industrial IT and OT environments, has not been tampered with, corrupted, or introduced from untrusted or unmanaged sources.

    What it includes

    In a manufacturing or industrial context, software supply chain security typically covers:

    • Component sourcing and inventory: Identifying and tracking third-party and open-source libraries, firmware, drivers, and application components used in MES, SCADA, PLC programming tools, and other OT/IT systems.
    • Vendor and service provider governance: Assessing and managing security expectations for software vendors, integrators, cloud providers, and managed service partners that supply or maintain production systems.
    • Build and integration security: Protecting build pipelines, CI/CD tools, repositories, and configuration management so that compiled binaries and deployment packages match the intended source and configuration.
    • Code integrity and provenance: Using signing, checksums, or similar mechanisms to verify that software, firmware, and configuration updates come from expected sources and have not been altered.
    • Secure delivery and deployment: Controlling how updates, patches, and new applications are tested, approved, and rolled out to production, especially to safety- or quality-critical OT systems.
    • Runtime monitoring and verification: Monitoring systems for unauthorized or unexpected software, versions, or configurations on servers, workstations, HMIs, engineering laptops, and embedded devices.
    • Decommissioning and lifecycle management: Removing or isolating unsupported software, obsolete components, and deprecated dependencies, and ensuring access and credentials are revoked when vendors or tools are retired.

    What it does not include

    Software supply chain security is related to but distinct from:

    • General cybersecurity: It is narrower than overall IT/OT security programs, which also address networks, physical access, endpoint hardening, and user behavior.
    • Traditional logistics supply chain: It does not focus on the movement of physical goods and materials, although it can interact with supplier management and quality processes.

    Operational meaning in regulated manufacturing

    In regulated or high-consequence manufacturing environments, software supply chain security often appears in:

    • Qualification and validation activities for MES, LIMS, historians, and equipment software, including maintaining documented evidence of versions, sources, and change history.
    • Vendor risk management, where suppliers of control systems, embedded firmware, and cloud-based production tools are assessed for secure development and patching practices.
    • Change control and configuration management, ensuring that only reviewed and approved software changes reach production assets and that rollback paths are maintained.
    • Traceability, where organizations track which software versions, libraries, and configurations were used to manufacture specific lots or batches, to support investigations or remediation.

    Relationship to NIST 800-53 and similar frameworks

    Standards and frameworks such as NIST SP 800-53, NIST SP 800-161, and software bill of materials (SBOM) guidance are often used as reference models for organizing controls related to software supply chain security. In mixed IT/OT and brownfield environments, these frameworks are commonly used to define and evidence requirements for:

    • Selecting and onboarding software suppliers and integrators
    • Securing development, build, and deployment pipelines
    • Monitoring software assets, versions, and vulnerabilities across IT and OT
    • Documenting traceability of software changes and approvals

    Common confusion

    • Software supply chain security vs. software composition analysis (SCA): SCA tools analyze code and dependencies for vulnerabilities and licenses. They are one technique within software supply chain security but do not replace broader governance of vendors, build pipelines, and deployment.
    • Software supply chain security vs. SBOM: An SBOM provides an inventory of components in a software product. Software supply chain security uses SBOMs as one input but also addresses process controls, vendor management, and runtime verification.
    • Software supply chain security vs. physical supply chain security: Physical supply chain security focuses on protecting the movement and storage of materials and finished goods, while software supply chain security focuses on digital components and code.

    Context in OT/IT convergence

    As OT and IT systems converge, software supply chain security extends into areas such as PLC and DCS firmware updates, smart sensor and IIoT device management, and integration middleware between MES, ERP, and plant-floor equipment. Organizations typically align these practices with their broader cybersecurity, quality, and supplier management programs to maintain consistent requirements and traceability across ecosystems.

  • Cybersecurity Maturity Model Certification (CMMC)

    Cybersecurity Maturity Model Certification (CMMC) is a cybersecurity assessment framework used by the United States Department of Defense (DoD) to evaluate and verify the cybersecurity maturity of defense contractors and certain suppliers. It defines a tiered set of practices and processes that organizations implement and then have assessed by accredited third-party assessors to determine whether they can handle specific categories of defense-related information.

    Scope and purpose

    CMMC primarily applies to organizations that handle:

    • Federal Contract Information (FCI), which is information provided by or generated for the U.S. government under contract and not intended for public release.
    • Controlled Unclassified Information (CUI), which includes sensitive technical data, drawings, specifications, and other information that requires safeguarding but is not classified.

    In industrial and manufacturing environments, CMMC is relevant to companies that design, manufacture, test, or maintain defense-related products or components, and that store or transmit CUI or FCI in their IT or OT systems, MES, ERP, PLM, or quality systems.

    Key concepts

    • Maturity levels: CMMC defines multiple cybersecurity maturity levels, each associated with a set of practices and processes. Higher levels require more comprehensive and institutionalized controls.
    • Mapped practices: Many CMMC practices are aligned with existing standards and guidance, particularly NIST SP 800-171 for protection of CUI, as well as other NIST and federal cybersecurity references.
    • Third-party assessment: For applicable contracts, organizations are assessed by authorized CMMC Third-Party Assessment Organizations (C3PAOs). The outcome is a maturity level determination used by the DoD in contract award decisions.
    • Contractual requirement: Specific CMMC levels may be listed in solicitations and contracts, indicating the minimum level an organization must be assessed at to be eligible for award.

    Operational meaning in manufacturing

    Within manufacturing, aerospace, and other regulated sectors, CMMC affects how organizations design and operate both IT and OT environments that process CUI or FCI. Typical operational implications include:

    • Identifying where CUI resides across MES, ERP, PLM, QMS, file shares, and engineering tools.
    • Implementing access control, logging, and monitoring for systems that store or transmit CUI, including shop-floor terminals and connected equipment.
    • Defining processes for change control, configuration management, and incident response that meet CMMC-aligned practices.
    • Coordinating with suppliers and subcontractors that may also handle CUI and need to align with applicable CMMC expectations.

    Relationship to other frameworks

    • NIST SP 800-171: CMMC incorporates and builds on many of the NIST 800-171 requirements for protecting CUI in non-federal systems.
    • DFARS clauses: Defense Federal Acquisition Regulation Supplement (DFARS) clauses often reference NIST 800-171 and CMMC-related obligations for contractors and subcontractors.
    • Other cybersecurity standards: Organizations may map controls from ISO 27001, NIST 800-53, and industrial cybersecurity standards such as IEC 62443 to CMMC practices as part of their internal alignment.

    Common confusion

    • CMMC vs. NIST 800-171: NIST 800-171 is a set of requirements for protecting CUI; CMMC is a certification-oriented framework that incorporates and assesses implementation of those and additional practices.
    • CMMC vs. general cybersecurity: CMMC is not a complete global cybersecurity standard for all industries. It is a DoD-focused model used to evaluate and document cybersecurity maturity for defense contracting.

    Manufacturing-relevant examples

    • A precision machining supplier to a defense OEM implements role-based access control and logging on its MES and file servers, then undergoes a CMMC assessment to demonstrate its maturity level for handling CUI-labeled drawings.
    • An aerospace MRO provider segregates networks and hardens workstations used to access technical orders and maintenance data that qualify as CUI, documenting these measures to align with CMMC practices.

  • SL 3

    SL 3 commonly refers to Security Level 3 in industrial control system and operational technology (OT) cybersecurity models. It represents a target level of protection where systems are expected to withstand intentional, sophisticated attempts to compromise confidentiality, integrity, or availability by attackers with moderate resources and specific knowledge of the system.

    What SL 3 typically includes

    In industrial and manufacturing environments, SL 3 generally implies:

    • Strong authentication and authorization for users and services
    • Hardened configurations and minimized attack surface on controllers, servers, and network devices
    • Network segmentation, firewalls, and controlled remote access
    • Monitoring and logging of security-relevant events
    • Change control and controlled deployment of firmware, software, and configurations
    • Protections against common malware and targeted intrusion attempts

    SL 3 is usually applied to systems whose compromise could cause major safety, quality, regulatory, or business impacts, such as critical batch controllers, safety-related interlocks, or plantwide historians used as records in regulated environments.

    What SL 3 is not

    SL 3 is not a specific product label or certification. It is a targeted level of security requirements for a system or zone, usually defined as part of a risk-based cybersecurity program. Individual components (PLCs, firewalls, MES, etc.) might support or enable SL 3, but the level applies to the overall architecture and controls, not to a single device in isolation.

    Relation to standards

    Security levels such as SL 1 through SL 4 appear in several OT-focused cybersecurity frameworks. In these contexts, SL 3 usually represents protection against intentional, knowledgeable attackers with moderate resources, higher than basic protection for accidental or casual threats (often associated with SL 1 or SL 2), and below the most stringent level used for highly critical or national-level targets (often SL 4).

    Operational use in manufacturing

    In practice, “aiming for SL 3” means defining and implementing a set of controls, procedures, and technical safeguards appropriate for systems with significant risk. For example:

    • Defining an SL 3 security zone for a regulated production line with safety and quality-critical controls
    • Requiring multifactor authentication and strict access control for administrative functions on MES or batch systems
    • Implementing strict change management and validation for configuration and software updates in that zone

    The decision to target SL 3 is typically based on a documented risk assessment, taking into account process criticality, safety and environmental impact, product quality, regulatory exposure, and the feasibility of compensating controls in existing (brownfield) plants.

    Common confusion

    • SL 3 vs. device capabilities: A device advertised as supporting features for SL 3 does not mean the installed system achieves SL 3. The achieved security level depends on design, configuration, and operation.
    • SL 3 vs. compliance: Targeting or describing a system as SL 3 is not a statement of legal or regulatory compliance. It is a security design objective that may support broader compliance programs.
    • SL 3 vs. SL 4: SL 4 usually aims to resist highly resourced, highly motivated attackers, often beyond what is practical for many typical manufacturing systems. Not all systems are expected to reach SL 3 or SL 4; the appropriate target level is risk-based.

  • Defense Federal Acquisition Regulation Supplement (DFARS)

    The Defense Federal Acquisition Regulation Supplement (DFARS) is the U.S. Department of Defense (DoD) supplement to the Federal Acquisition Regulation (FAR). It provides additional rules, clauses, and procedures that apply specifically to contracts and subcontracts involving the DoD.

    What DFARS covers

    DFARS addresses topics that are unique or especially important to defense procurement. These commonly include:

    • Safeguarding controlled unclassified information (CUI) and covered defense information (CDI)
    • Cybersecurity requirements for defense contractors and subcontractors (for example DFARS 252.204-7012)
    • Reporting of cybersecurity incidents that affect defense information systems
    • Use and control of technical data, including export-controlled information
    • Special sourcing, domestic preference, and specialty metals rules
    • Industrial base, subcontracting, and supply chain requirements specific to defense

    DFARS is organized into parts, subparts, and sections that mirror the structure of the FAR, and it is implemented through clauses that are included in contracts and purchase orders issued by DoD contracting officers.

    DFARS in manufacturing and industrial operations

    In industrial and manufacturing environments that support defense programs, DFARS most often shows up as specific contract clauses that drive requirements for:

    • Information systems and network security controls applied to OT and IT environments handling defense data
    • Alignment with security frameworks referenced by DFARS (such as NIST SP 800-171 for protecting CUI)
    • Data handling rules for technical drawings, NC programs, work instructions, and MES/ERP data that contain defense information
    • Flow-down of DFARS clauses to suppliers, machine shops, special processors, and other subcontractors
    • Incident reporting workflows and record-keeping when cyber events affect covered systems

    Operationally, this can influence how MES, ERP, PLM, quality systems, and file repositories are configured, how access is controlled, and how audit evidence is generated and retained to demonstrate that contract clauses are being followed.

    Relationship to other regulations and standards

    DFARS is related to, but distinct from:

    • FAR (Federal Acquisition Regulation): FAR sets baseline federal acquisition rules. DFARS adds DoD-specific requirements on top of FAR.
    • NIST SP 800-171: Often referenced by DFARS clauses as the security control framework for protecting CUI in non-federal systems.
    • CMMC (Cybersecurity Maturity Model Certification): A DoD program that builds on NIST SP 800-171 and DFARS requirements to assess and verify contractor cybersecurity practices.

    Common confusion

    • DFARS vs DFARS 252.204-7012: DFARS is the entire DoD supplement to FAR. DFARS 252.204-7012 is a specific contract clause within DFARS that focuses on safeguarding covered defense information and cyber incident reporting.
    • DFARS vs CMMC: DFARS is a regulatory supplement that defines contract requirements. CMMC is an assessment and maturity model used to evaluate whether contractors meet certain cybersecurity expectations, many of which originate from DFARS and NIST SP 800-171 references.

    Context for regulated manufacturers

    For manufacturers and industrial operations that build parts, assemblies, or systems for the DoD, DFARS commonly determines how digital technical data may be stored and shared, which environments (for example, government clouds or specific hosting regions) are acceptable, and what kinds of cybersecurity controls and incident response processes must be in place across the supply chain.

  • Data Minimization

    Data minimization commonly refers to the practice of collecting, using, sharing, and retaining only the minimum amount of data needed to achieve a clearly defined purpose. In regulated industrial and manufacturing environments, it is applied to both personal data and operational data stored or processed in MES, ERP, PLM, quality, and OT/IT systems.

    Core elements of data minimization

    Data minimization typically includes:

    • Purpose limitation: Defining why data is needed before collection and aligning data fields with that purpose.
    • Scope limitation: Avoiding unnecessary fields, attributes, and data sources that are not essential to the process or requirement.
    • Access limitation: Restricting visibility of sensitive data to only those roles that require it to perform defined tasks.
    • Retention limitation: Keeping data only for as long as it is needed to support operations, traceability, regulatory, or contractual requirements.

    Data minimization in manufacturing and OT/IT systems

    Within industrial operations, data minimization appears in system design and day-to-day workflows, for example:

    • MES and shop floor systems: Configuring work-order, traveler, and quality forms to capture only the required fields for traceability, compliance, process control, and performance monitoring.
    • ERP, PLM, and integration layers: Limiting which fields are replicated between systems so only necessary identifiers, specifications, and quality results flow across interfaces.
    • Access control and views: Designing role-based views so operators, engineers, quality, and suppliers see only the data elements needed for their responsibilities.
    • Supplier and customer data handling: Restricting externally shared data (e.g., drawings, test data, traveler details) to what is needed to execute the work or demonstrate conformity.
    • Personal data on the shop floor: Minimizing storage of direct identifiers (such as full personal details) in production systems when badge IDs or role identifiers are sufficient.

    Relationship to privacy, security, and compliance

    Data minimization is a recurring principle in data protection and cybersecurity frameworks. In manufacturing, it supports:

    • Privacy requirements: Reducing collection of personal information about employees, contractors, and visitors when not required for workforce management or safety.
    • Cybersecurity and export control: Limiting the volume and distribution of controlled technical data (for example, export-controlled or sensitive defense information) within and between systems.
    • Audit and evidence management: Keeping evidence needed for quality and regulatory audits while avoiding storage of additional, nonessential data fields that increase risk and complexity.

    Operational considerations

    Applying data minimization in industrial operations usually involves:

    • Reviewing forms, interfaces, and integrations to remove unused or redundant fields.
    • Defining data dictionaries and purpose statements for key datasets in MES, ERP, PLM, and QMS systems.
    • Coordinating with quality, IT, security, and engineering teams so minimization does not compromise required traceability or product history.
    • Aligning retention schedules with regulatory and customer record-keeping requirements while avoiding indefinite storage.

    Common confusion

    • Data minimization vs. data reduction or compression: Data minimization is about deciding which data to collect and keep at all, not about compressing or aggregating data for storage savings.
    • Data minimization vs. data masking: Masking and anonymization hide or transform data values. Data minimization focuses on whether the data needs to be collected, stored, or shared in the first place.