RSC Content Type: FAQ

Direct answers to common technical or compliance questions.

  • Do I need to abandon my current OEE calculation to adopt ISO 22400?

    No. You do not need to abandon your current OEE calculation to adopt ISO 22400, but you do need to be explicit about what is and is not ISO 22400 aligned. In regulated and long-lifecycle environments, most plants run a coexistence and mapping approach rather than a hard cutover.

    How ISO 22400 and your current OEE can coexist

    ISO 22400 defines a standardized set of manufacturing KPIs (including OEE and related indicators) with specific terms, numerators, denominators, and time bases. Your legacy OEE implementation is almost certainly different in at least some of these details.

    In practice, this connects to ISO 22400 KPI governance when teams need to turn the answer into repeatable execution habits.

    Common coexistence patterns:

    • Dual reporting: Keep your current OEE for continuity and add an ISO 22400-compliant OEE view in parallel for selected lines, products, or customers.
    • Mapping and translation: Maintain your existing data structures, but document and implement a mapping layer (in MES, data warehouse, BI tool, or scripts) that outputs ISO 22400 KPIs from the same raw events.
    • Phased convergence: Start with dual definitions, then converge to ISO 22400 where the benefit (benchmarking, customer expectations, multi-site comparability) outweighs re-training, re-baselining, and validation costs.

    When you do need to change your OEE definition

    You do not have to “abandon” your current OEE, but you cannot call it ISO 22400-compliant if:

    • You classify time buckets differently than ISO 22400 (for example, treating planned changeovers as loss in one system and as non-productive but not loss in another).
    • You use non-standard or site-specific formulas (for example, embedding quality yield into availability, or counting rework as good output).
    • You mix shift, order, and calendar bases without clear rules that match ISO 22400’s KPI definitions.

    In those cases, you have two options:

    • Keep your legacy OEE as-is and label it clearly as “Plant OEE” or “Site OEE”, separate from any ISO 22400 metrics.
    • Refactor your calculation and data model so that at least one OEE metric matches ISO 22400 exactly, while keeping the old metric for historical comparison during a transition period.

    Key dependencies and risks in regulated environments

    Transitioning to ISO 22400 is not just a math change; it affects systems, records, and sometimes validated reports:

    • Data model and event taxonomy: Your MES, SCADA, or historian must capture the states and timestamps that ISO 22400 assumes. If downtime reasons, changeover codes, or quality states are incomplete or inconsistent across cells, you may not be able to implement ISO 22400 cleanly without rework.
    • Validation and change control: If OEE or related KPIs are used in validated reports or formal decisions (capacity, release criteria, maintenance triggers), changing definitions may require documented impact assessment, change control, regression checks, and potentially re-validation of calculations and reports.
    • Historical comparability: Once you change the definition, historical trend lines break. You either maintain both calculations for a defined overlap period or run a back-calculation project from raw data (if those raw events are complete, consistent, and retrievable).
    • System coexistence: Legacy MES/ERP/BI stacks often hard-code OEE logic. Replacing that wholesale can be high-risk due to qualification burden, downtime risk, and integration complexity. A separate analytics layer that computes ISO 22400 metrics from existing signals is usually lower risk than ripping out embedded OEE logic everywhere.

    A practical migration approach

    A pragmatic path in brownfield, regulated environments typically looks like this:

    1. Document your current OEE definition: Precisely define how you calculate availability, performance, and quality today, including time bases, exclusions, and data sources.
    2. Compare to ISO 22400: Identify exact differences: which time buckets differ, which loss categories are merged or split, and whether your good/bad classifications align.
    3. Run a dual-calculation pilot: On a small scope (one line or cell), compute both “legacy OEE” and “ISO 22400 OEE” from the same raw events. Quantify the delta and its drivers.
    4. Decide on your target set: Choose where strict ISO 22400 alignment is necessary (multi-site benchmarking, OEM/customer reporting, corporate dashboards) and where local definitions are acceptable for internal problem-solving.
    5. Implement a mapping layer: Prefer adding a calculation/mapping layer in a data warehouse or analytics tool over re-implementing every MES/ERP screen, especially when those systems are validated or have long upgrade cycles.
    6. Manage change and training: Communicate clearly which numbers are ISO 22400, which are legacy, and how they should be used. Lock this into procedures or playbooks so interpretations do not drift.

    How to communicate OEE metrics after adopting ISO 22400

    To avoid confusion and unrealistic expectations:

    • Label KPIs unambiguously: For example, use names like “OEE (ISO 22400)” vs “OEE (Plant Definition)” in dashboards and reports.
    • Keep lineage and traceability: Maintain controlled documentation describing the formulas, inputs, and changes over time. In audits or customer reviews, this is more valuable than claiming compliance without detail.
    • Avoid partial claims: If you only align some metrics to ISO 22400, say so. Do not imply “full ISO 22400 adoption” when only OEE was harmonized and other KPIs remain custom.

    In summary: you do not need to abandon your current OEE to adopt ISO 22400. You can run both in parallel, use mapping to bridge differences, and then selectively converge where it supports cross-site comparability and stakeholder expectations without creating unnecessary re-validation work or disrupting established performance management routines.

  • What are examples of non-conforming behavior?

    In regulated manufacturing, “non-conforming behavior” means actions or omissions that do not follow approved requirements, methods, or controls. It is broader than just nonconforming product. It includes behaviors by people and systems that bypass, weaken, or contradict documented processes, specifications, and controls.

    1. Operator and technician behaviors

    • Skipping required process steps: Omitting an in-process inspection or cleaning step because “it always passes” or “we are behind schedule.”
    • Using unapproved work methods: Following a tribal shortcut instead of the current, approved work instruction.
    • Bypassing interlocks or safety features: Using magnets, jumpers, or manual overrides to defeat guards, light curtains, or door switches to “get the job done faster.” (Also a safety issue.)
    • Using wrong or outdated documents: Printing a work instruction months ago and continuing to use it after new revisions are released.
    • Using incorrect tools or equipment: Substituting a different torque wrench, adhesive, fixture, or gage that is not specified in the routing or work instruction.
    • Working without required qualifications: Performing special processes (welding, NDT, sterilization, etc.) without current certification or training sign-off.
    • Improvising rework without approval: Filing, shimming, drilling, or bending parts to make them fit without an approved rework instruction or deviation.
    • Inaccurate or incomplete recording: Checking off steps not actually performed, copying another operator’s readings, or leaving required fields blank in batch records, travelers, or eDHR.
    • Ad-hoc material substitution: Grabbing “similar” hardware, o-rings, lubricants, or chemicals from another bin when the specified material is not available.

    2. Supervisor, engineering, and management behaviors

    • Informal deviations: Telling a team to ignore a spec, skip a test, or change a process step “just this once” without formal deviation or change control.
    • Schedule pressure over compliance: Explicitly or implicitly rewarding on-time delivery while tolerating or encouraging shortcuts around inspection or documentation.
    • Uncontrolled process changes: Changing parameters (e.g., oven cure time, pressure, CNC feeds/speeds) or sequences without documented change control, validation, or risk assessment.
    • Overriding quality decisions without process: Releasing material that failed inspection or that has open nonconformances without approved concession or use-as-is disposition.
    • Delaying or avoiding issue escalation: Instructing staff not to log an NCR, deviation, or complaint to avoid metrics impact or audits.
    • Ignoring training and competence gaps: Assigning complex or regulated tasks to untrained personnel because “they will figure it out” or “we are short-staffed.”

    3. Quality system and documentation behaviors

    • Using uncontrolled documents: Relying on personal copies, spreadsheets, or shared-drive instructions that are not under document control.
    • Backdating or pre-signing records: Completing signatures or timestamps before work is done (or altering them afterward) to match schedules.
    • Incomplete traceability: Not recording required lot numbers, serial numbers, or equipment IDs for traceable materials or special processes.
    • Not following NCR/CAPA procedures: Handling defects verbally instead of raising a nonconformance, or closing CAPAs without verifying effectiveness.
    • Editing data without audit trail: Modifying inspection results or batch data outside the validated system, or without justification and traceability.

    4. Equipment, calibration, and maintenance behaviors

    • Using out-of-calibration gages: Continuing to use instruments, torque tools, or test rigs beyond calibration due date or after known failure.
    • Adjusting equipment without authorization: Technicians changing recipes, offsets, or control logic without proper authority or documentation.
    • Disabling alarms or interlocks: Silencing nuisance alarms, removing fuses, or changing alarm thresholds to avoid stoppages instead of resolving root causes.
    • Running outside validated ranges: Routine operation of ovens, sterilizers, molding presses, or environmental chambers outside validated setpoints or limits.
    • Skipping preventive maintenance: Deferring required PM on critical equipment because “it is still running fine” and not documenting the decision appropriately.

    5. Data, IT, and system behaviors

    • Work outside validated systems: Running production from offline spreadsheets or emails when MES/ERP/QMS is the approved system of record.
    • Manual workarounds for system constraints: Re-typing, copy-pasting, or duplicating data between systems without reconciliation or checks, leading to mismatches between paper and digital records.
    • Uncontrolled configuration changes: Changing routing logic, part masters, electronic signatures, or security roles in MES/ERP/QMS without change control and testing.
    • Inadequate access control: Shared logins, generic accounts on production systems, or supervisors entering data on behalf of operators as routine practice.
    • Shadow IT solutions: Deploying unapproved apps or databases to track production, quality, or maintenance data outside corporate governance.

    6. Brownfield and coexistence realities

    In brownfield environments with mixed legacy and modern systems, non-conforming behavior often appears around the gaps between systems, not just within one system:

    In practice, this connects to non-conformance management when teams need to turn the answer into repeatable execution habits.

    • Operators following the paper traveler while ignoring later changes applied only in MES or vice versa.
    • Parallel, unofficial trackers used to “fix” poor integrations, which slowly diverge from the system of record.
    • Plants running different revisions of the same work instructions due to incomplete rollout or limited downtime for updates.

    Trying to “fix” non-conforming behavior purely by replacing systems usually fails in regulated, long-lifecycle operations. New platforms do not remove the need for disciplined change control, validation, clear ownership of requirements, and practical workarounds for downtime and integration gaps. Without addressing these, non-conforming behaviors simply migrate to the new tools.

    7. How to interpret and act on non-conforming behavior

    • Context matters: Some behaviors may be non-conforming in one plant or program but acceptable in another with different approvals, risk assessments, or validated ranges.
    • Look for patterns, not one-offs: A single deviation may be a mistake; repeated behaviors usually indicate process, training, or system design issues.
    • Tie behaviors to documented controls: Classify behaviors against specific SOPs, work instructions, drawings, or system configurations they violate or bypass.
    • Use structured problem solving: Treat persistent non-conforming behavior as a signal for root cause analysis and potential CAPA, not just individual blame.

    Any assessment of non-conforming behavior must be grounded in your actual procedures, specifications, and regulatory obligations. The same act can be either acceptable variation or a serious violation depending on documentation, approvals, and validated limits in your environment.

  • What are the main benefits of moving from ad-hoc KPIs to ISO 22400?

    Moving from ad-hoc KPIs to ISO 22400 mainly improves consistency, comparability, and governance of manufacturing performance metrics. The benefits are significant, but they depend on data quality, integration maturity, and how rigorously the model is implemented and maintained.

    1. Common language across plants, systems, and vendors

    Ad-hoc KPIs often mean each plant, department, or integrator defines metrics differently. ISO 22400 provides standardized definitions (for example, for OEE-related KPIs, availability, performance, quality) so that:

    In practice, this connects to ISO 22400 KPI governance when teams need to turn the answer into repeatable execution habits.

    • Operations, quality, engineering, and IT are talking about the same thing when they say “availability” or “performance loss”.
    • Different plants, lines, and products can be compared without re-translating local KPI definitions.
    • Vendors (MES, SCADA, historians, analytics tools) have clearer requirements for how to calculate and expose KPIs.

    This reduces time spent arguing over KPI definitions and re-building reports when organizations or systems change.

    2. Better comparability and benchmarking

    With ad-hoc KPIs, cross-plant comparisons are often not credible because each site has its own assumptions. ISO 22400 improves:

    • Internal benchmarking between shifts, cells, or plants, because definitions and calculation logic are aligned.
    • External benchmarking against industry references or partners using the same standard, subject to each side implementing the standard faithfully.
    • Change impact assessment, because you have consistent baselines before and after process, equipment, or software changes.

    This does not eliminate the need to normalize for product mix, routing complexity, or regulatory overhead, but it makes those adjustments more transparent.

    3. Clearer data requirements for MES/ERP and OT integration

    ISO 22400 explicitly links KPIs to underlying data elements and events. Moving away from ad-hoc metrics helps you:

    • Identify which machine states, production counts, quality results, and schedule data must be captured and time-aligned.
    • Specify more precise integration requirements for MES, ERP, PLM, QMS, and historian systems.
    • Expose data gaps early (for example, no reliable planned vs unplanned downtime codes, or ambiguous shift boundaries).

    In brownfield environments with mixed vendors, this structure helps prioritize realistic integrations instead of attempting full replacement of existing systems, which often fails due to validation cost, downtime risk, and requalification burdens.

    4. Stronger governance, traceability, and change control

    In regulated and long-lifecycle environments, uncontrolled KPI definition changes can undermine traceability and auditability. ISO 22400 helps by:

    • Providing a reference model so changes to KPI logic are documented as deviations from the standard.
    • Making it easier to version-control KPI definitions and link them to MES/ERP configuration changes.
    • Supporting clearer evidence trails when regulators, customers, or internal auditors ask how performance metrics are computed.

    The standard does not replace change control, validation, or documented procedures. It gives you a stable baseline so those controls are easier to apply.

    5. Reduced rework in analytics and reporting

    Ad-hoc KPIs lead to repeated one-off report builds and conflicting dashboards. By adopting ISO 22400:

    • Analytics teams can design reusable data models and calculations rather than bespoke logic for every site or stakeholder.
    • Unified semantic layers (in BI tools or data warehouses) are easier to maintain and test.
    • System migrations and upgrades are less disruptive because KPI definitions are decoupled from specific tools.

    These benefits only materialize if the ISO 22400 model is actually implemented at the data and calculation level, not just mentioned in documentation.

    6. More reliable performance-driven decision making

    When KPI logic is ad hoc or opaque, decisions about capacity, staffing, capital projects, and continuous improvement are harder to justify. ISO 22400 can improve decision quality by:

    • Making loss structures (availability, performance, quality) more visible and consistently categorized.
    • Allowing leadership to see whether improvements are real or artifacts of changed definitions.
    • Enabling more confident use of performance data in A3s, 8D/RCCA, and portfolio-level investment discussions.

    It does not guarantee better performance; it improves the reliability of the information you base actions on.

    7. Practical constraints and tradeoffs

    There are real limitations and costs in moving from ad-hoc KPIs to ISO 22400:

    • Data readiness: If basic signals (run/stop, scrap, rework, changeovers, planned stops) are unreliable, standardization alone will not fix KPI quality.
    • Legacy system limitations: Some older MES/SCADA or custom tools may not support ISO 22400-caliber event granularity without invasive changes.
    • Validation and change control: In regulated environments, changing KPI logic can trigger validation and documentation needs; this slows down the transition and must be planned.
    • Partial adoption: Many organizations implement a subset of ISO 22400 aligned to their constraints. This is workable, but you should be explicit about which definitions you use and where you deviate.
    • Training burden: Leadership and engineers must be trained on the standard; otherwise, people will keep interpreting KPIs through old ad-hoc definitions.

    In most aerospace-grade and similarly regulated environments, incremental adoption layered on existing MES/ERP stacks is more realistic than attempting a clean-sheet implementation or full system replacement.

    8. How this coexists with existing ad-hoc KPIs

    Moving to ISO 22400 does not require throwing away every current KPI overnight. A practical approach is:

    • Map current KPIs to the closest ISO 22400 equivalents.
    • Identify gaps where current metrics are not aligned or are missing critical loss categories.
    • Run both versions in parallel for a period, document differences, and communicate impacts to stakeholders.
    • Formally retire legacy definitions via controlled change once users trust the ISO 22400-based metrics.

    This coexistence strategy helps control risk, manage validation scope, and maintain credibility with skeptical operations and quality leaders.

  • Can I add domain-specific KPIs on top of ISO 22400 categories?

    Yes. ISO 22400 is explicitly designed to be extendable, so you can add domain-specific KPIs as long as you keep a clear and traceable relationship to the standard categories and objects.

    How to layer domain-specific KPIs on ISO 22400

    In practice, most regulated and high-mix environments do not stop at the base ISO 22400 indicators. They:

    • Use ISO 22400 KPI groups and objects (e.g., availability, performance, quality; equipment, order, material) as a common backbone.
    • Define domain- or product-specific KPIs (e.g., “first-pass yield for titanium structural parts,” “batch right-first-time for sterile fill,” “NPT per engine program”).
    • Map each custom KPI back to one or more ISO 22400 indicators and base measures where possible.

    This mapping is important for comparability across plants, suppliers, and systems, and for explaining your metrics to auditors and customers.

    Key constraints and risks

    Simply adding more KPIs tends to create confusion unless you address these points explicitly:

    • Definition control: Each domain-specific KPI needs a precise, version-controlled definition: scope, units, inclusions/exclusions, time basis, and data sources. Without this, discrepancies between MES, data warehouse, and local Excel calculations will accumulate.
    • Double-counting and overlap: Custom KPIs often partially duplicate ISO 22400 ones. If you are not explicit about which KPI is the “authoritative” one for a decision, you can end up with conflicting numbers in management reviews.
    • Traceability: For regulated environments, you should be able to trace a reported KPI value back to raw events and master data: which equipment, which production order, which time window, and which transformation logic.
    • Change control: KPI formula changes, new filters, or data model changes should go through formal change control, especially when metrics drive release decisions, batch disposition, or capacity planning.
    • Validation and testing: Where metrics are used in validated processes or electronic records, new KPIs and changes to them typically require documented testing and sometimes revalidation of MES, historian interfaces, and reporting tools.

    Practical integration in brownfield environments

    In mixed, legacy-heavy landscapes, adding domain-specific KPIs on top of ISO 22400 is feasible but rarely plug-and-play:

    • MES and historian limits: Older MES or SCADA systems may not natively support ISO 22400 semantics. You can still implement the logic in a data warehouse or analytics layer, but you must be clear where the “system of record” for each KPI lives.
    • Multiple calculation engines: Plants often have calculations in MES, historian, custom middleware, and BI tools. If you add a domain-specific KPI, decide where it is calculated and prevent alternative, unsanctioned versions in local spreadsheets.
    • Long lifecycle assets: Some equipment or legacy interfaces cannot be changed easily without qualification or downtime. In those cases, you may need to compute both ISO 22400 and domain-specific KPIs externally, leaving the core control systems untouched.
    • Avoiding full replacement: Attempting to replace all legacy KPI logic with a single new platform at once often fails due to downtime risk, integration complexity, and validation burden. Incremental layering on top of existing systems, with clear mapping to ISO 22400, is usually more realistic.

    Suggested governance approach

    A simple governance model makes domain-specific extensions workable:

    • KPI catalog: Maintain a central catalog listing each KPI, whether it is ISO 22400-based or domain-specific, with owner, purpose, formula, and mapping to ISO 22400 indicators.
    • Tiering: Separate global KPIs (based directly on ISO 22400) from domain/plant-specific ones to avoid endless debates about which number is “right” at corporate vs site level.
    • Standard interfaces: Where possible, expose both standard and domain-specific KPIs via a common data model or API, even if the underlying systems are heterogeneous.
    • Documentation for audits: Keep evidence of how KPIs are calculated, tested, and changed over time. This helps when auditors question why your internal metrics differ from generic OEE benchmarks.

    In summary, adding domain-specific KPIs on top of ISO 22400 is not only allowed but often necessary. The value comes from disciplined definition, mapping, and governance so that extensions improve insight instead of increasing confusion.

  • How much does ISO 27001 certification usually cost for industrial companies?

    There is no single “standard” price for ISO 27001 certification in industrial environments. Total cost depends heavily on scope, plant count, current security maturity, and how much work you can absorb with existing staff. For most industrial companies it is a multi-year spend, and internal effort usually outweighs external invoices.

    Typical cost components

    When leadership asks “What does ISO 27001 cost?” they are usually mixing several distinct buckets:

    • Internal effort: time from IT, OT, engineering, quality, legal, HR, and site leadership to design and run the Information Security Management System (ISMS).
    • External advisory: gap assessments, policy development support, risk assessment facilitation, and implementation coaching.
    • Tools and infrastructure: controls you may need to buy or upgrade (e.g., logging/monitoring, vulnerability management, backup, asset inventories, GRC / ISMS tooling).
    • Certification audits: Stage 1 & Stage 2 audits, then annual surveillance and recertification.
    • Ongoing maintenance: periodic risk reviews, internal audits, management reviews, and corrective actions.

    Order-of-magnitude ranges for industrial companies

    These are indicative ranges only, assuming a typical regulated, multi-system industrial environment. Numbers are ballparks, not quotes.

    1. Certification body fees (external audits)

    • Small scope (e.g., 1–2 sites, limited processes, up to ~200 people in scope):
      Approx. USD 10k–30k for initial certification over 3 years (Stage 1 + Stage 2 + surveillance), depending on the certification body, country, and complexity.
    • Mid-size scope (several sites and functions, 200–1,000 people in scope):
      Approx. USD 30k–80k over the 3-year cycle.
    • Large or complex scope (multi-country, many plants, OT-heavy, high regulatory overlap):
      Often USD 80k+ over 3 years.

    Cost drivers include number of employees in scope, number of locations, IT vs OT complexity, and whether the ISMS is narrowly scoped (e.g., just a data center) or covers broad manufacturing operations and engineering systems.

    2. External consulting and implementation support

    External support is optional but common, especially for a first certification or when OT is tightly coupled to safety- or quality-critical processes.

    • Light support / coaching (templates, periodic reviews, some training):
      Approx. USD 10k–40k over the initial implementation.
    • Moderate support (structured gap assessment, risk workshops, control design help, internal audit support):
      Often USD 40k–150k.
    • Heavy support / near turn-key (consultants driving much of the program, documentation, and readiness):
      Can easily exceed USD 150k–300k, especially across multiple plants and systems.

    In regulated industrial environments with complex MES/ERP/PLM/QMS stacks, consulting effort tends to be higher than in a pure SaaS or office-IT environment because processes, systems, and responsibilities are more fragmented and need careful alignment with change control and validation.

    3. Internal effort (usually the largest cost)

    Even if external invoices look modest, internal cost in people time is often the dominant spend:

    • Core ISMS team (CISO / security lead, IT/OT security, QA/regulatory, risk/compliance): typically fractional FTEs over 12–24 months to design and embed processes.
    • Process owners (operations, engineering, plant management): time spent on risk assessments, procedure changes, access reviews, and training.
    • Integration work: IT and OT teams aligning asset inventory, backup, logging, remote access, and change control with existing MES/SCADA/ERP/QMS practices.

    If you cost internal time, it is common for the initial implementation to equate to 0.5–2 FTE-years of effort for a small/mid-sized manufacturer, and significantly more across a large, multi-site group, spread over multiple roles and departments.

    4. Tools, controls, and remediation

    ISO 27001 does not mandate specific tools, but closing gaps usually implies some investment. Examples:

    • Centralized logging and monitoring (SIEM or similar).
    • Vulnerability management, patch management, and secure remote access, especially for OT.
    • Backup/restore improvements, including testing and documentation.
    • Identity/access management improvements (MFA, joiner-mover-leaver, privileged access).
    • Policy and document management, and sometimes GRC/ISMS platforms.

    Costs range from near-zero incremental (if you already have mature tooling) to significant new annual spend for monitoring, security services, and licensing. In a brownfield industrial context, the bigger cost is often integration and rollout across aging OT assets, not just software licenses.

    5. Ongoing maintenance costs

    After certification, you will carry a recurring workload:

    • Annual risk reassessments and treatment plans.
    • Internal audits and management reviews.
    • Corrective actions, security incident handling, and continual improvement.
    • Surveillance audits and recertification every cycle.

    For many companies, this becomes a fractional FTE or more in steady state, plus certification body fees each year. It should be treated as a standing operational cost, not a one-off project.

    Key cost drivers in industrial / regulated environments

    • Scope definition: Restricting scope (e.g., only certain data centers or specific product lines) reduces cost but can create complexity and may not align with customer expectations.
    • OT & legacy assets: Old PLCs, SCADA, lab equipment, and proprietary vendor systems often cannot meet modern security practices easily, so you compensate with procedures, network controls, and careful change control. This adds effort and sometimes hardware/network costs.
    • Coexistence with existing systems: You will need to work with, not replace, MES, ERP, PLM, QMS, and plant historians. Full replacement strategies are rarely cost-effective because of validation effort, downtime risk, and integration complexity. Expect cost in documenting interfaces, formalizing access control, and aligning change management.
    • Regulatory overlap: Where you already comply with sector standards (e.g., IEC 62443 for OT, export controls, customer-specific security requirements), some controls can be reused, reducing incremental cost but increasing documentation work to demonstrate mapping and traceability.
    • Process maturity: Plants with strong document control, CAPA, and change control (often due to quality system requirements) can usually adapt existing structures, which reduces new process design cost but increases the need for careful integration and cross-references.

    What should you budget for a first pass?

    Indicative planning numbers for an organization with several industrial sites and mixed IT/OT, assuming a reasonably defined but not yet mature security program:

    • External audit fees: budget on the order of USD 20k–80k over 3 years, depending on scope and size.
    • Consulting / advisory: a wide band, but USD 40k–150k is common if you want structured help and internal teams are not already experienced with ISO 27001.
    • Internal effort: plan for at least 0.5–2 FTE-years during initial implementation, distributed across roles; more for larger and more complex estates.
    • Tooling & remediation: highly variable. Some plants can leverage existing investments; others may face a step-change in monitoring, backup, or identity systems. Treat this as a separate security modernization budget, not just a “certification cost.”

    For a mid-sized industrial company, it is common for all-in cost (internal + external + tools) over the first 2–3 years to land in the low hundreds of thousands of USD, though narrower scopes or very mature organizations can be lower.

    Constraints, caveats, and how to get a real number

    Any concrete quote requires:

    • A clear definition of ISMS scope (sites, processes, systems, and data).
    • Basic inventory of IT and OT systems, including key vendors and integration points.
    • An honest view of current security maturity and documentation (policies, procedures, records).
    • Understanding of regulatory context and customer/security requirements already in force.

    Certification bodies can often give audit fee estimates quickly once they know your headcount-in-scope and sites. For total cost, you will need at least a high-level gap assessment or internal self-assessment to estimate internal effort and remediation work.

    ISO 27001 certification itself does not guarantee compliance with all cybersecurity or regulatory obligations, nor does spending more ensure a successful audit. Cost effectiveness comes from scoping carefully, reusing existing governance where possible, and planning for coexistence with your long-lived industrial and quality systems rather than trying to replace them wholesale.

  • What are the main challenges when integrating ISO 27001 with AS9100?

    Integrating ISO 27001 (information security management) with AS9100 (aerospace quality management) can reduce duplication, but it introduces non-trivial challenges, especially in brownfield, highly regulated manufacturing environments. The two standards are compatible in principle, yet they focus on different risk domains and operate on different technical realities on the shop floor.

    1. Different primary risk focus and language

    AS9100 is centered on product quality, safety, and regulatory conformity across the lifecycle of aerospace products. ISO 27001 is centered on confidentiality, integrity, and availability of information. When integrating, organizations often struggle with:

    • Different risk lenses: AS9100 risk thinking is often focused on nonconforming product and process failures, while ISO 27001 is focused on information assets, threat actors, and cyber events.
    • Terminology gaps: “Information asset,” “threat,” and “vulnerability” mean little to many production-focused stakeholders, while quality terms have less meaning to security teams.
    • Ownership conflicts: Quality usually owns AS9100; IT / security usually owns ISO 27001. Integrating into a single management system requires clear governance boundaries.

    If these perspectives are not reconciled deliberately, you tend to get parallel systems that share documents but not a common understanding of risk.

    2. Aligning risk assessment and risk treatment

    Both standards require structured risk assessment and treatment, but with different emphasis and tooling. Challenges include:

    • Different risk models: AS9100 often uses FMEA-type approaches and product/process risk matrices. ISO 27001 uses asset–threat–vulnerability models mapped to Annex A controls.
    • Single vs multiple risk registers: A forced single register can become unusable if it mixes deeply technical cyber risks with process and supplier risks without clear structure.
    • Risk acceptance criteria: The organization may tolerate higher cyber risk than product safety risk, or vice versa. Integrating systems requires explicit, documented criteria for each domain.

    Practically, many organizations keep separate but linked risk registers (quality/process vs information security) and define how risks interact, rather than trying to force one blended model.

    3. Overlapping documentation and document control

    Both standards require documented policies, procedures, and records under robust document control. In brownfield environments with legacy QMS and IT documentation, integration challenges include:

    • Redundant procedures: Separate change control, incident handling, and supplier evaluation procedures for quality vs. security are common. Integrating them without breaking existing approvals and training can be difficult.
    • Fragmented repositories: QMS documents may live in a validated document control system, while ISO 27001 policies live in IT tools or file shares. Harmonizing without revalidating everything is a recurring issue.
    • Traceability and versioning: When a common procedure is used as evidence for both standards, change control and traceability need to satisfy both sets of auditors, which increases documentation rigor and review overhead.

    Organizations often choose a single controlled repository for top-level policies and processes, while allowing domain-specific work instructions and technical configs to remain in specialized systems, linked by references.

    4. Integrating internal audit and management review

    Both standards require internal audits and management reviews. Integration saves effort but introduces complexity:

    • Audit competence: Auditors who are strong in AS9100 may not be competent to audit information security controls, and vice versa. Trying to use the same small team for all topics can create superficial audits.
    • Scope and sampling: A combined audit program must cover both production processes and information security controls (e.g., backup, access management, SOC processes). Proper sampling across both domains is harder to plan.
    • Management review content: A combined review must address quality KPIs and information security performance (incidents, vulnerabilities, control test results). That requires cross-functional input and more structured preparation.

    Many organizations adopt partially integrated audit programs, with joint planning and reporting but domain-specific audit execution where specialist knowledge is needed.

    5. Applying ISO 27001 controls to shop-floor and OT environments

    The largest practical challenge in industrial and aerospace manufacturing is mapping ISO 27001 controls to operational technology (OT) and production systems that are already constrained by AS9100 requirements and long lifecycles:

    • Legacy equipment: Plant assets may run unsupported operating systems, vendor-locked configurations, or certified software that cannot be changed without requalification and downtime risk.
    • Validated / qualified states: In aerospace and other regulated sectors, making cyber-hardening changes can trigger requalification, validation, or at minimum new evidence for configuration control and process capability.
    • Availability vs. security tradeoffs: ISO 27001 controls that look straightforward in IT (e.g., aggressive patching, network segmentation, strict access lockouts) can disrupt production, test systems, or calibration processes if not adapted carefully.

    In practice, many organizations implement ISO 27001 with explicit scoping decisions that limit the treatment of some OT risks, documenting compensating controls (monitoring, physical controls, procedural checks) where technical changes are not feasible without unacceptable production or compliance impact.

    6. Supplier, outsourcing, and data-sharing challenges

    Both standards have requirements around suppliers and external providers, but with different emphases:

    • AS9100: Focus on supplier quality, configuration control, flow-down of technical requirements, and traceability of materials and processes.
    • ISO 27001: Focus on third-party access to information, confidentiality, and security controls for service providers (including cloud, IT outsourcing, and data centers).

    Integrating these perspectives raises issues such as:

    • Contract language: Existing aerospace contracts and quality clauses may not include security requirements for handling design data, test data, or production data. Updating contracts at scale is slow and can face supplier pushback.
    • Supplier segmentation: Some suppliers are critical to product quality but have limited access to information; others handle sensitive design data but have minimal product impact. A single unified supplier risk model can obscure these differences.
    • Evidence collection: Quality often relies on certificates of conformity, process audits, and PPAP-like evidence, while security may require SOC reports, penetration test summaries, or security questionnaires. Maintaining both can be resource intensive.

    Practically, many organizations build a coordinated but dual-lens supplier program, where quality and security each have defined responsibilities but share a common supplier master data set and risk tiering.

    7. Change control across quality and security domains

    Both standards place strong emphasis on controlled change, but the drivers differ. Integrating them in a brownfield environment introduces specific hurdles:

    • Security-driven changes: Security teams may need to make urgent changes (e.g., blocking ports, patching a vulnerability, altering access) that affect validated test rigs, NC machines, or inspection systems that are subject to AS9100 controls.
    • Engineering-driven changes: Product or process changes may require new information flows, access patterns, or tools that alter the information security risk profile.
    • Multiple change boards: Parallel CABs (Change Advisory Boards) for IT and MRBs/ECBs for engineering/quality can cause misalignment or delays if not coordinated.

    The integration challenge is to define when a change must be evaluated under both frameworks, how impact is assessed, and how evidence is captured to satisfy both sets of requirements without paralyzing operations.

    8. Evidence, audit trails, and tool integration

    In mixed MES/ERP/PLM/QMS stacks with long equipment lifecycles, evidence management is a recurring pain point:

    • Fragmented systems: Quality evidence often resides in QMS, MES, and PLM; security evidence resides in ticketing tools, SIEM, or identity platforms. Aggregating evidence for combined audits is labor-intensive.
    • Validation burden: Replacing or centralizing tools (e.g., moving all CAPA and incident management into one platform) can trigger validation and qualification work that is costly and risky.
    • Traceability across domains: A single event (e.g., cyber incident affecting an inspection station) may require both an information security incident record and a nonconformance / CAPA record. Linking those traces in a defensible way is a real integration challenge.

    Most organizations end up with an integrated management system at the process and governance layer, while accepting that underlying tools will stay heterogeneous for the foreseeable future. Interfaces and cross-references become more realistic than total system replacement.

    9. Cultural and organizational challenges

    Beyond the technical aspects, integration depends heavily on culture and roles:

    • Competing priorities: Production and quality teams may see security controls as obstacles to throughput; security teams may underestimate constraints from validation and aerospace qualifications.
    • Training overload: Staff can experience fatigue from overlapping trainings (quality, safety, security, export controls), particularly if content is not harmonized.
    • Leadership focus: If top management treats ISO 27001 as an IT issue and AS9100 as a quality issue, the integrated system will be nominal only, with limited cross-domain decision-making.

    Deliberate cross-functional governance (e.g., a joint quality & security steering group) is usually needed to make tradeoffs explicit and recorded.

    10. Why full replacement strategies usually fail here

    Some organizations attempt to solve integration by replacing legacy QMS, MES, and security tooling with a single new platform. In aerospace-grade and similar contexts, this often fails or stalls because:

    • Qualification and validation burden: New tooling must be qualified, integrated, and often revalidated to satisfy both quality and regulatory expectations, which is expensive and time-consuming.
    • Downtime and cutover risk: Replacing systems that control production or manage aerospace product records carries substantial downtime and traceability risks.
    • Integration complexity: Existing interfaces to ERP, PLM, lab systems, and test rigs are typically brittle and bespoke; rebuilding them is non-trivial.

    Incremental integration of processes and evidence, while leaving core legacy systems in place and under control, is usually more realistic than a big-bang replacement when aligning ISO 27001 with AS9100.

  • Are FMEA or similar tools required by AS9100 for risk management?

    AS9100 does require risk management, but it does not require FMEA, FMECA, or any specific tool. FMEA is one recognized method for identifying and mitigating risk, yet the standard is written to be tool-agnostic.

    What AS9100 actually requires for risk management

    AS9100 (e.g., Rev. D, clause 6.1 and related clauses) expects you to:

    In practice, this connects to AS9100 compliance when teams need to turn the answer into repeatable execution habits.

    • Plan actions to address risks and opportunities related to product quality and conformity.
    • Define and apply a risk management process that is appropriate to your products and operations.
    • Establish criteria for risk acceptance, prioritization, and treatment.
    • Integrate risk thinking into planning, design and development, production, and change control.
    • Maintain documented information (evidence) showing how risks are identified, evaluated, mitigated, and reviewed.

    The standard does not name FMEA as a requirement. Certification bodies will not normally insist on FMEA specifically, provided your risk management approach is robust and traceable.

    Using FMEA and similar tools in an AS9100 context

    While not mandated, FMEA (or FMECA, hazard analysis, risk registers, etc.) is often used because it provides:

    • Structured identification of failure modes, causes, and effects at product or process level.
    • A way to prioritize issues using severity/occurrence/detection or similar scoring.
    • Clear linkage to controls, inspection plans, work instructions, and process changes.

    In regulated aerospace environments, FMEA or similar methods can also help tie together design inputs, process controls, inspection characteristics (e.g., for AS9102/FAI), and NCR/CAPA data. That said, an FMEA that is created once for audit and never maintained will not satisfy AS9100 expectations on risk being an ongoing discipline.

    What auditors typically look for

    Auditors generally focus on the effectiveness and consistency of your risk approach, not the brand name of the method:

    • Can you show how high-risk items are identified and prioritized?
    • Are risks linked to actions (controls, additional inspection, process changes, training, supplier controls)?
    • Is risk information kept current when there are engineering changes, process changes, supplier changes, or new NCR trends?
    • Is there traceability between risk assessments and downstream artifacts such as routers, work instructions, control plans, and inspection records?
    • Is risk management integrated into design reviews, MRB decisions, and CAPA, or is it a stand-alone form?

    If you can demonstrate these elements using another structured method (risk matrix, hazard analysis, bow-tie diagrams, etc.), that is typically acceptable.

    Brownfield and systems reality

    In most aerospace plants, risk management data ends up scattered across legacy QMS, spreadsheets, PLM, and MES/ERP. Introducing a new FMEA tool or module can be useful, but it also introduces:

    • Integration risk: keeping FMEA in sync with current BOMs, routings, and work instructions.
    • Change control burden: ensuring that engineering changes, supplier changes, and process changes trigger FMEA reviews.
    • Validation and qualification cost: if the tool feeds controlled documentation or is used as a quality record, it may require validation and documented change control.

    Trying to replace all existing risk-related artifacts with a single new tool often fails in long-lifecycle, regulated environments because of downtime constraints, integration complexity, and the need to preserve historical evidence. A more realistic approach is usually to:

    • Define a minimum, standard risk method (which may be FMEA-based) for new or changed products and processes.
    • Phase it in where the risk and payback are highest, instead of retrofitting every legacy part family at once.
    • Ensure that whatever tool you use feeds or aligns with your existing MES/ERP/QMS artifacts without breaking traceability.

    Practical takeaway

    You do not have to use FMEA to comply with AS9100, but you do need a disciplined, documented, and maintained approach to risk management. Choose tools that fit your process maturity and system landscape, and focus on traceability, integration with planning and change control, and evidence that risks drive concrete actions.

  • What is the role of PDCA in ISO 9001:2015?

    PDCA (Plan-Do-Check-Act) is the management and improvement cycle that ISO 9001:2015 is built around. The standard does not treat PDCA as an optional tool, but as the basic logic for how a quality management system (QMS) is planned, run, monitored, and improved.

    How PDCA maps to ISO 9001:2015 clauses

    ISO 9001:2015 is structured to follow PDCA across the whole QMS:

    In practice, this connects to the ISO 9001 quality baseline when teams need to turn the answer into repeatable execution habits.

    • Plan: Understand context and risks, define processes and objectives.
      • Key clauses: 4 (Context of the organization), 5 (Leadership), 6 (Planning), selected parts of 7 (Support).
      • Typical activities: defining process interactions, setting quality objectives and KPIs, risk-based thinking, resource and competence planning, document and data control strategies.
    • Do: Operate the processes as planned and controlled.
      • Key clause: 8 (Operation).
      • Typical activities: executing production and service provision, managing changes, controlling external providers, using work instructions, travelers, inspection plans, and production records.
    • Check: Monitor performance and compliance to planned arrangements.
      • Key clause: 9 (Performance evaluation).
      • Typical activities: process and product monitoring, analysis of production and quality data, internal audits, management review, supplier performance review.
    • Act: Take action based on what was learned to improve the QMS and its processes.
      • Key clause: 10 (Improvement).
      • Typical activities: corrective action, addressing nonconformities, preventive and risk-based actions, structured continuous improvement projects, updating procedures and controls under change control.

    Role of PDCA in a regulated, brownfield environment

    In industrial and aerospace-grade operations, PDCA is not a separate “tool” layered on top of existing systems. It is the way you coordinate them:

    • Plan often lives across multiple systems: requirements in ERP/PLM, risk registers, process maps, and controlled procedures in QMS or document control tools.
    • Do is executed via legacy MES, paper or hybrid travelers, machine controls, MRO systems, and supplier portals that cannot be simply replaced without major requalification and downtime.
    • Check relies on data pulled from these disparate systems: QMS (NCRs/CAPA), MES or travelers (as-built, scrap, rework), ERP (delivery and cost), and audit findings.
    • Act must respect change control, validation, qualification of equipment and software, and the long lifecycle of assets and documentation.

    Because of this, PDCA in ISO 9001:2015 is less about installing a new improvement program and more about ensuring that your existing planning, execution, monitoring, and improvement mechanisms are deliberately connected, traceable, and operating as a closed loop.

    What PDCA does and does not guarantee

    • PDCA supports compliance and audit readiness by providing a repeatable way to plan, execute, check, and improve your QMS.
    • PDCA does not guarantee certification outcomes or regulatory compliance. Results depend heavily on process discipline, data integrity, operator adoption, and integration quality across MES/ERP/QMS and shop-floor systems.
    • In practice, many failures in ISO 9001 systems come from PDCA breaks: changes implemented without proper planning or validation, data not reviewed, audit findings not acted on, or improvements not embedded into controlled documentation and training.

    Using PDCA effectively with existing systems

    For most regulated plants, trying to replace all legacy systems to “get PDCA” is high risk and often unsuccessful because of validation cost, downtime, and integration complexity. A more practical approach is to:

    • Make explicit which existing tools and processes play each PDCA role for each major value stream.
    • Ensure traceability between Plan (requirements and risks), Do (records), Check (metrics, audits), and Act (CAPA, engineering changes, procedure updates).
    • Align PDCA cycles with formal management review, MRB, and CAPA processes so improvement actions are documented, reviewed, and controlled.
    • Use digitalization projects (for example, digital travelers or nonconformance workflows) to close specific PDCA gaps instead of attempting a full QMS/ERP/MES replacement.

    In summary, PDCA is the organizing logic of ISO 9001:2015. Its role is to ensure that planning, operation, evaluation, and improvement of your QMS form a controlled, evidence-based loop across the many systems and processes already in place.