Connect981 – Content Dev

RSC Cluster: ISO 27001 for Aerospace and Industrial Operations

  • What are the most common ISO 27001 findings in manufacturing?

    In manufacturing, ISO 27001 findings usually cluster around a few patterns: incomplete scoping, weak basic controls on the shop floor, and poor evidence that controls actually operate as designed. The specific findings vary by plant, auditor, and integration maturity, but the themes below come up repeatedly.

    1. Incomplete or fuzzy scope for OT, MES, and test equipment

    Many manufacturing organizations define an ISO 27001 scope focused on corporate IT while leaving operations technology (OT) and production data only partially covered.

    • Common findings:
      • Production lines, test stands, PLC networks, and lab systems not clearly included or excluded in the Statement of Applicability.
      • Ambiguity about whether MES, historians, and QMS are in-scope when they run in plants but are hosted centrally.
      • No clear mapping of information security requirements to product, process, and quality data in OT systems.
    • Why it happens: Brownfield environments with legacy equipment, mixed vendors, and long asset lifecycles make scoping politically and technically difficult.

    2. Incomplete asset and information inventory

    Accurate inventories are a core ISO 27001 expectation, but plants often have large blind spots.

    • Typical gaps:
      • No consolidated inventory of OT assets (PLCs, HMIs, industrial PCs, data loggers, machine controllers).
      • Test benches, programming laptops, and engineering workstations missing from the asset list.
      • Information assets such as NC programs, routings, recipes, test data, and calibration records not classified or even listed.
      • Shadow systems (access databases, local spreadsheets, scripts) used for production decisions with no registration.
    • Manufacturing nuance: Many assets are embedded in machines that cannot easily be scanned or taken offline for discovery, and OEM support contracts sometimes constrain configuration visibility.

    3. Weak access control on shop floor and engineering systems

    Access control findings are very common, especially where IT identity practices did not extend into OT.

    • Common findings:
      • Shared generic accounts on HMIs, industrial PCs, test stations, and maintenance laptops.
      • No individual authentication for changes to machine parameters, PLC logic, or NC programs.
      • Inconsistent revocation of access for contractors, temp workers, and transferred employees.
      • Uncontrolled local admin rights on engineering workstations and programming tools.
      • Remote access to vendors without strong authentication, time-bound access, or robust logging.
    • Typical root causes: Legacy devices that do not support modern authentication, cultural resistance on the shop floor, and incomplete integration between corporate identity systems and plant assets.

    4. Insufficient change control for OT, MES, and automation

    ISO 27001 expects controlled changes to information systems. In many plants, IT change management is formal, but OT and automation changes are handled informally.

    • Frequent findings:
      • No formal process for changes to PLC code, robot programs, test sequences, or recipes.
      • Inadequate versioning and rollback capability for automation and MES configuration.
      • Security impact not assessed when process changes are implemented (for example, adding networked sensors, remote diagnostic access, or new data exports).
      • Poor linkage between change records, validation/qualification records, and security risk assessments.
    • Brownfield challenge: Upgrading or revalidating production systems can be expensive and downtime-constrained, so plants often defer security-motivated changes until auditors highlight the risk.

    5. Inadequate backup, recovery, and configuration management

    Backups exist for central IT systems, but production environments often have partial or inconsistent coverage.

    • Common issues:
      • No tested backups of PLC programs, recipes, or machine parameter sets.
      • Backups stored only locally on the same network segment or in ad hoc engineer-managed archives.
      • Lack of documented, tested recovery procedures for MES, SCADA, or key plant databases.
      • Recovery objectives (RPO/RTO) not defined or not realistic relative to production impact.
    • Impact on findings: Auditors often flag the gap between documented policies (for example, enterprise backup standards) and the actual state of OT and plant-level systems.

    6. Weak logging, monitoring, and incident handling in OT environments

    ISO 27001 requires detection and management of security events. OT environments frequently lag behind IT in this area.

    • Typical findings:
      • Limited or no central logging from PLCs, industrial PCs, and OT network devices.
      • No clear incident response process that covers production systems and cross-functional roles (operations, maintenance, IT, quality, EHS).
      • OT events not integrated with SIEM or monitored only through OEM tools that plants rarely review.
      • No correlation between cyber incidents and quality/nonconformance investigations.
    • Dependency: Achieving robust monitoring in OT often depends on vendor support, network segmentation quality, and the tolerance for adding monitoring tools without requalification.

    7. Removable media and data transfer controls

    Removable media are still widely used in manufacturing for NC programs, firmware, and recipes, and are a common source of findings.

    • Common findings:
      • No consistent controls for USB sticks used to move programs into CNC machines, printers, or testers.
      • Personal or unvetted media used to load software or diagnostics tools onto industrial PCs.
      • Lack of scanning procedures or quarantine steps before media is connected to OT assets.
      • No logging or traceability of how critical programs and data are moved between systems.
    • Brownfield reality: For older machines without network connectivity, removable media may be the only practical option, so organizations must design controls that work despite this constraint rather than assuming full elimination.

    8. Supplier, integrator, and OEM security oversight

    Manufacturing relies heavily on OEMs, system integrators, and outsourced services for systems that affect information security.

    • Typical auditor observations:
      • Supplier security requirements not aligned with ISO 27001 controls, especially for MES, OT integrators, and equipment OEMs that provide remote access.
      • No formal review of third-party access to production networks (for example, VPN tunnels, remote monitoring boxes).
      • Unclear ownership of patching and hardening responsibilities for vendor-supplied systems.
      • Limited due diligence for cloud services used to process production, maintenance, or quality data.
    • Constraints: Changing OEM practices or renegotiating contracts can be slow and may trigger requalification of validated systems.

    9. Policy, training, and awareness not adapted to plant realities

    Policies often exist on paper but are written for office staff, not for operators, technicians, and engineers.

    • Common findings:
      • General information security policies that do not mention OT, MES, or production-specific scenarios.
      • Training that covers phishing but not practical issues like handling USB drives for CNC programs or vendor remote access.
      • Operators and maintenance staff unaware of their specific responsibilities under ISO 27001 controls.
      • No evidence that training effectiveness is evaluated in production settings.
    • Tradeoff: Tailored training takes time away from production and often competes with safety and quality training, so it must be prioritized deliberately.

    10. Risk assessment and treatment not reflecting real plant risks

    ISO 27001 is risk-driven. Many findings arise because the risk assessment does not match operational reality.

    • Typical gaps:
      • Risk assessments performed centrally without plant input, missing realistic threat scenarios (for example, impact of OT ransomware on batch traceability or calibration data).
      • Underestimation of dependencies on single critical systems such as legacy MES, historians, or license servers for engineering tools.
      • No linkage between information security risks and existing risk frameworks used for safety, process, or quality.
      • Treatment plans not aligned with validation constraints, downtime restrictions, or OEM limitations, making them hard to implement.

    11. Documentation and evidence gaps

    ISO 27001 places strong emphasis on documented information and evidence that controls operate. In manufacturing, this often exposes inconsistencies between what is written and what happens during production.

    • Recurring findings:
      • Procedures updated for ISO 27001 on paper but not rolled out or followed in plants.
      • Missing or incomplete records for periodic reviews, access recertifications, and log reviews.
      • Security considerations not integrated into existing document control, change control, and validation processes.
      • Legacy systems operating outside formal documentation, for example, old test stands kept in service.
    • Dependency: Closing these gaps often depends on aligning ISO 27001 documentation with existing QMS, MES, and engineering document control, rather than creating stand-alone security documents.

    How brownfield constraints shape typical findings

    Most manufacturing plants operate brownfield environments with mixed generations of equipment, various MES and SCADA platforms, and heavy validation burdens. This shapes findings in several ways:

    • Some controls (for example, strong authentication, centralized logging) are difficult to retrofit into old equipment without major redesign or requalification.
    • Downtime windows are short, so remediation plans must be phased, and auditors may cite findings about slow implementation, not just initial gaps.
    • Full replacement of legacy systems purely for security reasons is rarely realistic; auditors look instead for documented risk acceptance, compensating controls, and clear roadmaps.

    Overall, the most common ISO 27001 findings in manufacturing are less about the absence of policies and more about inconsistent extension of those policies into OT, MES, and production data, constrained by long equipment lifecycles and integration debt.

  • What is the difference between ISO 27001 and GDPR?

    ISO 27001 and GDPR are related but fundamentally different. They interact, but one does not replace or guarantee the other.

    Core difference

    ISO 27001 is an international information security management standard. It describes how to set up and run an Information Security Management System (ISMS) to manage risks to information assets.

    GDPR is a law (the EU General Data Protection Regulation). It defines legal requirements for how organizations process, store, transfer, and protect personal data of individuals in the EU/EEA.

    Scope and focus

    • ISO 27001 scope:
      • Covers all information assets in scope (not just personal data): engineering data, process recipes, machine logs, MES/ERP databases, supplier documents, etc.
      • Focuses on risk management, controls, and continuous improvement of information security.
      • In a plant context, this includes OT networks, historian data, backups, remote access to equipment, vendor connectivity, and cloud services tied into MES/ERP/QMS.
    • GDPR scope:
      • Only covers personal data of identified or identifiable natural persons in the EU/EEA (employees, suppliers’ staff, customers, visitors, candidates).
      • Focuses on lawful basis, transparency, data subject rights, and cross-border transfers, in addition to security.
      • In industrial environments, this is often HR systems, access control logs, training records, QMS deviations linked to individuals, system audit logs, and support tickets.

    Legal status vs management standard

    • ISO 27001:
      • Voluntary standard (unless made mandatory by contracts or regulators).
      • You can be certified by an accredited body to show that your ISMS conforms to the standard within a defined scope.
      • Certification is based on an audit of your documented system and implemented controls.
    • GDPR:
      • Legal requirement in the EU/EEA for organizations that process personal data of individuals in that region.
      • No simple “GDPR certificate” that proves full compliance. Some schemes or codes of conduct exist, but regulators evaluate compliance case by case.
      • Non-compliance can lead to enforcement actions, including fines and mandatory remediation.

    How they relate in practice

    ISO 27001 can support GDPR, but it does not make you GDPR-compliant by itself.

    • ISO 27001 helps you systematically manage confidentiality, integrity, and availability of information, including personal data.
    • Its controls (e.g. access control, logging, encryption, secure development, supplier management) are useful for meeting GDPR’s requirement to implement “appropriate technical and organisational measures”.
    • However, GDPR includes many areas that ISO 27001 does not fully cover, such as:
      • Lawful basis for processing (consent, contract, legal obligation, etc.).
      • Data subject rights (access, deletion, portability, objection, restriction).
      • Data minimisation, purpose limitation, and storage limitation.
      • Data Protection Impact Assessments (DPIAs) for high-risk processing.
      • Rules for international data transfers.

    Because of this, you can have a well-implemented ISO 27001 ISMS and still be non-compliant with GDPR on topics like retention schedules, HR data handling, or response to subject access requests.

    Implications for industrial and regulated environments

    In brownfield manufacturing environments, both ISO 27001 and GDPR run into the same practical constraints:

    • Legacy systems: Old MES, historians, SCADA, access control systems, and data loggers often have limited security and data protection controls. Retrofitting them for least-privilege access, proper logging, or granular data retention can be complex and may require vendor cooperation and re-validation.
    • Long equipment lifecycles: Production equipment and control systems may remain in use for decades. Achieving ISO 27001-aligned controls and GDPR-aligned retention or pseudonymisation often involves compensating controls rather than full replacement.
    • Integration debt: Personal data may be replicated across HR, training, QMS, MES, and physical security systems. Mapping data flows and implementing GDPR requirements (like right to erasure or restriction) often requires significant integration work and change control.
    • Validation and qualification burden: In regulated industries, changing security controls, identity management, or logging in validated systems may trigger re-validation. This slows the rollout of ISO 27001 controls and GDPR-related changes and must be planned into the change control process.

    Misconceptions to avoid

    • “If we get ISO 27001 certified, we are GDPR compliant”: No. Certification can be evidence of a structured approach to security, but GDPR compliance depends on how you manage personal data specifically, across technical and legal dimensions.
    • “GDPR is only an IT issue”: No. GDPR affects HR policies, supplier contracts, shop-floor CCTV, badge access logs, training records, and paper records just as much as cloud or IT systems.
    • “We can fix GDPR with a new system”: Replacing legacy systems might help, but in regulated, long-lifecycle environments full replacement often fails or overruns due to downtime risk, integration complexity, and qualification/validation cost. A more realistic approach is usually incremental hardening, better governance, and precise scoping of personal data flows.

    How to use ISO 27001 to strengthen GDPR posture

    If you operate in a regulated manufacturing environment, a practical approach is:

    1. Define ISMS scope carefully: Include key systems that process personal data (HR, QMS, access control, service desk, MES user accounts, remote access gateways) and critical OT interfaces.
    2. Map personal data flows: As part of risk assessment, identify which systems hold personal data, how it moves between them, and where it is logged or backed up.
    3. Align controls with GDPR risks: Prioritise ISO 27001 controls that directly reduce GDPR risk, such as identity and access management, logging and monitoring, backup protection, and supplier security requirements.
    4. Integrate with change control and validation: Ensure ISMS-driven changes (e.g. new logging, network segmentation, or encryption) go through existing change control, qualification, and validation processes to avoid unintended compliance or availability impacts.
    5. Close non-security gaps separately: Address GDPR topics not covered by ISO 27001 (lawful basis, notices, DPIAs, data subject rights) through privacy governance, not just technical controls.

    In summary, ISO 27001 is a structured framework to manage information security risks, while GDPR is a binding legal regime for personal data protection. In industrial settings, combining both requires pragmatic integration with legacy systems, validation constraints, and existing governance processes.

  • How is an ISMS different from general IT security in a factory?

    An Information Security Management System (ISMS) is a formal management framework for information security. General IT security in a factory is usually a collection of technical and procedural controls. The ISMS defines how those controls are selected, governed, audited, and improved over time.

    Scope: information vs. just IT assets

    General IT security in a plant typically focuses on:

    • Protecting networks, servers, endpoints, and user accounts
    • Perimeter defenses, VPNs, and remote access rules
    • Malware protection, patching, and backups

    An ISMS has a broader scope: it is about information risks across the business, which may include:

    • Production recipes, NC programs, and process parameters
    • Inspection plans, quality records, and batch genealogy data
    • Supplier data, customer drawings, and export-controlled technical data
    • Both IT and OT environments (MES, SCADA, PLCs, historians) where that information is created or used

    In a factory, this means the ISMS should explicitly address risks at the boundary of ERP, MES, QMS, PLM, and shop-floor control systems, not just the corporate IT network.

    Governance and risk management vs. isolated controls

    General IT security often grows organically: a firewall here, an MFA project there, antivirus everywhere. Controls may be sound, but not consistently linked to a documented risk picture.

    An ISMS typically introduces:

    • Formal risk assessment for information assets, including OT data flows
    • Defined scope (sites, systems, processes) and documented risk acceptance
    • Policies and standards that apply across plants and functions
    • Roles and responsibilities (e.g., asset owners, risk owners, ISMS steering group)
    • Planned controls mapped to risks and to requirements (for example ISO 27001, IEC 62443, customer contracts)

    In practice, this means that firewall rules, access models in MES, and backup strategies for historians are not just “good ideas” but are traceably linked to risks, policies, and approvals.

    Lifecycle and change control vs. one-off projects

    General IT security is often project-based: deploy a new NAC solution, upgrade antivirus, implement a SOC. In regulated manufacturing environments, these projects may not be tightly integrated with validation, configuration control, or long equipment lifecycles.

    An ISMS emphasizes:

    • Change control for security-relevant changes in IT and OT (for example new remote access path to a PLC vendor)
    • Configuration management for security baselines across multiple plants
    • Incident management and lessons learned, feeding back into risk and controls
    • Continual improvement using internal audits, metrics, and management review

    In a brownfield factory with decades-old lines, the ISMS should explicitly account for systems that cannot be patched frequently, complex vendor dependencies, and validation constraints. It will not remove these constraints, but it forces them into a managed decision process rather than ad hoc exceptions.

    Integration with OT and long-lifecycle assets

    General IT security often stops at the IT/OT boundary: security teams may treat OT as a separate domain owned by engineering, especially where proprietary fieldbuses, legacy Windows versions, and vendor-managed appliances exist.

    An effective ISMS in a factory environment needs to:

    • Recognize OT systems as information assets with explicit risk owners
    • Integrate with safety, quality, and validation processes without overriding them
    • Respect long qualification and downtime constraints, especially in aerospace, pharma, and similar sectors
    • Describe how cyber controls (network segmentation, hardening, monitoring) will coexist with vendor requirements and existing MES/SCADA/PLC stacks

    This usually rules out simplistic “rip-and-replace” strategies. Replacing a validated MES or SCADA purely for security reasons can create more risk than it removes due to requalification, integration work, and potential new failure modes.

    Documentation, evidence, and auditability

    General IT security may be strong technically but weak on documentation. In regulated factories, that is often not acceptable.

    An ISMS normally requires:

    • Documented policies, procedures, and control descriptions
    • Asset and risk registers with traceability to implemented controls
    • Records of approvals, exceptions, and periodic reviews
    • Internal audit plans and documented outcomes

    This documentation does not guarantee external audit outcomes, but it provides structured evidence that decisions were made deliberately and follow a defined process. This is important where quality, regulatory, or customer audits increasingly extend into cybersecurity posture.

    What an ISMS does not do

    It is important to be explicit about limits. An ISMS:

    • Does not guarantee security or compliance; it structures how you manage risk
    • Does not automatically make legacy OT systems secure; it makes their risk explicit and managed
    • Will not succeed without alignment across IT, OT, quality, engineering, and plant management
    • Can become a paperwork exercise if controls are not enforced in real systems and processes

    Effectiveness will depend heavily on the quality of integration with existing MES/ERP/QMS, the maturity of change control, and how realistically plant constraints are handled.

    How they coexist in a real factory

    In practice, you do not replace IT security with an ISMS. Instead, the ISMS provides the governance layer around existing and future controls. Typical coexistence in a brownfield plant looks like:

    • Keeping current firewalls, antivirus, SOC, and OT segmentation as-is
    • Documenting them as controls in the ISMS, linked to assets and risks
    • Adding missing process elements: risk assessments, formal access reviews, vendor remote access rules, incident handling playbooks
    • Aligning security changes with existing validation, quality, and change control processes rather than bypassing them

    This approach fits better with long equipment lifecycles and minimizes disruption while still raising the overall level of control and auditability.

  • When should we reference ISO 27002 in our procedures?

    ISO 27002 is a catalog of information security controls and guidance, not a regulation. In a regulated industrial environment, you reference it in procedures when it clarifies how you manage information security risks, but you still need site-specific definitions, ownership, and validation.

    Situations where referencing ISO 27002 makes sense

    It is usually appropriate to reference ISO 27002 when your procedure is:

    • Defining the information security management framework
      For example, an “Information Security Policy” or “Information Security Management” procedure that sets the overall structure of controls, roles, and governance. Here you can state that your control set is aligned with ISO 27002 and then map specific controls into your internal standards.
    • Describing specific security controls
      Procedures or standards for topics such as:
      • Access control to MES, DCS, historians, QMS, ERP, or PLM
      • Account and credential management for OT and IT systems
      • Logging, monitoring, and incident detection
      • Backup, restore, and disaster recovery of production and quality systems
      • Change and configuration management of servers, applications, and network devices
      • Supplier and third-party access to plant systems and technical data

      In these cases, referencing the relevant ISO 27002 control(s) can help justify the control design and align with common practice.

    • Documenting risk assessment and treatment
      Procedures that define how you perform and document information security risk assessments and select treatments. ISO 27002 can be referenced as the catalog for potential controls you consider during risk treatment, but you still need your own risk criteria and acceptance rules.
    • Defining information security requirements for projects and changes
      Change control, system implementation, or project lifecycle procedures that require security reviews for new MES, QMS, SCADA, or data integration projects. Here you can require that designers consider applicable ISO 27002 controls and document which ones are implemented, not implemented, or compensated.
    • Setting requirements for suppliers and service providers
      Procedures for vendor qualification, managed services, or cloud usage may reference ISO 27002 as a baseline for security expectations (for example, logging, access control, incident response). This must be translated into concrete contractual and technical requirements, not left as a vague citation.

    How to reference ISO 27002 without creating problems

    In regulated manufacturing environments, vague or absolute references to ISO standards often create audit and validation issues. Be specific and bounded:

    • Reference specific clauses or controls
      Instead of we comply with ISO 27002, use wording like this procedure implements controls aligned with ISO 27002:2022, sections 5.15 and 8.2, adapted to site risk and system constraints.
    • Make your internal control descriptions primary
      Describe what you actually do in clear, testable terms. Use ISO 27002 as a source of practice, not as the main body of the procedure. Auditors and regulators will test what you wrote and implemented, not the standard.
    • Include version and scope
      If you reference ISO 27002, state the edition (for example, ISO/IEC 27002:2022) and where it applies (for example, Information assets classified as Confidential and above in IT and OT networks). This limits re-interpretation when the standard is updated.
    • Document your tailoring
      Many ISO 27002 controls are not practical for all OT, legacy, or safety-critical systems. Procedures should allow for risk-based tailoring and require documented justification when a control is not applied or is applied via a compensating measure.
    • Avoid implying certification or guarantees
      Do not state or imply that referencing ISO 27002 makes you compliant or certified. Use language like aligned, based on, or informed by, and make clear that actual implementation is defined in local work instructions, configurations, and validated controls.

    Interactions with existing OT, MES, ERP, and QMS environments

    In brownfield plants, you rarely implement ISO 27002 controls uniformly across all systems. Your procedures should:

    • Recognize legacy constraints
      Many production and test systems cannot support modern security controls without requalification or downtime. For example, you may not be able to enforce strong authentication on an older MES without a disruptive upgrade.
    • Separate baseline from exceptions
      Use ISO 27002 to define a baseline control set for new or modernized systems. Document controlled exceptions for legacy or validated systems where changes could impact product quality, regulatory filings, or validated states.
    • Integrate with change control and validation
      Any change derived from an ISO 27002 recommendation (for example, hardening an OS, segmenting a network, tightening access) must go through your established change control, risk assessment, and validation processes, especially where GMP, airworthiness, or safety-critical functions are impacted.
    • Clarify roles and system boundaries
      Procedures should specify where responsibility lies among IT, OT, quality, and operations for implementing and monitoring each control category. ISO 27002 itself does not define organizational boundaries; you must.

    Where you should be cautious about referencing ISO 27002

    There are cases where referencing ISO 27002 is unhelpful or risky:

    • Core manufacturing, test, or quality procedures
      Work instructions for machining, assembly, test, batch release, or deviation handling should not rely on ISO 27002 for technical content. At most, you may reference your information security procedure that is itself aligned to ISO 27002.
    • Validation documentation as a substitute for requirements
      Do not use compliance with ISO 27002 as a stand-in for specific system requirements in user requirement specifications or validation protocols. Requirements must be explicit and testable in your context.
    • Audit response documents
      A strong response explains your risk assessment, decisions, and controls. Overstating ISO 27002 alignment without evidence can increase audit exposure rather than reduce it.

    Practical wording examples

    Examples of bounded references that typically work better in regulated environments:

    • This procedure defines the information security control framework for OT and IT systems supporting manufacturing and quality. Control categories are aligned with ISO/IEC 27002:2022 and tailored based on documented risk assessment and system constraints.
    • For new or significantly modified systems, security requirements shall be defined with reference to applicable control categories in ISO/IEC 27002:2022. Selected controls and any deviations shall be documented in the project risk assessment and change records.
    • Supplier information security controls shall, at minimum, cover access control, incident management, and backup/restore processes consistent with the intent of ISO/IEC 27002:2022 for the contracted services. Specific requirements are defined in the supplier security schedule.

    Key tradeoffs to recognize

    When deciding how heavily to reference ISO 27002, balance:

    • Clarity vs. flexibility
      Detailed mapping to ISO 27002 can improve clarity for security teams but may reduce flexibility for plants with different legacy systems and risk profiles.
    • Standard alignment vs. lifecycle reality
      Full alignment with ISO 27002 across all systems is rarely realistic in aerospace-grade or GMP environments because of qualification burden, downtime risk, and integration complexity. A risk-based, incremental approach is more sustainable.
    • External expectations vs. internal capability
      Referencing ISO 27002 may signal maturity, but if your actual processes, logging, and enforcement are immature or fragmented across sites, over-claiming can create regulatory or customer trust problems.

    In summary, reference ISO 27002 in procedures that govern how you design, select, and justify information security controls across IT and OT, but keep the standard as a guiding framework, not a substitute for concrete, validated, and site-specific requirements.

  • How does ISO 27001 apply to industrial IoT deployments?

    ISO 27001 applies to industrial IoT (IIoT) as a management system standard for information security across the people, processes, and IT/OT assets that make up your IIoT ecosystem. It does not define how to engineer controllers or safety systems, and it is not a product certification. It provides a structured way to decide what risks to address, how to control them, and how to prove you are doing so consistently.

    1. What ISO 27001 actually covers for IIoT

    ISO 27001 defines requirements for an Information Security Management System (ISMS). In an IIoT context, the ISMS typically covers:

    • Data handled by IIoT platforms (sensor data, event logs, configuration, user accounts, sometimes production and quality data).
    • Networks and interfaces between sensors, gateways, edge devices, plant networks, and cloud services.
    • Supporting IT systems such as identity providers, monitoring tools, backup infrastructure, and integration middleware.
    • Processes and people that deploy, configure, administer, and use IIoT systems.

    ISO 27001 applies wherever information security risks exist. For IIoT, that is mainly around confidentiality, integrity, and availability of data and services, not directly around safety functions or process control behavior, although these interact.

    2. Scoping ISO 27001 for industrial IoT

    ISO 27001 is flexible on scope. For brownfield plants, you typically do not put the entire OT environment under scope on day one. Instead, you might define the scope as:

    • A specific IIoT platform (cloud or on-prem) and its supporting services.
    • The connectivity layer from defined gateways up to that platform.
    • The teams and processes responsible for design, deployment, and operation of that IIoT stack.

    Where it gets complex is how the scoped IIoT environment connects back into production networks, MES, ERP, and vendor systems. ISO 27001 requires you to identify and manage those interfaces, but the legacy systems themselves may not be fully in scope. You must be explicit about this in your Statement of Applicability and scope definition to avoid false expectations.

    3. Risk assessment: where ISO 27001 meets OT reality

    ISO 27001 requires a formal risk assessment. For IIoT, that should include:

    • Impact on operations: loss of IIoT availability may be more critical than loss of confidentiality (e.g., condition monitoring or predictive maintenance feeds that prevent unplanned downtime).
    • Integrity of data and commands: tampered sensor data can mislead optimization or maintenance decisions; tampered commands could disrupt operations if bidirectional control is enabled.
    • Cross-domain risk: IIoT often bridges OT and corporate IT; a compromise in one domain can be a pivot for the other.
    • Vendor and cloud risk: IIoT platforms, device management services, and analytics tools are often provided as managed or cloud services with shared responsibility models.

    ISO 27001 does not prescribe how to rate operational risk for OT-specific scenarios. You will need an internal risk model that recognizes safety, regulatory, and production continuity impacts and aligns with your existing OT risk assessment and IEC 62443 work, if any.

    4. Controls relevant to IIoT from ISO 27001 Annex A

    Annex A controls (or the corresponding controls in ISO 27001:2022) provide a menu of areas that must be considered. Key control areas for IIoT typically include:

    • Asset management: maintaining an inventory of IIoT devices, gateways, virtual machines, cloud services, and data flows. In brownfield environments this inventory is often incomplete; ISO 27001 pushes you to formalize it over time.
    • Access control: managing user and service identities for IIoT platforms, enforcing least privilege, controlling API keys, and integrating with existing identity and access management where feasible.
    • Cryptography: encryption in transit between devices, gateways, and cloud; key management; certificate lifecycle. Legacy protocols and constrained devices may limit what is practical.
    • Physical and environmental security: securing locations where IIoT gateways, edge servers, and networking equipment are placed, especially when cabinets are shared with legacy OT.
    • Operations security: patching, configuration management, anti-malware where appropriate, logging and monitoring for IIoT components, with realistic maintenance windows for OT.
    • Communications security: network segmentation for IIoT traffic, remote access controls, secure tunneling, and documented data flows in and out of the plant.
    • Supplier relationships: contracts and SLAs with IIoT vendors, cloud providers, and integrators that define security responsibilities, data handling, and incident reporting.
    • Incident management: how IIoT-related incidents are detected, triaged, and integrated into existing plant incident, problem, and change processes.
    • Business continuity: how you recover IIoT services, configurations, and data after outages, and how you operate safely if IIoT is unavailable.

    Which controls are “applicable” depends on your specific deployment, integration approach, and regulatory context. ISO 27001 requires you to justify inclusions and exclusions, not blindly implement every control.

    5. Relationship with IEC 62443 and OT cyber standards

    In industrial environments, ISO 27001 should not be treated as a replacement for OT-focused standards such as IEC 62443. The relationship is typically:

    • ISO 27001: governs the overall management system for information security, including IIoT, with policies, risk processes, and governance across IT and OT.
    • IEC 62443 and similar: provide technical and architectural guidance for securing industrial automation and control systems, including zones and conduits, security levels, and system requirements.

    For IIoT that touches control networks, you usually need both:

    • ISO 27001 to define who owns risk, change, audits, and continuous improvement around IIoT.
    • IEC 62443 (and vendor-specific hardening guides) to define how to segment, configure, and harden the OT and IIoT components.

    Many organizations start by applying ISO 27001 to the IIoT platform and cloud touchpoints while using IEC 62443 to govern how gateways and plant connectivity are engineered. This coexists more easily with long-life assets and avoids attempting a full OT replacement.

    6. Governance, change control, and validation

    In regulated manufacturing, ISO 27001 mainly reinforces governance requirements you likely already have:

    • Change control for IIoT configurations, firmware updates, and integrations with MES/ERP/QMS, including impact assessment, testing, approvals, and rollback plans.
    • Configuration and version traceability for IIoT sensors, gateways, and applications, which can become part of data integrity evidence in audits.
    • Validation and qualification for IIoT platforms that influence regulated data or product quality decisions, so security changes do not unintentionally undermine validated states or audit trails.

    ISO 27001 does not tell you how to validate IIoT systems or how to meet sector-specific regulations. It simply requires that your security controls be planned, implemented, and reviewed under a managed lifecycle, which you then align with your existing validation and quality systems.

    7. Brownfield constraints and why “rip and replace” usually fails

    Applying ISO 27001 to IIoT in existing plants is constrained by long equipment lifecycles, vendor lock-in, and limited downtime. Common realities include:

    • Legacy protocols and devices that cannot meet modern security requirements without gateways or compensating controls.
    • Shared infrastructure where IIoT traffic rides on networks coexisting with safety and control systems, which limits aggressive changes.
    • Integration debt between IIoT, MES, ERP, PLM, and QMS that complicates clear scoping and responsibility boundaries.
    • Downtime risk that makes large-scale network redesigns or system replacements difficult to justify, especially where each change requires significant requalification and documentation.

    ISO 27001 helps manage this by enforcing a risk-based, incremental improvement approach instead of expecting a clean-slate architecture. You identify the highest-risk IIoT use cases and interfaces and strengthen controls over time, rather than attempting a single large transformation that disrupts operations.

    8. What ISO 27001 does not guarantee for industrial IoT

    It is important to be explicit about what ISO 27001 does not provide:

    • It does not guarantee system safety or compliance with process safety standards.
    • It does not guarantee regulatory compliance in pharmaceuticals, aerospace, or other sectors, though it can support evidence for some information security expectations.
    • It does not ensure that any specific IIoT product or vendor is secure by design; that depends on their engineering practices and your integration work.
    • It does not remove the need for security testing, OT hardening, and vendor assessments for IIoT components.

    ISO 27001 provides a framework to manage risk and demonstrate a disciplined approach to information security around IIoT. Its effectiveness depends heavily on accurate scoping, realistic risk assessment, integration with OT security practices, and the maturity of your existing processes.

  • Do our key suppliers need to be ISO 27001 certified?

    Not all key suppliers need to be ISO 27001 certified. Whether you require it depends on what they do for you, what data and systems they can access, and what your own regulatory and customer obligations are.

    When ISO 27001 certification is typically justified

    Requiring ISO 27001 (or an equivalent, formally audited information security framework) is more common when a supplier:

    • Hosts or processes your production, quality, or product data in their own cloud or data center (for example, SaaS MES, IIoT, QMS, data historian, PLM integrations).
    • Has remote access into your plant network or OT systems (for example, equipment vendors with remote diagnostics, integrators, managed service providers).
    • Handles sensitive technical data (for example, export-controlled, ITAR/EAR, defense, or customer-classified drawings and specifications).
    • Acts as a critical dependency for regulated records (for example, batch records, device history records, electronic signatures, NC/CAPA systems).
    • Is explicitly required by your customers or contracts to hold ISO 27001 or equivalent certification.

    In these cases, certification can provide a structured baseline, audit evidence, and some assurance that the supplier has a managed information security program. It does not guarantee security or compliance outcomes, but it reduces some third-party risk and assessment burden.

    When ISO 27001 is usually not required

    For many suppliers in manufacturing supply chains, ISO 27001 is not strictly necessary, for example:

    • Make-to-print parts suppliers with no direct access to your systems, and who only receive limited drawings and work instructions.
    • Suppliers providing standard catalog components with minimal or no proprietary information.
    • Local service and maintenance providers with on-site-only access under supervision and no remote connectivity.

    These suppliers still need appropriate controls, but that may be achieved through contractual requirements, basic security expectations, and periodic checks rather than full ISO 27001 certification.

    Risk-based approach instead of a blanket requirement

    In regulated, brownfield environments, a blanket requirement that all key suppliers be ISO 27001 certified is often impractical and may not be risk-proportionate. A more realistic pattern is:

    1. Classify suppliers by information and system risk
      Segment suppliers by the sensitivity of data they handle, level of connectivity to your environment, and their role in regulated records or safety-relevant functions.
    2. Define tiered requirements
      For higher-risk tiers, require stronger evidence (for example, ISO 27001, SOC 2, IEC 62443 alignment for OT vendors, or customer-specific frameworks). For lower-risk tiers, require basic security controls and contractual commitments.
    3. Use multiple assurance mechanisms
      Combine ISO 27001 (when applicable) with security questionnaires, technical validations (for example, penetration tests, OT network segregation), and audit rights, rather than relying solely on a certificate.
    4. Align with your own controls and architecture
      Supplier security posture needs to be compatible with how your MES, ERP, PLM, QMS, and OT networks are actually integrated, not how you wish they were. Weak segmentation or legacy systems may change how risky a given supplier connection really is.

    Constraints specific to regulated and long-lifecycle environments

    In aerospace, defense, medical device, and similar sectors, insisting on ISO 27001 for all critical suppliers can conflict with other realities:

    • Limited supplier pool: Niche process or special-geometry suppliers may be technically unique; excluding them for lack of ISO 27001 can be infeasible.
    • Long equipment lifecycles: OEMs of legacy equipment that require remote support or firmware updates may not have ISO 27001 but are operationally irreplaceable.
    • Validation and qualification burden: Shifting to an ISO 27001-certified alternative supplier can trigger requalification, validation, or recertification of parts, processes, or systems, with high cost and schedule impact.

    As a result, many plants accept some suppliers without ISO 27001 and compensate with stricter technical and contractual controls, such as tighter OT segmentation, controlled file exchanges, and documented risk acceptance under change control.

    Practical minimums to require even without ISO 27001

    For key suppliers that are not certified, it is still reasonable to expect and verify:

    • Documented information security responsibilities and basic policies.
    • Access control practices (user management, MFA where applicable, role-based access).
    • Patch and vulnerability management for systems that interact with your environment.
    • Incident reporting obligations, including timelines and scope of notification.
    • Secure data handling and retention for your drawings, NC programs, and records.
    • Change control practices where their changes could affect your validated state.

    These can be captured through contracts, security addenda, supplier quality agreements, or specific clauses in purchase orders, and can be tied into your existing supplier quality and audit programs.

    How this coexists with existing MES/ERP/QMS stacks

    In brownfield environments with mixed MES, ERP, PLM, QMS, and OT vendors, it is usually not realistic to replace tools or suppliers just to align everyone to ISO 27001. Instead, plants typically:

    • Maintain a supplier-criticality and security-risk register.
    • Use network segmentation, jump hosts, and controlled data interfaces to reduce reliance on supplier-side controls alone.
    • Integrate supplier security checks into existing supplier quality and audit processes, rather than standing up a separate track.
    • Apply change control when adding new cloud services or remote access paths, including explicit review of supplier certifications and security posture.

    This approach acknowledges integration debt and regulatory constraints, while still driving the supply base toward better security practices, including ISO 27001 where it is most justified.

    Bottom line

    Your key suppliers do not all need to be ISO 27001 certified. For high-risk suppliers that host your critical data, have remote access, or handle sensitive regulated information, ISO 27001 (or equivalent) is often appropriate and sometimes contractually required. For others, a documented, risk-based set of security expectations and verification activities is usually more practical and better aligned to the realities of regulated, long-lifecycle manufacturing.

  • Do we need all plants in scope to get ISO 27001 certified?

    No. ISO 27001 does not require you to include every plant, site, or system in a single certification scope. You can define a limited scope, such as specific plants, business units, or IT environments. However, how you scope the certification carries practical and audit implications that you should understand clearly.

    How ISO 27001 scoping works

    ISO 27001 certification is issued against a defined scope statement, not your entire company by default. The scope typically specifies:

    • Which legal entities, functions, and locations are covered
    • Which products, services, or processes are covered
    • Which information systems, networks, and data types are included

    You can, for example:

    • Certify only a subset of plants (e.g., aerospace or defense plants)
    • Certify only a central data center and core OT/IT services used by multiple plants
    • Certify one pilot plant or region first, then expand the scope over time

    Key constraints and tradeoffs in a multi-plant environment

    In regulated, multi-plant manufacturing, partial scope is often practical, but it introduces dependencies you must manage carefully.

    1. Shared services and infrastructure

    If certified plants rely on corporate or shared services that are not fully within scope, you must show how the Information Security Management System (ISMS) controls extend to those dependencies. Examples include:

    • Central Active Directory, identity and access management, or VPN services
    • Shared MES, ERP, PLM, QMS, data historians, or file shares
    • Corporate cloud platforms used by multiple plants

    Auditors will expect you to:

    • Document which shared components are in scope versus out of scope
    • Show risk assessments that explicitly address cross-plant dependencies
    • Demonstrate contracts, SLAs, or internal agreements that ensure required controls are in place for shared services

    2. Interfaces between certified and non-certified plants

    When some plants are in scope and others are not, interfaces and data flows become a focal point:

    • Data exchanged between certified and non-certified plants must be controlled, monitored, and risk-assessed.
    • Remote access from non-certified plants (e.g., engineering support, corporate IT, suppliers) must comply with the ISMS controls for the certified scope.
    • Shared OT networks, jump hosts, or vendor remote support need clearly defined boundaries and hardening.

    If boundaries are fuzzy or undocumented, auditors may challenge the scope definition or find nonconformities.

    3. Impact on customers and contractual requirements

    Some customers, especially in aerospace, defense, or medical, may:

    • Require ISO 27001 certification for specific programs, products, or data types
    • Expect that all plants handling their data or manufacturing their parts are included in the scope

    In those cases, certifying only certain plants is acceptable only if:

    • All work and information for that customer is contained within the certified scope, or
    • You are transparent with the customer about which plants and systems are covered and which are not

    Do not assume that a limited scope certificate will automatically satisfy customer or regulatory expectations without that alignment.

    4. Operational reality in brownfield plants

    In mixed, brownfield environments, including every plant in a first certification cycle is often unrealistic because of:

    • Legacy equipment that cannot easily support modern security controls
    • Non-standardized OT/IT architectures and local workarounds
    • Limited ability to take downtime for hardening and validation
    • Existing MES/ERP/QMS integrations that are sensitive to change

    For these reasons, many organizations:

    • Start with a narrower, well-controlled scope (e.g., key plants, central infrastructure)
    • Use that to establish patterns, procedures, and evidence-generation practices
    • Incrementally extend the ISMS and certification scope as controls mature and local constraints are addressed

    5. Traceability, validation, and change control

    In regulated manufacturing, the ISMS interacts with validation and change control practices for OT and IT systems. When you certify only certain plants:

    • Configuration baselines, change records, and validation status for in-scope systems must be traceable and auditable.
    • Changes in shared systems (e.g., MES upgrade) may affect both certified and non-certified plants, but evidence obligations will differ.
    • Procedures must clearly specify which sites and systems follow ISO 27001-governed processes and which follow local or legacy controls.

    Ambiguity here can cause audit issues, especially if evidence from non-certified plants is inadvertently presented as part of the certified ISMS.

    When a broader plant scope may be justified

    You may choose to include more plants in scope when:

    • Plants are highly interconnected at the network, application, and data levels, making clean boundaries difficult
    • Common OT and IT platforms already apply uniform controls across plants
    • Key customers or programs span multiple plants, and splitting scope would complicate customer assurance

    However, broad scope increases the effort needed to harmonize procedures, evidence generation, and internal audit coverage, especially in facilities with older assets and heterogeneous controls.

    Practical approach for deciding scope

    A pragmatic, defensible approach is to:

    1. Identify drivers: Clarify whether the primary drivers are customer requirements, regulatory expectations, corporate risk appetite, or specific programs.
    2. Map dependencies: Document shared services, networks, and data flows across plants and central IT, focusing on where program-critical or regulated data flows.
    3. Define clear boundaries: Choose a scope that you can explain and defend to an auditor, with explicit inclusions/exclusions and interface controls.
    4. Start with a manageable scope: Especially in brownfield environments, prioritize plants and systems where you can implement and demonstrate controls reliably.
    5. Plan for expansion: Establish a roadmap to extend the ISMS and certification to additional plants as controls, standardization, and integrations mature.

    In summary, you do not need all plants in scope to obtain ISO 27001 certification, but scoping decisions must be explicit, technically coherent, and consistent with how your plants, OT/IT systems, and data actually interact. In regulated manufacturing, getting the boundaries and interfaces right is more important than having a maximally broad scope on day one.

  • How is a control catalog different from a framework like ISO 27001?

    A control catalog and a framework like ISO 27001 solve related but different problems. They are not interchangeable, and in regulated industrial environments they are usually used together.

    What is a control catalog?

    A control catalog is a structured list of potential controls you can implement to manage risk. Examples include NIST SP 800-53 control families or IEC 62443-3-3 requirement sets. Key characteristics:

    • Scope: Focused on individual controls and control families (e.g., access control, logging, backup, segmentation).
    • Form: Typically a large, modular library of requirements that you can select from, profile, and tailor.
    • Goal: Provide options and common language for security and OT controls, not prescribe how your management system should run.
    • Use: You pick which controls are applicable based on risk, regulatory drivers, and feasibility in your brownfield environment.

    By itself, a control catalog does not define:

    • How you govern cybersecurity or OT security end to end.
    • How you run risk assessments, handle exceptions, or manage changes.
    • How you show ongoing effectiveness, internal audits, or management review.

    What is a framework like ISO 27001?

    ISO 27001 is a management system framework for information security (an ISMS). It tells you how to set up and run a managed, auditable program:

    • Scope & context: Define boundaries, interested parties, and requirements.
    • Governance: Policies, roles, responsibilities, and leadership commitment.
    • Risk management: How to assess risks, select controls, and justify residual risk.
    • Lifecycle: Planning, implementation, monitoring, internal audit, and continual improvement.
    • Evidence: Documentation and records needed to show the system is defined and working.

    The Annex A of ISO 27001 looks like a small control catalog, but it is tightly tied to the ISMS process. Many organizations also map Annex A to richer catalogs (e.g., NIST, IEC 62443) for OT or regulated manufacturing needs.

    Core differences

    • Purpose:
      • Control catalog: Menu of potential controls.
      • Framework (ISO 27001): Operating model for a managed security program.
    • Level:
      • Control catalog: Primarily technical/operational requirements.
      • Framework: Governance, process, risk, and improvement, plus a control set.
    • Outcome:
      • Control catalog: Helps you specify “what” to implement.
      • Framework: Helps you prove you run a controlled system with defined inputs, outputs, and reviews.
    • Traceability expectations:
      • Control catalog: Trace from a requirement to control implementation and evidence.
      • Framework: Trace from risk and business context through control selection, implementation, monitoring, and management review.

    How they work together in industrial and OT environments

    In a regulated or long-lifecycle manufacturing environment, you typically:

    • Use a framework (ISO 27001, or IEC 62443-2-1 for OT) to define governance, risk, and lifecycle management.
    • Reference one or more control catalogs (e.g., ISO 27001 Annex A, NIST 800-53, IEC 62443-3-3) as your pool of specific controls.
    • Map selected controls to existing MES, SCADA, PLCs, network gear, and procedures rather than trying full system replacement, which often fails due to validation burden, downtime risk, and integration complexity.

    The reality in brownfield plants is that:

    • Not every catalog control is technically or operationally feasible on legacy equipment.
    • Changes to controls often require formal change control, revalidation, and requalification.
    • Evidence must come from multiple systems (MES, QMS, OT monitoring, IT logs), and integration gaps are common.

    A framework helps you justify why certain catalog controls are tailored, deferred, or replaced by compensating measures, and how you manage that over time.

    Practical selection considerations

    When deciding how to use a control catalog vs a framework in your environment, leadership teams usually focus on:

    • Regulatory drivers: Which frameworks and catalogs are referenced by your regulators, customers, or contracts.
    • OT vs IT scope: ISO 27001 is IT focused; IEC 62443 catalogs and frameworks are more aligned to OT, but still need tailoring for each plant.
    • Integration with existing systems: How well chosen controls can be implemented with your current MES/ERP/QMS and OT stack without unacceptable downtime or revalidation cost.
    • Traceability: Ability to show a clear link from risk to control selection, implementation, monitoring, and change history.

    In summary, a control catalog is a detailed parts list, while a framework like ISO 27001 is the architecture and management system. Industrial organizations typically need both, configured carefully to fit brownfield constraints and validation requirements.

  • Who should participate in ISO 27001 risk workshops for aerospace operations?

    For aerospace operations, ISO 27001 risk workshops work best when they are cross functional and aligned to the actual system landscape, not just the org chart. The exact participants depend on the scope of the workshop, but the following roles are typically required.

    Core participants (almost always required)

    • Information Security / CISO function: Facilitates the risk method, keeps alignment to ISO 27001, maintains the risk register structure, and ensures treatment options and control mapping are consistent with the ISMS.
    • IT Operations: Represents enterprise infrastructure, networks, identity and access, backup/restore, and cloud or data center services that support engineering, MES, PLM, ERP, and QMS.
    • OT / Manufacturing Systems Engineers: Represent control systems (PLCs, SCADA, DCS), industrial networks, HMIs, and integration with MES and test systems. They are essential for realistic assessment of downtime risk, patching constraints, and vendor limitations.
    • Manufacturing / Operations Leadership: Brings understanding of production priorities, takt time constraints, maintenance windows, and the business impact of loss of availability, integrity, or traceability in the shop floor environment.
    • Engineering / Product & Test Owners: Represent CAD/PLM, NC programming, test rigs, and model-based definition. They help evaluate risks around design data integrity, export-controlled data, and configuration changes that affect qualified processes.
    • Quality / Compliance Representatives: Ensure that risk scenarios consider implications for nonconformance handling, records retention, traceability, regulated documentation, and how cybersecurity events intersect with quality and airworthiness obligations.
    • ISMS Owner / Risk Manager: Maintains the overall ISO 27001 risk framework, ensures consistency across sites and programs, and checks that workshop outputs are usable for ongoing risk treatment, monitoring, and internal audits.

    Participants based on scope and data sensitivity

    • Program / Business Unit Leaders: Needed when the scope covers a major platform or key customer contract so impact scoring aligns with contractual, export, and schedule realities.
    • Export Controls / Trade Compliance: Involved when the workshop covers ITAR/EAR or other controlled technical data, to quantify regulatory and data-handling risks accurately.
    • Supply Chain / Supplier Management: Important if critical processes or data reside at suppliers (e.g., special processes, machining, assembly, testing) or depend on shared portals, EDI, or shared PLM/MES access.
    • Facilities / EHS: Included when physical security, shared utilities, or environmental/health/safety systems affect or are affected by cyber events (e.g., building management systems, compressed air, or nitrogen supplies tied to production).
    • Data Owners / Process Owners: Named owners for specific information assets (e.g., NC programs, FAI records, as-built/as-flown traceability, test data) so that asset value and tolerable downtime are not guessed by IT alone.
    • Vendor or Integrator Representatives: Sometimes needed for proprietary MES/SCADA/PLM, legacy test stands, or cloud services when internal teams lack full visibility into technical limitations and realistic mitigations.

    Who should not own the workshop alone

    • IT or security alone should not run risk workshops without operations, engineering, and quality. This often leads to controls that look good on paper but are not deployable in a qualified aerospace production environment.
    • Single-vendor perspectives should not dominate. Many aerospace plants run brownfield stacks with multiple MES, legacy test systems, and long-lived equipment. Risk decisions must reflect coexistence and integration constraints across all major systems.

    Practical participation rules for brownfield aerospace plants

    • Scope per workshop: Define the boundary first (e.g., “final assembly line and associated MES/PLM” or “engine test cells and data systems”). Invite only those who have accountability or deep knowledge within that boundary.
    • Representation, not crowding: Aim for 8–15 active participants. Consolidate representation where possible (e.g., one senior OT engineer who can speak for several lines, one quality lead with delegated inputs).
    • Include both business and technical views: Ensure every critical process area has at least one technical representative (who understands systems and constraints) and one business/process owner (who understands operational and contractual impact).
    • Cover the full lifecycle: Because equipment and software live for decades, include voices who understand legacy qualification constraints, historical deviations, and planned modernization, not just new deployments.
    • Ensure decision-making authority: At least some participants should be able to commit to risk acceptance, prioritization, or follow-up actions, or to bring decisions promptly to the correct governance body.

    Role of governance and change control

    • Change control boards (CCBs) or similar governance bodies should not all attend, but should receive outputs, as many risk treatments will require controlled changes to validated or qualified systems.
    • Configuration management and document control teams should be consulted so that identified treatments (e.g., new procedures, updated work instructions) can be implemented with traceability across systems and sites.

    How this differs from generic ISO 27001 workshops

    • In aerospace manufacturing, availability and integrity of OT and quality records often carry higher operational risk than typical office IT services, so OT, quality, and engineering participation is not optional.
    • Because plants run mixed legacy and modern systems, risk discussions must include people who understand integration, validation history, and why “rip-and-replace” or frequent patching may be impractical without requalification and significant downtime.
    • Export controls and customer / regulatory obligations add stakeholders that are not present in most generic ISO 27001 contexts, particularly for handling controlled technical data and multi-national programs.