Executive Message
As your organization pursues CMMC Level 2, AI-enabled development, automation, source code, infrastructure, and deployment processes must be governed when they touch CUI, support CUI systems, or can change the security posture of the CUI environment. CMMC Level 2 aligns to the security requirements in NIST SP 800-171; the first question for any control is always which systems process, store, transmit, or protect CUI.
Key point: Without CI/CD governance and monitoring, the organization may struggle to prove who changed what, why it changed, whether it was reviewed, whether security checks passed, and whether deployment activity was authorized — for the systems inside or adjacent to the CUI boundary.
“CMMC Level 2 is not asking you to stop using AI or automation. It is asking you to prove that the use of AI, code, infrastructure, and deployment automation is controlled, monitored, and evidence-backed wherever it touches or protects CUI.”
Why This Matters for CMMC Level 2
Compliance Risk
Evidence Gaps
If build, test, approval, and deployment activity is not logged and retained, the company may not be able to demonstrate effective controls during assessment.
Security Risk
Unauthorized Change
Developers, tools, or AI agents may introduce code, scripts, dependencies, or infrastructure changes without proper review.
Business Risk
Life Sciences Sensitivity
In a life sciences environment, AI and automation may touch regulated workflows, IP, research data, quality systems, PHI, customer data, and potentially CUI. For CMMC, the key question is which of those systems process, store, transmit, or protect CUI.
Primary Areas They Need to Govern
| Area | What They Need | Why It Matters |
|---|---|---|
| Source Code Governance | Branch protection, pull request reviews, no direct production commits, signed commits where practical, least-privilege repository access. | Creates accountability and prevents unreviewed changes. |
| Secure CI/CD Pipeline | Automated build, test, security scan, approval, deployment, rollback, and evidence capture. | Turns deployment into a repeatable, auditable control process. |
| AI Governance | Approved AI tools, rules for CUI and sensitive data, prompt logging, human review of AI-generated code, model/version governance. | Prevents uncontrolled disclosure, hallucinated code, unapproved automation, and untraceable AI-driven changes. |
| Secrets Management | No keys or passwords in code. Use a managed vault, rotation, short-lived credentials, and controlled service identities. | Reduces the risk of credential theft and accidental exposure. |
| Software Supply Chain | Dependency scanning, SBOMs, pinned versions, artifact signing, container scanning, approved packages. | Protects against malicious or vulnerable third-party components. |
| Infrastructure as Code | Version-controlled Terraform, Bicep, CloudFormation, or similar IaC with peer review and security scanning. | Prevents uncontrolled manual infrastructure changes and configuration drift. |
| Monitoring & Alerting | Monitor repository changes, pipeline failures, deployment events, permission changes, secrets exposure, and production drift. | Enables timely detection and response. |
| Evidence Retention | Preserve approvals, build logs, test results, scan results, deployment records, artifact hashes, and audit trails. | Supports CMMC assessment and operational accountability. |
Required vs. recommended: Some items above — signed commits, SBOMs, artifact signing, pinned versions, and container signing — are strong DevSecOps practices rather than explicit CMMC Level 2 requirements. Treat them as recommended maturity unless tied to a specific control implementation in the organization's SSP. What CMMC drives is that changes to CUI-relevant systems are controlled, reviewed, monitored, and evidence-backed; the specific mechanism is a design choice.
Minimum CI/CD Governance Controls
Must Have
Change Control
- All changes tied to a ticket, work item, or approved request.
- Pull request required before merge.
- Production branch protected.
- Emergency changes documented after the fact.
Must Have
Security Gates
- Secret scanning.
- Dependency vulnerability scanning.
- Blocking rules for critical findings.
Where applicable to the environment: SAST / code scanning, container scanning, and IaC scanning — apply these where custom code, containers, or infrastructure-as-code are actually in use. Treat them as strongly recommended rather than universal.
Important
Approval & Segregation
- Developer cannot independently approve and deploy high-risk production changes.
- Security approval for sensitive systems.
- Clear production release authority.
- Role-based access to pipeline environments.
Important
Deployment Integrity
- Deploy only from approved artifacts.
- Track artifact hash/version.
- Maintain rollback plan.
- Log who approved and who deployed.
AI-Specific Controls to Discuss
AI adds a new layer of risk because it can generate code, scripts, configuration, test data, prompts, documentation, and automation logic. These outputs need to be governed before they affect production or sensitive environments.
| AI Question | Expected Governance Answer |
|---|---|
| Can developers use public AI tools? | Only approved tools, with clear rules on what data may be entered. |
| Can CUI, PHI, IP, research data, or customer data be pasted into prompts? | No, unless the platform is approved for that data classification and contractual controls are in place. |
| Can AI-generated code be committed? | Yes, only after human review, testing, security scanning, and traceable approval. |
| Can AI agents execute actions? | Only through approved tools, least-privilege identities, policy checks, logging, and human approval for high-risk actions. |
| Are prompts and outputs logged? | Risk-based. For business, compliance, or production-impacting workflows, retain enough to show user, tool, purpose, data classification, approval, output disposition, and change linkage. Do not retain CUI or PHI in AI logs unless the logging platform is approved for that classification — a prompt log full of sensitive data is itself a new exposure. |
| Are models and prompts versioned? | Yes, especially where outputs affect regulated or operational decisions. |
Map This to CMMC / NIST SP 800-171 Control Families
The behaviors above are not abstract best practice — each one supports specific control families an assessor will look at. This mapping shows the customer how the work lines up with the assessment. It is a support map, not a claim that any single practice satisfies a control.
| Governance area | CMMC / NIST SP 800-171 family it supports |
|---|---|
| Repository access, branch protection, least privilege, service identities | Access Control; Identification & Authentication |
| Pull requests, approval, release authority, configuration control | Configuration Management |
| Pipeline logs, deployment records, evidence retention (incl. the RAIVS audit chain, Airiam's Risk-Adaptive AI Verification System) | Audit & Accountability; Security Assessment |
| Secrets management, vaulting, service identities | Access Control; Identification & Authentication; System & Communications Protection |
| Vulnerability, dependency, code, container, and IaC scanning | System & Information Integrity; Risk Assessment |
| IaC review and drift detection | Configuration Management |
| AI tool approval and CUI data-use rules in prompts | Access Control; Awareness & Training; Configuration Management; System & Communications Protection |
| Human approval for high-risk AI/automation actions; separation of duties | Access Control; process accountability |
| Monitoring and alerting | Audit & Accountability; System & Information Integrity |
| Incident, exception, and bypass handling | Incident Response; System & Information Integrity |
Say “supports,” not “satisfies.” These practices help operationalize and evidence controls that support CMMC Level 2 readiness. Final applicability depends on the organization's CUI boundary, SSP, shared-responsibility model, and C3PAO expectations.
Monitoring They Should Put in Place
Repository Monitoring
- Permission changes
- Branch protection changes
- Direct commits to protected branches
- Secrets committed to code
Pipeline Monitoring
- Failed builds
- Failed security scans
- Bypassed approvals
- Manual deployment overrides
Runtime Monitoring
- Infrastructure drift
- New privileged identities
- Unexpected network exposure
- Unauthorized configuration changes
Recommended Implementation Roadmap
| Phase | Focus | Outcome |
|---|---|---|
| Phase 1: Baseline | Inventory repositories, pipelines, AI tools, automations, secrets, environments, and deployment paths. | Clear understanding of current risk and compliance gaps. |
| Phase 2: Control the Change Path | Implement branch protection, pull requests, code owners, access reviews, and production approval rules. | No unmanaged path from developer workstation to production. |
| Phase 3: Add Security Gates | Add secret scanning, SAST, dependency scanning, IaC scanning, container scanning, and test evidence capture. | Security and quality checks become part of every release. |
| Phase 4: Govern AI Use | Approve AI tools, define data rules, require human review, log AI-assisted development activity, and govern AI agents. | AI becomes productive without becoming uncontrolled. |
| Phase 5: Continuous Monitoring | Alert on high-risk repo, pipeline, identity, infrastructure, and deployment events. | Control effectiveness is monitored continuously, not just before assessment. |
| Phase 6: Evidence Automation | Centralize logs, approvals, scans, releases, artifacts, and exception records. | Assessment evidence is produced as a byproduct of normal operations. |
Questions to Ask the Customer
Development & CI/CD
- Where is source code stored?
- Who can approve changes?
- Who can deploy to production?
- Are branches protected?
- Are security scans required before release?
- Can deployments be traced to a ticket or request?
AI & Automation
- What AI tools are developers using?
- Are prompts and outputs logged?
- What data is prohibited in AI prompts?
- Can AI agents run scripts or modify systems?
- Are AI-generated changes reviewed by humans?
- Are models, prompts, and automations versioned?
| Area | Question that drives scope |
|---|---|
| Scope | Which repositories, pipelines, AI tools, automation tools, and cloud environments are inside or adjacent to the CUI boundary? |
| Data | Can CUI, CDI, ITAR/export-controlled data, PHI, research data, or customer IP enter AI tools, prompts, logs, or automations? |
| Evidence | Where will assessment evidence live, who owns it, and how long is it retained? |
| Authority | Who can bypass branch protection, pipeline gates, emergency approvals, or production deployment controls? |
| Agents | Can any AI agent, RPA bot, script, or automation account modify systems, tickets, code, infrastructure, or data? |
| Exceptions | How are emergency changes, failed scans, bypasses, and compensating actions documented? |
| External providers | Are any MSPs, MSSPs, cloud providers, AI vendors, or development contractors in scope or supporting in-scope assets? |
Closing Message
Recommended position: The organization does not need to stop development or slow innovation. It needs a governed, monitored, and evidence-producing development lifecycle that includes AI, automation, source code, infrastructure, deployment, and runtime operations.
“The goal is to make secure delivery the default path. Developers should not have to choose between moving fast and staying compliant. The pipeline should make the approved path the easiest path.”
CMMC and ISO 42001: how they fit together
AI and automation rarely stay neatly inside one boundary, so it helps to separate the compliance driver from the governance framework:
| Where it applies | What governs it |
|---|---|
| The CUI environment (DoD contract scope) | CMMC Level 2 / NIST SP 800-171 — the compliance requirement. |
| AI touching or protecting CUI systems | Governed as part of CMMC control implementation and evidence. |
| AI used across the business, outside the CUI boundary | ISO/IEC 42001 — an AI management-system framework we recommend for responsible, auditable AI use. Valuable, but not legally mandatory unless a contract, customer, or regulator requires it. |
The bridge, said plainly: For CUI, CMMC Level 2 drives the requirement. For AI used outside the CUI boundary, ISO/IEC 42001 gives the governance structure so AI adoption stays controlled, auditable, and responsible. CMMC is the floor where CUI lives; ISO 42001 is the AI-governance layer across the rest of the business. We do not present ISO 42001 as legally required, and we do not say either framework is “satisfied” by any single practice.