Connect981 – Content Dev

RSC Topic: Cybersecurity & Regulatory Alignment

Practical handling of CMMC, NIST 800-171, DFARS, ITAR contexts.

  • Will ISO 27001 certification guarantee new business with primes?

    No. ISO 27001 certification does not guarantee new business with primes. It is one input into their supplier risk assessment, but contract awards still depend on capability, price, schedule, past performance, and your ability to meet program-specific security and regulatory requirements.

    What ISO 27001 actually does for you

    ISO 27001 can be valuable for work with primes because it:

    • Shows you have a structured information security management system (ISMS).
    • Supports internal governance, risk assessment, and continuous improvement.
    • Makes it easier to answer security questionnaires and audits with evidence.
    • Can shorten due diligence cycles, especially for IT/OT interfaces and data handling.

    For experienced primes, a mature, well-implemented ISMS is often more important than the certificate itself. They will look for how you run risk assessments, manage changes, and maintain traceability for controls over time.

    Why certification alone is not enough

    Primes usually treat ISO 27001 as a hygiene factor, not a differentiator:

    • It is not a compliance umbrella. ISO 27001 does not, by itself, satisfy DFARS, ITAR, export controls, CMMC, or proprietary prime-specific requirements.
    • Scope matters. Many certifications cover only corporate IT, not manufacturing networks, test stands, or engineering systems. Primes will probe that.
    • Implementation quality varies widely. A certificate does not prove that controls are consistently effective in a brownfield OT environment with legacy PLCs, MES, and ERP.
    • Program requirements differ. Some programs require specific frameworks (for example NIST SP 800-171 or IEC 62443 for OT) that ISO 27001 only aligns with at a high level.

    What primes usually look for beyond ISO 27001

    In regulated manufacturing and aerospace-grade environments, primes typically assess:

    • Mapping to their exact requirements: How your controls map to their security clauses, export control requirements, and flowdowns.
    • Control coverage for OT and engineering: Identity, network segmentation, logging, and change control across MES, SCADA, CNCs, test cells, PLM, and QMS, not just office IT.
    • Evidence and traceability: Availability of maintained policies, risk registers, access reviews, change records, and incident logs that tie back to defined controls.
    • Lifecycle realism: Whether your security model works with long-lived equipment that cannot be frequently patched or replaced.
    • Vendor and data chain management: How you control sub-tier suppliers and protect technical data and controlled unclassified information (CUI).

    These are evaluated alongside traditional supplier criteria such as capacity, quality performance, on-time delivery, and cost structure.

    How to use ISO 27001 to improve your chances with primes

    ISO 27001 can still be a strong enabler if you apply it pragmatically:

    • Align your ISMS to prime frameworks: Map ISO 27001 controls to NIST, CMMC, IEC 62443, and specific prime questionnaires. Maintain that mapping as a controlled document.
    • Extend scope into manufacturing: Where feasible, include OT, MES, and engineering systems in your risk assessments, even if they are not fully in the certification scope.
    • Harden the most exposed interfaces: Focus on interfaces where prime data enters your environment (file transfers, VPNs, portals, test data, digital work instructions).
    • Strengthen evidence management: Make it easy to produce dated, traceable records of access control, change approvals, incident handling, and training.
    • Be transparent about gaps: When responding to primes, pair ISO 27001 with a clear, realistic plan for any required controls that are not yet fully implemented.

    Brownfield realities and full-replacement pitfalls

    In most plants, IT and OT environments are heavily brownfield: mixed vendors, legacy controllers, custom MES, and long-lived test rigs. Trying to “rip and replace” systems purely to match a textbook ISO 27001 design is rarely practical. Qualification burden, downtime risk, and revalidation cost typically outweigh the benefits.

    A more sustainable pattern is to:

    • Layer security controls (segmentation, monitoring, access control) around existing MES/SCADA/ERP rather than replacing them.
    • Integrate ISO 27001 processes with existing change control, deviation, and validation workflows instead of creating parallel systems.
    • Accept that some controls will be risk-based compensating measures instead of ideal technical fixes, and document that rationale clearly.

    This kind of realistic, well-governed approach often carries more weight with primes than a certificate alone.

    Bottom line

    ISO 27001 certification can help you get in the door, reduce friction in security reviews, and demonstrate a disciplined approach to information security. It will not, by itself, guarantee new business with primes. You still need demonstrable control coverage across IT and OT, alignment to program-specific requirements, strong evidence, and competitive operational performance.

  • SDLC

    SDLC (Software Development Life Cycle) is the structured process used to plan, design, build, test, release, and maintain software systems. In industrial and regulated environments, SDLC typically applies to MES, SCADA, PLC programming tools, data historians, quality systems, and other OT/IT software that support manufacturing operations.

    The SDLC describes the end to end progression of software from concept through retirement. Common phases include:

    • Requirements and analysis: Understanding user needs, regulatory constraints, interface requirements, and system boundaries.
    • Design: Defining architectures, data models, interfaces, and security controls.
    • Implementation: Writing and configuring code, scripts, logic, and integrations.
    • Verification and validation: Testing functionality, performance, cybersecurity, and compliance behavior.
    • Deployment and release management: Moving software into production environments in a controlled way.
    • Operation and maintenance: Monitoring, patching, defect correction, and change control throughout the system’s life.
    • Retirement: Decommissioning software, migrating data, and documenting transitions.

    Use in industrial and regulated environments

    In manufacturing and OT contexts, SDLC practices are often formalized to provide traceability, documentation, and evidence that software changes are controlled. This can include version control, documented requirements and test cases, change approval workflows, and impact assessments for safety, quality, and cybersecurity.

    For industrial automation and control systems, secure SDLC approaches incorporate security activities into each phase, such as threat modeling, secure coding practices, vulnerability assessment, and security-focused testing. Standards like IEC 62443-4-1 define process requirements for a secure development lifecycle tailored to industrial systems.

    Operational perspective

    From an operational standpoint, SDLC typically shows up as:

    • Formal procedures for how MES or SCADA changes are requested, designed, implemented, tested, and released.
    • Required documentation (requirements, design descriptions, test records) that link software changes to production and quality impacts.
    • Evidence trails used in audits to demonstrate control of software affecting product quality, data integrity, and safety-related functions.

    Common confusion

    • SDLC vs. secure SDLC: SDLC is the general lifecycle process for software. A secure SDLC explicitly integrates cybersecurity activities and controls into each phase.
    • SDLC vs. PLC logic changes: Editing PLC or DCS logic can be part of an SDLC when treated as software development, but day to day parameter changes or setpoint adjustments in operations are usually handled under different procedures (for example, engineering change control or maintenance workflows).

    Context: IEC 62443-4-1

    Within the IEC 62443 framework, SDLC is addressed by IEC 62443-4-1 as a secure development lifecycle for industrial automation and control system products. IEC 62443-4-1 defines specific, auditable process requirements and documentation expectations that extend generic SDLC concepts with OT-focused security and long-lived system considerations.

  • ISMS scope

    ISMS scope is the formally defined boundary within which an Information Security Management System (ISMS) is established, implemented, maintained, and continually improved. It specifies which sites, functions, processes, systems, assets, and information are covered by the ISMS, and which are explicitly out of scope.

    In industrial and regulated manufacturing environments, ISMS scope commonly covers some combination of:

    • Physical locations such as specific plants, warehouses, laboratories, or corporate offices
    • Organizational units such as IT, OT, engineering, quality, or supply chain
    • Business processes such as batch manufacturing, release to ship, change control, or vendor management
    • Systems and infrastructure such as MES, ERP, SCADA, data historians, networks, and cloud services
    • Categories of information such as production data, quality records, technical data, or personal data

    Typical contents of an ISMS scope statement

    An ISMS scope is usually documented in a short, explicit statement. In manufacturing, it often includes:

    • A description of covered sites and legal entities (for example, specific plants rather than the whole enterprise)
    • The main processes and services included (for example, GMP production and supporting quality systems)
    • The types of information and assets protected (for example, batch records, formulas, machine configurations)
    • High-level exclusions and constraints, where certain sites, functions, or systems are out of scope
    • Dependencies on shared or corporate services such as networks, identity management, and cloud platforms

    The scope is used to decide where risk assessments apply, which controls must be implemented, and which areas are examined during internal and external audits.

    Operational relevance in manufacturing

    In multi-site or global manufacturing organizations, the ISMS scope can be limited to:

    • Selected production plants or regions
    • Specific regulated product lines
    • Operational technology (OT) environments only, or IT and OT together
    • Defined systems such as MES, LIMS, or batch control systems

    Even when the scope is narrow, shared infrastructure and cross-site data flows (for example, corporate Active Directory, centralized historians, or cloud analytics) typically must be addressed as dependencies. These dependencies are not always fully in scope, but their interfaces, responsibilities, and controls usually need to be documented to avoid gaps and unclear accountability.

    What ISMS scope is not

    The ISMS scope is not the same as:

    • Asset inventory: The scope defines boundaries and coverage; it does not list every individual asset.
    • Risk treatment plan: The scope describes what is covered; it does not specify which controls are chosen for each risk.
    • Network segmentation: The scope may align with network zones, but it is a management and audit boundary, not a technical topology by itself.

    Common confusion

    ISMS scope vs. certification scope: The ISMS scope describes where the management system applies. A certification scope, when present, describes what an external body evaluated. These are often aligned but are not automatically identical.

    ISMS scope vs. organizational scope: An ISMS can cover only part of an organization, such as selected plants or functions, even when the overall company is larger. This partial coverage must be made explicit in the documented scope.

    Context from regulated manufacturing

    In regulated manufacturing, defining ISMS scope often requires careful consideration of:

    • Shared IT/OT infrastructure used by both in-scope and out-of-scope plants
    • Cross-site data exchange, such as centralized quality systems or global MES instances
    • Corporate processes (for example, change management or supplier onboarding) that influence information security at the plants

    Clear scope definition, including interfaces to out-of-scope areas, helps avoid control gaps, overlapping responsibilities, and audit findings related to information security governance.

  • SR controls

    SR controls are documented security requirements that specify how systems, data, and interfaces must be protected. In regulated or contract-driven environments, the term usually refers to a defined set of security requirements from a formal standard or customer flow-down that suppliers and internal teams must interpret, implement, and maintain.

    What SR controls typically include

    SR controls commonly cover areas such as:

    • Access control and user authentication for manufacturing and business systems
    • Network security for OT and IT environments, including segmentation and remote access
    • System hardening, patching, and malware protection on shop-floor and enterprise assets
    • Data protection, including handling of technical data and production records
    • Monitoring, logging, and incident response expectations
    • Supplier and third-party access to production systems and data

    Each SR control typically states a desired security outcome or requirement (for example, restricting access to specific roles, encrypting data, or logging configuration changes). Organizations then design technical and procedural measures that satisfy the intent of the requirement in their specific environment.

    Operational meaning in manufacturing environments

    In industrial and manufacturing contexts, SR controls are applied across both OT and IT systems. They influence:

    • Configuration of MES, SCADA, PLCs, historians, and plant networks
    • How production and quality data are accessed, stored, and transmitted
    • Supplier connections to plant systems and shared data repositories
    • Change control around configuration, software updates, and security settings

    Not every SR control applies in every situation. Organizations often perform a scoping and applicability review, then document how each applicable control is addressed, any tailoring, and any compensating controls used when the control cannot be implemented as written.

    Relationship to standards and contracts

    The term “SR controls” is frequently used where security requirements are defined by:

    • Industry or cybersecurity standards
    • Customer or prime contractor security clauses and flow-downs
    • Internal corporate security baselines for plants and suppliers

    In these cases, SR controls form the checklist of required or expected security behaviors. Suppliers and internal facilities are generally asked to demonstrate how they meet the intent of the applicable controls, and to keep this documented under change control.

    Common confusion

    • Not the same as general “controls”: SR controls are a subset focused specifically on security requirements, while broader risk or quality controls may address safety, process stability, or product quality.
    • Not a specific technology: An SR control is a requirement. Firewalls, access rules, and procedures are examples of measures that can satisfy one or more SR controls.

    Context from supplier management

    When used in supplier discussions, SR controls usually refer to the security requirements that a supplier is expected to address for the systems and data in scope. Smaller or specialized suppliers may not implement every control exactly as written but are often expected to:

    • Determine which SR controls apply to their scope and data
    • Implement right-sized technical and procedural measures that meet the intent
    • Document applicability decisions, tailoring, and compensating controls
    • Maintain this documentation under configuration and change control

  • 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.

  • How does ISO 27002 help with Annex A control implementation?

    ISO 27002 supports Annex A implementation by expanding each Annex A control from ISO 27001 into more detailed guidance and examples. It is essentially a catalog of recommended information security controls and good practices that you can use to interpret what each Annex A control really means in day-to-day design, operation, and evidence generation.

    What ISO 27002 actually provides

    For each Annex A control, ISO 27002 typically gives you:

    • Purpose and rationale for the control (why it exists and what risk it is trying to mitigate).
    • Implementation guidance with suggested measures, process steps, and technical/organizational options.
    • Examples of applicable situations to help you judge when a control should be strengthened, adapted, or may reasonably be out of scope.
    • Links to related controls so you can design coherent control sets instead of isolated point solutions.

    This turns the relatively short Annex A text into something you can actually implement, review, and audit against in a structured way.

    How it helps in regulated industrial and OT-heavy environments

    In a brownfield manufacturing environment, Annex A by itself is often too high level to be directly actionable. ISO 27002 helps by:

    • Supporting risk-based tailoring: You can map ISO 27002 guidance to your actual OT constraints, legacy equipment, and safety/regulatory requirements, then decide which measures are realistic and high value.
    • Clarifying control intent: For controls that conflict with uptime, safety systems, or validation baselines (for example, patching or remote access), ISO 27002 clarifies the objective so you can design compensating controls instead of simply ignoring the requirement.
    • Structuring existing practices: Many plants already do aspects of access control, backup, change management, and vendor management. ISO 27002 gives you a reference structure to formalize these into documented, auditable controls tied to Annex A.
    • Informing integration choices: For plants with mixed MES, ERP, PLM, and QMS stacks, ISO 27002 helps define what evidence and control behaviors you actually need from each system before committing to large, disruptive replacements.

    Using ISO 27002 to design Annex A controls

    A practical way to use ISO 27002 with Annex A is:

    1. Start from Annex A: Treat Annex A as the mandatory control list for ISO 27001 conformity. Decide which controls are applicable via your risk assessment and Statement of Applicability.
    2. Consult the corresponding ISO 27002 section: For each applicable Annex A control, review ISO 27002 guidance to understand expected measures and common implementation patterns.
    3. Map to your current state: Identify which suggested measures you already have, which are partially covered, and which are missing or unrealistic given legacy systems, validation status, and operational risk.
    4. Specify plant-appropriate controls: Define the concrete control design for your environment (for example, how you will handle OT remote access or account provisioning on shared HMIs), referencing ISO 27002 guidance where it fits.
    5. Define evidence and ownership: Based on ISO 27002 examples, determine what logs, records, and reviews will demonstrate that the control operates as intended, and which role or function owns it.
    6. Embed in change control: Ensure any new or changed controls, especially those touching validated systems or safety-related equipment, go through your standard change, testing, and approval processes.

    Where ISO 27002 does not help

    There are clear limits:

    • No compliance guarantee: Using ISO 27002 does not in itself make you compliant or pass an audit. You still need a functioning ISMS, risk assessment, and evidence of control operation.
    • Not OT-specific: ISO 27002 is written for information security in general, not industrial control systems. Some guidance needs adaptation to coexist with IEC 62443 practices, safety instrumented systems, and vendor-locked equipment.
    • No direct mapping to every regulation: It does not replace sector-specific requirements (for example, GMP expectations, export control rules, or safety regulations). It can support them, but does not cover all obligations.
    • Not a design blueprint: It describes what “good” looks like at a principle level, but it will not design your network zones, choose your identity provider, or define plant-specific procedures.

    Coexistence with legacy systems and standards like IEC 62443

    In many regulated plants, OT cybersecurity is already guided by IEC 62443 or vendor hardening guides. ISO 27002 can still help:

    • For governance and process controls: Areas like policies, supplier management, HR security, logging review, and incident management are often weaker in OT programs; ISO 27002 gives structure to these.
    • For aligning IT and OT controls: It offers a common language to align IT security, corporate ISMS, and plant-level technical controls so that Annex A controls are consistently interpreted across domains.
    • For bridging to enterprise systems: When integrating OT with MES, ERP, QMS, and document control, ISO 27002 can help define minimum security expectations for interfaces, user provisioning, and data handling.

    Full replacement of existing OT security frameworks or validated systems with something designed purely around ISO 27002 is rarely realistic in aerospace, pharma, or other high-assurance environments, because of validation cost, downtime risk, supplier constraints, and long asset lifecycles. In practice, ISO 27002 is layered on top as a reference for governance and to close Annex A gaps without disrupting stable, qualified systems.

    How auditors typically use ISO 27002 in Annex A reviews

    While each auditor and certification body is different, ISO 27002 often influences Annex A assessments by:

    • Setting expectation ranges for what is normally considered adequate control design at a given risk level.
    • Providing a benchmark when you propose non-standard or compensating controls; auditors may check whether your approach still meets the intent described in ISO 27002.
    • Supporting consistency across sites, so controls such as access management, backup, and logging follow similar principles even when technical platforms differ.

    The key is to be explicit in your Statement of Applicability and supporting procedures about how you interpreted Annex A controls, where you followed ISO 27002 guidance directly, and where you made justified adaptations based on operational and regulatory constraints.

    Summary

    ISO 27002 helps with Annex A implementation by translating each control into more detailed intent, design options, and examples. In regulated manufacturing, it is most effective when used as a structured reference to tailor Annex A controls to real OT/IT constraints, document your design decisions, and define clear evidence, rather than as a prescriptive checklist or a replacement for existing validated systems and domain-specific standards.

  • 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.

  • Shadow CUI

    Core meaning

    Shadow CUI commonly refers to controlled unclassified information (CUI) that exists, is processed, or is transmitted outside of formally recognized, monitored, or managed environments.

    In practice, this is CUI that:

    – Resides in locations not designated as official CUI repositories (for example, local drives, personal cloud accounts, unregistered file shares)
    – Flows through tools or workflows that are not part of the documented CUI handling process
    – Is created through copying, exporting, screen captures, or derived work products that are not tracked in the official CUI inventory

    The term is typically used by analogy to “shadow IT” and is descriptive rather than formal or regulatory.

    Use in industrial and manufacturing environments

    In regulated industrial and manufacturing settings, shadow CUI can appear in:

    – Manufacturing documentation: unofficial copies of technical data, work instructions, or configuration details stored on laptops, USB drives, or local network folders
    – OT and MES data extracts: exports from MES, historians, LIMS, or quality systems containing design data, test results, or customer information that meet the definition of CUI but are saved outside approved systems
    – Email and collaboration tools: CUI content pasted into chat, collaboration platforms, or email threads not managed as part of the formal CUI environment
    – Engineering and maintenance workflows: screenshots, spreadsheets, or personal notes containing CUI (for example, system topology, controlled drawings, or test parameters) kept for convenience but not tracked

    In these contexts, shadow CUI is usually discussed as a visibility and governance problem: organizations cannot consistently apply their documented CUI handling, retention, or monitoring practices to information they do not know exists or cannot easily locate.

    Boundaries and what it is not

    Shadow CUI:

    – **Is** controlled unclassified information that meets applicable definitions or classifications but is stored or used outside the defined, managed CUI environment
    – **Is** a descriptive risk or governance concept, not an official data category or formal regulatory term
    – **Does not** create a new type of information; it is still CUI, but with unclear or informal ownership, storage, or control
    – **Does not** refer to classified information or public, unrestricted data

    It is distinct from:

    – **Official CUI repositories**: systems and locations explicitly designated and documented for handling CUI
    – **Shadow IT**: systems, applications, or infrastructure deployed without central IT knowledge or approval; shadow CUI can exist in shadow IT, but the terms are not interchangeable

    Common sources of confusion

    ### Shadow CUI vs. CUI

    – **CUI** is defined by content and applicable regulations or contracts.
    – **Shadow CUI** is defined by its *location and governance context*—it is CUI that is not under the intended controls, monitoring, or lifecycle management.

    ### Shadow CUI vs. shadow IT

    – **Shadow IT** focuses on unapproved technology (applications, services, devices).
    – **Shadow CUI** focuses on the data itself, which may live in both approved and unapproved tools, but outside documented handling practices.

    In manufacturing, it is possible to have:

    – Shadow IT with no shadow CUI (for example, a non-critical team chat tool used only for scheduling)
    – Shadow CUI in approved systems (for example, CUI copies stored in ad hoc directories of an otherwise approved file server)

    Site-context relevance

    On this site, shadow CUI is most relevant where industrial operations and manufacturing systems intersect with information governance, such as:

    – MES, historian, or quality system exports that contain CUI and are shared informally
    – Integration between OT and IT systems where CUI-related data is replicated into reporting or analytics environments not documented as CUI systems
    – Operational intelligence and shop-floor visibility tools that aggregate design, process, or customer data qualifying as CUI but are operated as general-purpose analytics platforms

    In these contexts, the term is used to describe visibility, control, and governance challenges around where CUI actually resides and flows across production, engineering, and support systems.