How do we handle nonconformities that affect both quality and security?

Handle nonconformities that affect both quality and security as a single, linked issue that is processed through both your quality management and cybersecurity processes. Splitting them into separate tracks without coordination usually creates gaps in risk assessment, corrective actions, and evidence for audits.

1. Establish clear criteria for “quality + security” nonconformities

First define what qualifies as a joint issue in your context. Typical triggers include:

• Product or process nonconformance that is suspected to be caused by a cyber incident (e.g., tampered parameters, manipulated test results, unauthorized MES changes).
• Security incidents that may have altered manufacturing records, recipes, configurations, or evidence needed for product release or traceability.
• Compromise of systems that are part of validated or qualified processes (e.g., MES, historians, QMS, equipment controllers) where integrity of quality data is uncertain.

The exact criteria depend on your risk assessment, system landscape, and regulatory obligations. Document them in procedures so operations, quality, and IT/OT security interpret events consistently.

2. Use a single master record with cross-links to QMS and security

In brownfield environments, you typically will not have a single system that can cleanly own both quality and security workflows. Instead:

• Create one master record in the system that has the strongest regulatory traceability requirements, usually the QMS (e.g., nonconformity or CAPA record).
• Open a corresponding security/incident ticket in the corporate incident response tool or OT security system.
• Link the records explicitly using IDs in both directions and reference them in deviation reports, risk assessments, and change control.

Do not rely only on email or informal notes for these links. The master record should clearly state that security and data integrity are in scope so reviewers can see the full context.

3. Run a joint impact and risk assessment

Assess impact across both quality and security dimensions before deciding on containment or release decisions.

At minimum, consider:

• Product and patient/customer impact: Could altered data or process steps affect safety, performance, regulatory compliance, or field reliability?
• Data integrity: Are historical records, batch data, test results, or genealogy still trustworthy? How far back could compromise extend?
• System scope: Which systems (MES, PLCs, DCS, LIMS, QMS, ERP) may have been affected? Are any validated or qualified?
• Regulatory and contract requirements: Are there obligations to notify regulators, certification bodies, or customers for security-related quality risks?
• Containment risk: Could security containment actions (e.g., isolating a line, blocking accounts, patching) create new process or quality risks?

This assessment should be performed collaboratively by quality, operations/engineering, and IT/OT security, not by one function alone.

4. Coordinate containment across production, quality, and IT/OT

Containment must limit both quality and security impact, while recognizing constraints on downtime and validation:

• Stabilize the process: Pause affected lots/batches, label and segregate suspect material, and freeze product release decisions until minimum integrity is established.
• Secure the environment: IT/OT may isolate systems, disable accounts, or roll back configurations, but should coordinate with operations to avoid unsafe or uncontrolled shutdowns.
• Preserve evidence: Ensure logs, configuration snapshots, and relevant batch records are preserved before systems are rebuilt or restored.

Document containment decisions and tradeoffs, especially if security best practices must be staged or adapted to avoid unplanned outages of validated systems.

5. Perform integrated root cause analysis

Root cause analysis should explicitly consider both process/quality and cybersecurity contributing factors. Common patterns include:

• Process & equipment: Poor parameter control, inadequate verification of setpoints, missing independent checks.
• Human factors: Shared credentials, bypassed controls, unvetted changes to master data or recipes.
• Technical controls: Inadequate network segmentation, weak access control, insufficient integrity monitoring, missing change logs.
• Management systems: Gaps in training, procedures, and change control covering both quality and security for OT systems.

If you use formal methods (e.g., 5-Whys or fishbone diagrams), show explicitly where security-related causes and controls come into play. This is important for auditability and for preventing recurrences that cross domains.

6. Design CAPAs that address both domains

Corrective and preventive actions must be coherent across quality and security. Typical actions might include:

• Process corrections: Rework, additional inspection, or product recall decisions based on validated data integrity and risk criteria.
• Security hardening: Strengthening authentication, tightening change control on recipes/configurations, improving logging, or implementing OT security monitoring.
• Data integrity measures: Rebuilding trust in data sets (e.g., re-running critical tests, cross-checking manual records, reconciling batch histories).
• Governance changes: Updating procedures to require security review for changes to validated systems, training operators and engineers on cyber-impacted nonconformities.

Be explicit about which system owns each action (QMS, ITSM, OT maintenance system, MES change workflow) and ensure due dates and effectiveness checks are aligned. Avoid duplicating the same action in multiple systems without synchronization.

7. Respect validation, change control, and legacy system constraints

In regulated, long-lifecycle plants, many quality-critical and OT systems are validated or qualified, and cannot be rapidly replaced or heavily modified without significant cost and downtime. When handling joint quality/security nonconformities:

• Expect that “ideal” security fixes (e.g., rapid patching, architecture overhauls, replacing legacy controllers) may not be immediately feasible for validated equipment and software.
• Use layered mitigations where needed, such as procedural controls, monitoring, or network-level protections, while planning longer-term validated changes.
• Ensure any configuration change, patch, or system restoration follows documented change control and, where required, revalidation or verification.

Full system replacement solely to resolve a combined quality/security issue is rarely practical in aerospace-grade or similarly regulated environments, due to qualification burden, revalidation cost, integration complexity, and extended downtime risks. Plan phased, risk-based improvements instead.

8. Maintain traceability and audit-ready documentation

Because these events cut across domains, documentation and traceability are critical:

• Retain a complete chain of records: initial detection, risk assessment, decision logs, containment, root cause analysis, CAPAs, and effectiveness checks.
• Ensure traceability from affected lots/batches and equipment to the nonconformity, and from the nonconformity to the associated security incident records.
• Capture rationale for decisions, especially where business continuity or validation constraints limited the speed or scope of security changes.

This documentation supports regulatory inspections, customer audits, and internal reviews, but it does not guarantee any specific compliance or certification outcome.

9. Define ownership and communication paths

Clarity on roles and escalation is essential before an event occurs:

• Assign a lead function for joint issues, often quality for product-impacting events, with IT/OT security as co-leads for cyber incidents.
• Predefine when to involve site management, corporate security, legal, and regulatory affairs.
• Ensure operators and engineers know how to recognize and report issues that may have a security origin (e.g., unexplained parameter changes, inconsistent MES data).

Periodic drills or tabletop exercises that include both nonconforming product scenarios and security incidents can expose gaps in your current approach.

10. Fit the approach to your existing systems and maturity

The specifics of handling joint quality/security nonconformities depend heavily on:

• Which systems you have in place (QMS, MES, ERP, ITSM, OT monitoring) and how well they are integrated.
• Your current validation state, documented procedures, and data integrity controls.
• The regulatory frameworks and customer expectations that apply to your products and markets.

Where tooling integration is weak, focus on clearly defined procedures, roles, and record-linking conventions. Over time, you can incrementally improve system integrations to reduce manual effort and the risk of things “falling between” quality and security workflows.