Does my AS9100 corrective-action system count as CMMC incident response?

The Question

"We are mapping our AS9100 Rev D quality manual to NIST 800-171. For Incident Response (Family 06), we want to point directly to our existing nonconformance and corrective action procedure (CAR/CAPA). Does an assessor consider an IT security incident a 'nonconformance' that can be handled through a standard quality CAR, or do we need a standalone IT incident response plan?"

The Discipline

Your AS9100 CAPA process can serve as the governing workflow for incident response, but only if it is explicitly extended to cover cyber-specific preparation, detection, analysis, containment, recovery, internal and external reporting, evidence preservation, and testing. It does not automatically satisfy CMMC incident response by virtue of being a corrective-action process.

When a calibrated gauge drops out of tolerance, your quality system triggers a deeply ingrained discipline: detect the deviation, document it in a nonconformance record, contain the suspect product, investigate the root cause, implement a corrective action, and verify that the action prevented recurrence. When a user clicks a malicious link or a laptop containing CUI is misplaced, the required organizational response covers the same six activities — and adds two more that NIST SP 800-171 §3.6.1 names explicitly: preparation (the procedure exists, is trained, and is resourced before the incident) and recovery (restoring affected systems and validating their integrity post-incident).

A C3PAO is not assessing the title of the document. The assessor is assessing whether the organization has objective evidence of an operational incident-response capability. That evidence may be contained in a standalone incident response plan, a cyber-incident annex to the AS9100 CAPA procedure, the SSP, training records, tabletop records, incident records, and after-action evidence.

To successfully use your existing AS9100 CAPA process to satisfy the Incident Response family, four extensions must be explicitly documented in both your quality manual and your System Security Plan:

1. Definition of Trigger and Detection. Your procedure must explicitly define a cyber incident (e.g., unauthorized access to CUI, suspected malware, lost device) as a trigger for a nonconformance report, and name the detection mechanisms — log monitoring, alerts, user reports — through which an incident becomes known. Define in your CAPA procedure who has authority to determine "this is a cyber incident" — typically the Quality Manager with concurrence from IT — and document the determination timestamp on the CAR record. The CAR record must rigorously timestamp the moment of discovery; the 72-hour clock runs from then, not from incident occurrence.

2. DFARS Reporting, Notification, and Preservation. A cyber incident involving covered defense information carries a strict contractual reporting requirement under DFARS 252.204-7012(c)(1)(ii). Your CAR procedure must establish a defined path for rapidly reporting cyber incidents to DoD within 72 hours of discovery through DoD’s DFARS cyber-incident reporting channel, including the DIBNet/DC3 DCISE Incident Collection Format process as maintained by DC3. Portal access requires a DoD-approved medium assurance certificate (CAC or ECA). Because certificate issuance can take time, access should be established before an incident occurs. ECA certificates are available from DoD-approved Certificate Authorities at public.cyber.mil/eca/. If a sub-tier supplier handles covered defense information, the CAPA/IR procedure should include a supplier-incident notification path. DFARS 252.204-7012(m) requires subcontractors to provide the DoD-assigned incident report number to the prime or next higher-tier subcontractor as soon as practicable. As a practical control, add a 24-hour supplier-to-contractor notice obligation so the prime can determine whether customer notification, contract coordination, or a separate report is required. The procedure should also require preservation of affected-system images and relevant monitoring or packet-capture data for at least 90 days after submission of the cyber incident report, consistent with DFARS 252.204-7012(e).

3. IT Resource Integration, Preparation, and Recovery. While the Quality Manager owns the envelope of the corrective action (tracking, verifying closure), your IT resource must be formally designated as a required participant in detection, analysis, containment, and recovery for cyber events. Preparation — the IR procedure documented, the IT resource resourced, training delivered — must be in place before an incident.

4. Testing the IR Capability. NIST SP 800-171 §3.6.3 requires the organization to test the incident response capability. A normal AS9100 internal audit that merely checks whether the procedure exists is not IR testing. A tabletop, simulation, or actual incident exercise may satisfy the testing expectation if it exercises the cyber-incident workflow, produces records, captures lessons learned, and drives corrective actions through closure.

If your quality manual and SSP explicitly account for these four extensions, and the process is trained, tested, and evidenced, your existing AS9100 CAPA process can serve as the operating spine of a mature incident-response system. The QM's next deliverable is the SSP language for IR.L2-3.6.1, 3.6.2, and 3.6.3 that maps each subrequirement's assessment objectives to the CAPA process and the four extensions above. The SSP can cross-reference QMS procedures (e.g., "see Quality Manual §10.2.1 with extensions and §3.6.3 testing protocol"); duplicate procedure documentation is not required. This alignment also strengthens the truthfulness of your SPRS affirmation: the affirmed controls are the controls you actually run. You do not need to invent a parallel universe for IT.