Connect981 – Content Dev

Glossary Tag: risk detection

  • IT

    IT, short for Information Technology, commonly refers to the systems, infrastructure, software, and services used to create, process, store, secure, and transmit digital information within an organization. In industrial and manufacturing environments, IT typically covers business and enterprise systems, data centers, corporate networks, and cloud services, as distinct from plant-floor operational technology (OT).

    Scope in industrial and regulated environments

    In manufacturing organizations, IT usually includes:

    • Enterprise applications such as ERP, PLM, LIMS, QMS, CRM, and HR systems
    • Office productivity and collaboration tools, email, and document repositories
    • Corporate and site-wide networks (LAN, WAN, VPN, Wi-Fi) and internet connectivity
    • Servers, storage, virtualized environments, and cloud platforms
    • Directory services, identity and access management, and user account provisioning
    • Enterprise cybersecurity controls such as firewalls, endpoint protection, and monitoring tools

    IT departments in regulated industries often work closely with quality, compliance, and operations teams to support validated systems, data integrity practices, and secure interfaces between IT systems and OT systems such as SCADA, DCS, and MES.

    Role in security and compliance

    Within information security frameworks such as ISO 27001, IT commonly represents a major portion of the information assets and infrastructure in scope. This can include:

    • Networks and communication links that connect manufacturing sites and corporate locations
    • Systems that store or process regulated records, technical data, or confidential information
    • Supporting services like backup, recovery, logging, and centralized administration

    IT responsibilities in this context typically cover implementing and operating security controls, managing changes to systems and networks, and coordinating with OT teams where there are shared or boundary systems.

    Common confusion

    IT vs OT: IT focuses on business and enterprise information systems, while OT (Operational Technology) refers to the hardware and software that monitor or control physical equipment and processes on the shop floor. In modern plants, IT and OT often converge in areas such as MES, data historians, and edge gateways, which require clear ownership and security boundaries.

    IT vs IS: IT refers to the technology and systems themselves, while information security (IS) or cybersecurity refers to the protection of those systems and the information they handle. IT teams frequently operate or host security controls but are not identical to the security function.

    Relation to ISO 27001 scope

    When defining the scope of an ISO 27001 Information Security Management System (ISMS) in a manufacturing company, IT elements usually form a substantial part of what is included. The scope statement often clarifies which IT networks, applications, data centers, and cloud services are covered, and how shared IT/OT components are treated, especially in brownfield environments with legacy systems and constrained change windows.

  • Nonconformance Code

    A nonconformance code is a standardized identifier used to classify a nonconformance in a quality or manufacturing system. It commonly appears as a short alphanumeric value, picklist option, or controlled label in records such as NCRs, inspection results, supplier issues, scrap reports, or CAPA-related workflows.

    The code does not describe the entire event by itself. It is a structured way to categorize the issue so that people and systems can sort, trend, route, report, and analyze nonconformances consistently across products, work centers, suppliers, or sites.

    What it typically includes

    • The type of nonconformance, such as dimensional, documentation, material, process, or labeling issue

    • Sometimes the source or point of detection, such as incoming inspection, in-process inspection, final inspection, or customer return

    • Sometimes disposition or workflow classification, depending on how the quality system is configured

    In digital quality systems, a nonconformance code may drive reporting logic, approvals, escalation paths, or links to downstream activities such as MRB review, rework, scrap tracking, supplier follow-up, or corrective action.

    What it is not

    A nonconformance code is not the same as the full nonconformance record. The full record usually includes details such as part or batch affected, requirement not met, quantity, evidence, containment, disposition, and approvals. The code is only one controlled data element within that record.

    It is also not necessarily a root cause code. Some organizations use separate coding structures for defect type, cause, containment, and disposition to avoid mixing problem description with cause analysis.

    Common confusion

    Nonconformance code is often confused with defect code, rejection code, disposition code, or root cause code. These may overlap in some systems, but they are not always interchangeable:

    • A defect or rejection code usually identifies what was found wrong

    • A disposition code usually identifies what will be done with the affected item, such as rework or scrap

    • A root cause code usually identifies why the issue happened after investigation

    Organizations sometimes use one code set for several of these purposes, but the distinction matters for reporting accuracy and trend analysis.

    Manufacturing context

    In manufacturing and regulated environments, nonconformance codes support more consistent data capture across MES, QMS, ERP, and supplier quality workflows. For example, a receiving inspector might select a code for a material certification mismatch, while an in-process operator or quality technician might select a code for an out-of-tolerance feature. When codes are standardized, quality teams can compare patterns across jobs, lines, products, and suppliers more reliably.

  • bottleneck analysis

    Bottleneck analysis is the systematic identification and evaluation of the process step, resource, equipment, material flow, or decision point that limits overall throughput. In manufacturing, it is used to understand where work is waiting, capacity is constrained, or production flow is being slowed.

    The analysis commonly uses data such as cycle time, queue time, work-in-process, downtime, changeover time, labor availability, yield loss, and schedule adherence. It may be performed with shop-floor observations, value stream mapping, MES data, ERP schedule data, or operational performance metrics such as OEE and non-production time.

    A bottleneck is not always a permanently fixed asset or workstation. It can shift by product mix, staffing, material availability, inspection load, engineering holds, or maintenance conditions. Bottleneck analysis should also not be confused with root cause analysis, although the two are often connected. Bottleneck analysis identifies where flow is constrained; root cause analysis examines why that constraint exists.

    In industrial systems, bottleneck analysis is commonly applied in capacity planning, scheduling, line balancing, continuous improvement, and performance monitoring. For example, an inspection station with long queues may be the current bottleneck even if upstream machining equipment has lower nominal capacity.

  • Purchase Order

    A Purchase Order (PO) is a formal commercial document issued by a buying organization to a supplier that authorizes the purchase of specified goods or services under defined terms and conditions. It is a key control instrument in procurement and financial processes, especially in industrial and regulated manufacturing environments.

    Core characteristics

    A Purchase Order typically includes:

    • Unique PO number for identification and traceability
    • Buyer and supplier information
    • Description of goods or services, including part numbers or SKUs
    • Quantities, prices, currency, and payment terms
    • Required delivery dates and delivery locations
    • Applicable quality, regulatory, or technical requirements
    • Reference to related contracts, quotes, or framework agreements

    In most organizations, Purchase Orders are created, approved, and maintained in an ERP, procurement, or financial system. They provide the commercial basis for receiving, inspection, and invoicing activities.

    Role in industrial and regulated environments

    In manufacturing and other industrial operations, a Purchase Order commonly serves to:

    • Control external spending by requiring authorization before purchase
    • Link incoming materials or services to cost centers, projects, or products
    • Support material traceability by associating received lots or serials with a PO number
    • Reference required specifications, certificates, or regulatory constraints for supplied items
    • Provide a contractual baseline for supplier performance and dispute handling

    On the shop floor, PO numbers are often used to identify which incoming materials, components, or outsourced services belong to a particular order, batch, or customer project. Inspection records, nonconformance reports, and supplier corrective actions may all reference the relevant PO.

    Interaction with other operational documents

    Purchase Orders are related to, but distinct from, several other common documents:

    • Work Orders (WO): A WO instructs internal or external resources to perform work (such as manufacturing, maintenance, or rework). A WO may depend on materials or services procured via one or more POs, but the WO governs execution, while the PO governs purchasing.
    • Production Orders / Manufacturing Orders: These define what to make, in what quantity, and by when. They may consume materials that were acquired under one or more POs.
    • Purchase Requisitions: Internal requests that precede approval and conversion into a formal PO.
    • Invoices: Supplier billing documents that typically reference a PO number for matching and approval.

    Common confusion

    Purchase Orders are commonly confused with:

    • Work Orders: A PO is a commercial agreement with a supplier. A WO is an instruction to perform work, often within MES, CMMS, or maintenance systems. They may reference each other but serve different control and traceability purposes.
    • Contracts: A PO may operate under an existing contract or framework agreement. The contract sets the broader legal relationship, while the PO specifies a particular transaction under that relationship.

    Context from the PO vs WO distinction

    In discussions that compare PO and WO, the Purchase Order represents the financial and commercial commitment recorded in ERP or procurement systems, while the Work Order represents operational work instructions in systems such as MES or CMMS. Understanding this separation helps maintain clear boundaries between purchasing control, production or maintenance execution, and compliance documentation.

  • bill of materials

    Core meaning

    A **bill of materials** (BOM) is a structured list that specifies all components, raw materials, subassemblies, and sometimes services required to manufacture a defined product or execute a defined batch, including their quantities and basic identifying information.

    In industrial and regulated manufacturing environments, the BOM commonly:

    – Is defined and maintained in ERP, PLM, or product definition systems
    – Includes material identifiers, descriptions, units of measure, and required quantities
    – References engineering or product revisions to tie materials to a specific version of the product
    – Serves as a reference for planning, procurement, inventory management, and production execution

    A BOM describes **what** is needed to build a product, not **how** or **when** work is performed.

    Typical structure and levels

    BOMs are often hierarchical and may include:

    – **Top-level (finished good) BOM**: Lists main subassemblies and key materials that make up the final product
    – **Subassembly BOMs**: Define components for intermediate assemblies used within the top-level product
    – **Phantom or logical BOMs**: Groupings used for planning or design that may not exist as separate stocked items

    Depending on system and practice, BOMs may also identify alternates or substitutes, packaging materials, and labeling components when they are explicitly required to produce or release the product.

    Use in manufacturing workflows

    In integrated manufacturing environments, BOMs are used to:

    – Drive **material requirements planning** (MRP) and procurement in ERP systems
    – Define expected material consumption for **costing** and financial tracking
    – Inform **MES** or other shop-floor systems of required components for an order or batch
    – Support **traceability** by providing the expected structure against which actual material lots or serials are recorded

    During production, the BOM is typically linked to:

    – A **routing** or process definition (how work is done)
    – **Work orders**, production orders, or batch records (what is executed and when)
    – **Material master** data for each item listed

    Site context: BOM in MES–ERP integration and costing

    For program or product cost tracking across MES and ERP, the BOM commonly:

    – Resides and is maintained in ERP or PLM as the **authoritative product structure**
    – Provides the expected component list and standard quantities used to calculate standard or planned costs
    – Acts as the reference against which MES reports **summarized actual consumption** (by material ID and quantity) back to ERP at defined intervals

    In this context, MES usually does not author the BOM but uses it to validate material usage and ensure that recorded consumption aligns with the qualified product definition.

    Boundaries and exclusions

    A bill of materials **includes**:

    – Physical components, raw materials, and subassemblies
    – Sometimes non-stock items when they are integral to product composition (e.g., labels, certain consumables)

    A bill of materials **does not inherently include**:

    – Detailed work instructions, sequence of operations, or cycle times (these belong to routings or manufacturing instructions)
    – Real-time production data or yield results
    – Quality tests and acceptance criteria (these are typically defined in specifications or control plans)

    Some organizations maintain separate BOM types, such as **engineering BOM (EBOM)** and **manufacturing BOM (MBOM)**, to distinguish design intent from the structure used for actual manufacturing and sourcing.

    Common confusion and related terms

    – **BOM vs. recipe/formula**: In process industries, a *recipe* or *formula* includes process parameters and instructions in addition to material quantities. The BOM portion is the structured list of materials and quantities.
    – **BOM vs. routing**: A BOM defines *what materials* are required; a routing defines *how and in what sequence* operations are performed.
    – **BOM vs. product specification**: Specifications describe properties and performance requirements; the BOM lists the materials that make up the product.

    Understanding these distinctions helps ensure that BOMs are used consistently for planning, costing, and execution across ERP, MES, and quality systems.

  • control family

    A control family is a grouped set of related security, privacy, quality, or safety controls that share a common objective or topic within a formal framework or standard. Control families provide a structured way to organize individual controls so that organizations can plan, implement, and assess them systematically.

    What a control family includes

    In practice, a control family typically includes:

    • A collection of individual controls that address a similar risk area, process, or function, such as access control, configuration management, or incident response.
    • Sometimes, control enhancements or sub-controls that refine or strengthen a base control.
    • Framework-specific identifiers and labels that help with documentation, traceability, and audits.

    Control families appear in many frameworks used in industrial and regulated environments, including cybersecurity, information security, and quality management standards. They are used to organize requirements across OT and IT systems, MES/ERP integrations, data integrity, and other operational processes.

    Examples in common frameworks

    Examples of control families include:

    • NIST SP 800-53: Families such as Access Control (AC), Configuration Management (CM), System and Information Integrity (SI), and Audit and Accountability (AU). Each family contains multiple numbered controls and enhancements.
    • Other security and privacy frameworks: Similar groupings like identity and access management, change management, business continuity, or vendor management.
    • Quality and operational frameworks: Groupings such as document control, nonconformance and CAPA, equipment maintenance, or training and competence, even if they are not always labeled explicitly as “families.”

    How control families are used operationally

    In industrial and manufacturing contexts, control families are used to:

    • Structure policies and procedures (for example, a set of OT access control procedures aligned to an Access Control family).
    • Map technical and procedural controls in MES, ERP, QMS, and OT systems to specific framework requirements.
    • Plan assessments and audits by reviewing each family to confirm that required controls are defined, implemented, and evidenced.
    • Support risk analysis by viewing gaps and treatment plans by family (for example, all gaps in configuration management).

    Common confusion

    • Control family vs. control: A control is a single requirement or safeguard. A control family is a group of such controls organized around a shared topic.
    • Control family vs. baseline: A baseline is a selected set or level of controls (often across many families) for a given risk profile. A family is a topic-based grouping within the overall catalog of controls.
    • Control family vs. process area or domain: Some standards use terms like “domains” or “process areas” instead of “families.” These often serve the same organizational purpose but may be defined differently by each framework.

    NIST SP 800-53 context

    In NIST SP 800-53, a control family is a labeled group of security and privacy controls (for example, AC, AU, CM) that organizes the catalog. When counting or scoping controls for an implementation, organizations often determine which control families and corresponding baselines apply to their environment, including IT and OT systems that support manufacturing operations.

  • technical data

    Technical data commonly refers to detailed information that describes the design, manufacture, operation, maintenance, or testing of a product, system, or process. In industrial and regulated environments, it often has specific handling, export control, and information security implications.

    What technical data typically includes

    In manufacturing and industrial operations, technical data often covers:

    • Engineering designs and drawings, including CAD models and schematics
    • Manufacturing process instructions, routings, and control plans
    • Bill of materials (BOM) details beyond commercial part descriptions
    • Test methods, qualification procedures, and acceptance criteria
    • Product performance characteristics and tolerance data
    • Software source code or configuration details for embedded or control systems
    • Maintenance manuals, repair instructions, and overhaul procedures

    This information may exist in PLM, MES, ERP, document management, and quality systems, or as files exchanged with suppliers and customers.

    What technical data usually excludes

    Depending on the regulatory regime, technical data typically does not include:

    • Purely commercial or marketing materials (price lists, brochures, sales quotes)
    • Basic product descriptions that do not reveal detailed design or manufacturing know-how
    • General engineering knowledge that is widely taught or publicly available

    However, the exact boundary between technical data and non-technical information is defined by the applicable regulations, contracts, or internal policies.

    Technical data in regulated environments

    In many jurisdictions, technical data is a defined term in export control and defense-related regulations. In those contexts it can trigger specific obligations for:

    • Access control and user authorization within OT/IT systems
    • Cross-border transfers (email, file sharing, cloud storage, supplier portals)
    • Use of external service providers for design, analysis, or manufacturing
    • Recordkeeping and traceability of who accessed or shared certain documents

    Manufacturers often classify technical data to align with export control regimes or customer contract requirements and configure MES, PLM, and document control systems to enforce those classifications.

    Operational handling in manufacturing systems

    In day-to-day operations, technical data appears as:

    • Digital work instructions and standard operating procedures on the shop floor
    • Controlled drawings and specifications linked to part numbers and revisions
    • NC/CNC programs, control logic, and machine parameter sets
    • Test limits and calibration data used in inspection or automated testing

    Organizations typically govern technical data through document control, configuration management, and access control workflows. These workflows may integrate across MES, ERP, PLM, QMS, and content management systems to ensure that only authorized users can access specific technical data and that correct revisions are used in production.

    Information security and data loss considerations

    Because technical data can contain sensitive intellectual property or controlled information, it is often a focus area for information security and data loss prevention. Controls can include:

    • Role-based access control and segregation of duties
    • Network segmentation between OT and IT systems that store or process technical data
    • Monitoring and restrictions on file transfer, removable media, and printing
    • Encryption of repositories and communication channels where technical data is stored or transmitted

    Standards-based information security programs often require organizations to identify and classify technical data, assess risks related to its transfer and storage, and implement appropriate technical and procedural controls.

    Common confusion

    • Technical data vs. personal data: Technical data describes products and processes, while personal data relates to identifiable individuals. Both can be sensitive but are governed by different rules.
    • Technical data vs. trade secrets: Some technical data may qualify as trade secrets, but not all. Trade secret status depends on legal criteria and protection measures, not only on the type of information.
    • Technical data vs. operational data: Operational data (for example, machine telemetry or production counts) describes performance and events. Technical data describes how products are designed and manufactured. In some systems, both are stored together but are conceptually different.

    Link to data loss prevention and security standards

    In information security standards and risk assessments, technical data is often treated as a sensitive information category that requires controls on transfer, storage, and access. Data loss prevention tools, secure collaboration platforms, and controlled document workflows are examples of mechanisms that may be used to reduce the risk of unauthorized disclosure or leakage of technical data, especially when that data is subject to export controls or customer-imposed restrictions.

  • GRC

    GRC stands for governance, risk, and compliance. It commonly refers to a coordinated approach, set of processes, and supporting tools used by an organization to direct and control operations, manage risks, and meet regulatory and internal policy requirements in a consistent and traceable way.

    Core components of GRC

    In industrial and manufacturing environments, GRC typically includes:

    • Governance: How decisions are made and overseen. This covers roles, responsibilities, policies, standards, and escalation paths that direct how OT, IT, quality, safety, and security are managed.
    • Risk: Identification, assessment, treatment, and monitoring of risks, such as cyber risks in OT/ICS, safety risks, supply chain risks, and quality or compliance risks.
    • Compliance: Processes to interpret and implement external requirements (laws, regulations, standards) and internal policies, along with evidence management to show that required controls and procedures are followed.

    Operational meaning in manufacturing and OT

    In regulated manufacturing and industrial operations, GRC activities commonly include:

    • Defining and maintaining policies and standards for OT and IT systems, including security baselines and change control.
    • Maintaining control frameworks mapped to regulations and standards (for example mapping NIST SP 800-53 controls to the NIST Cybersecurity Framework for OT/ICS environments).
    • Conducting risk assessments for production systems, MES/ERP integrations, data flows, and third-party services.
    • Tracking issues, exceptions, and remediation actions (for example for cyber findings, audit findings, or quality deviations that have compliance impact).
    • Collecting and organizing audit-ready evidence from shop-floor systems, quality systems, and enterprise platforms.
    • Reporting risk posture, control coverage, and compliance status to leadership and regulators.

    Organizations may use dedicated GRC platforms or integrate GRC practices with existing tools such as ticketing systems, document control systems, MES, and cybersecurity monitoring solutions.

    Common confusion

    • GRC vs. cybersecurity: Cybersecurity is one risk domain managed within GRC. GRC is broader and also includes financial, operational, safety, and compliance risks.
    • GRC vs. quality management: Quality management focuses on product and process quality. GRC focuses on organizational governance, risk, and compliance. In regulated manufacturing, quality systems often feed evidence and risk data into the broader GRC framework.
    • GRC as a tool vs. a discipline: GRC is a management discipline and set of processes. GRC software tools support these processes but do not define them by themselves.

    Relation to the source context

    In the context of using NIST SP 800-53 to show NIST Cybersecurity Framework posture for OT/ICS, GRC provides the structure to map controls, aggregate risk and maturity information, maintain evidence for assessments, and report cybersecurity posture to leadership as part of an overall risk and compliance program.

  • Subgroup discovery

    Subgroup discovery is a data analysis method used to identify subsets of records that show a pattern, behavior, or outcome that differs meaningfully from the overall population. It is commonly used when a team wants to know not just what is happening on average, but which combinations of conditions are associated with unusually high scrap, low yield, delayed cycle time, quality escapes, or other operational signals.

    In manufacturing and regulated operations, subgroup discovery often works on production, quality, maintenance, or process data. A subgroup might be defined by a combination of attributes such as product family, machine, shift, material lot, supplier, operator qualification, environmental condition, or routing step. The result is not a single forecast or control limit, but a description of a subset that stands out statistically or operationally.

    What it includes and excludes

    Subgroup discovery generally includes:

    • Searching for data subsets with unusually high or low target values
    • Using interpretable conditions to describe those subsets
    • Comparing subgroup behavior against the full dataset or a baseline population
    • Ranking findings by measures such as significance, lift, coverage, or effect size

    It does not usually mean:

    • General clustering without a defined target outcome
    • Root cause confirmation on its own
    • Statistical process control charts or rational subgrouping in SPC
    • A complete causal model of the process

    How it appears in operations

    In practice, subgroup discovery may be used to scan MES, QMS, historian, LIMS, ERP, or maintenance data for combinations linked to specific outcomes. For example, an analysis might show that one subgroup of parts processed on a certain line, during a certain shift, with a specific supplier lot, has a much higher nonconformance rate than the plant average. That result can then be reviewed as a candidate signal for investigation.

    This makes subgroup discovery useful for surfacing localized issues that averages can hide, especially in high-mix production, multi-step processes, and environments where traceability data is available across systems.

    Common confusion

    Subgroup discovery is often confused with clustering and with SPC subgrouping.

    • Clustering groups records by similarity, usually without a predefined target variable. Subgroup discovery looks for subsets that are unusual with respect to a chosen outcome.

    • In SPC, a subgroup usually means a small set of observations collected under similar conditions for control charting. That is a different concept from subgroup discovery in data mining and analytics.

    • Association rule mining finds co-occurring conditions or events. Subgroup discovery is more focused on subsets that show a distinct target behavior or performance level.

    Why the term matters

    The term commonly appears in advanced analytics, process mining, and machine learning discussions where teams need interpretable findings rather than only black-box predictions. In regulated manufacturing, that interpretability can matter because discovered subgroups can be reviewed against process context, traceability records, and quality evidence before any operational conclusion is drawn.