DFARS 7012 + NIST 800-171
Mapping DFARS 7012 and NIST 800-171 Controls to AI on Your ERP
Short answer
DFARS 252.204-7012 requires adequate security for Covered Defense Information under NIST SP 800-171, and that obligation does not pause for AI - any AI system touching CDI in your ERP has to be mapped, control by control, the same way every other in-scope system is. The practical path is designing the AI stack against the specific control families (AC, AU, IA, SC, SI, CM) from day one, so a Compliance Manager can produce control-by-control evidence instead of a vendor's generic security claims. That evidence also has to cover the 72-hour DoD cyber incident reporting clock if the AI system ever touches an incident involving CDI.
- ERP
- SAP S/4HANA, Infor SyteLine, Deltek Costpoint, Oracle EBS
- Industries
- Aerospace, Defense, Electronics
- Written for
- Compliance Manager
DFARS 252.204-7012 is not a suggestion, it is a contract clause that requires you to provide adequate security for covered defense information, defined largely by reference to the 110 controls in NIST SP 800-171. When your ERP holds CDI - technical data, program information, unclassified controlled data tied to a DoD contract - the clause reaches every system that processes it, and an AI layer bolted onto that ERP is not exempt just because it is new.
The gap most compliance teams hit is not disagreement about whether AI needs to be covered, it is a mapping problem. Your control matrix has 110 rows, each with assessment objectives under NIST SP 800-171A, and most AI vendors hand you a SOC 2 report or a generic security whitepaper that does not map cleanly to any of them. You end up doing the mapping yourself, after the fact, which is slower and riskier than designing the system against the control language from the start.
There is also a reporting obligation that gets missed in AI conversations: DFARS 7012 requires reporting a cyber incident within 72 hours of discovery if it involves CDI. If your AI system processes CDI and something goes wrong - a misconfigured access control, an unexpected data exposure - that clock applies to it exactly as it applies to any other system in scope, and you need log data detailed enough to build an incident timeline fast.
This page walks through the control families most relevant to an AI layer on an ERP, what evidence a Compliance Manager should expect to produce, and how to structure the system so that mapping work happens once, during design, instead of every time someone asks for evidence.
What usually gets in the way
The problems we hear most from compliance manager teams running SAP S/4HANA.
Vendor security claims do not map to control language
A SOC 2 Type II report or an ISO 27001 certificate is useful context but does not answer, control by control, how a specific AI feature satisfies AC-3 access enforcement or AU-6 audit review, which is what your control matrix needs.
The 72-hour reporting clock includes AI-adjacent incidents
If CDI flows through an AI system and something goes wrong, the same DFARS 7012 incident reporting timeline applies, but many AI deployments were not built with the log granularity needed to build a timeline fast.
Flow-down ambiguity when the AI vendor is a subcontractor
If an AI vendor is effectively a subcontractor processing CDI, the flow-down of 7012 obligations to that vendor needs to be explicit in the contract, and many SaaS AI agreements were not written with that in mind.
Off-the-shelf AI tools skip logging and configuration controls
Consumer-oriented AI assistants are rarely built with the audit (AU) and configuration management (CM) control families in mind, leaving a documentation gap a Compliance Manager has to fill manually or flag as a risk.
Mapping happens too late to influence design
When control mapping is done after a system is already built, the answer is often we cannot fully satisfy this control, which forces a retrofit instead of a clean implementation.
Where AI earns its place in SAP S/4HANA
Each use case names the ERP objects it reads or writes, so your ERP team can judge the integration effort before anyone commits budget.
Control narrative drafting per family
Draft first-pass control implementation narratives for the control families the AI architecture touches, using the actual configuration of the connectors, logging pipeline, and access model as source material.
Touches: AI connector configuration, ERP role tables, network segmentation documentation
Outcome: reduces the drafting burden for control families the AI system directly affects
Access control (AC) evidence generation
Produce a current snapshot of which roles can query which ERP data through the AI layer, formatted to match AC family assessment objectives.
Touches: ERP role/permission tables, AI query access control configuration
Outcome: cuts the time to assemble AC evidence ahead of an internal or DIBCAC assessment
Audit log (AU) summarization for periodic review
Condense raw AI query and response logs into a review-ready summary aligned to AU-6 audit review requirements.
Touches: AI query/response audit log, ERP transaction log correlation
Outcome: turns a periodic audit review into a focused read instead of a raw log export
Incident timeline drafting support
Assemble a draft incident timeline from AI and ERP logs around a suspected incident window, to accelerate the documentation needed inside the 72-hour reporting clock.
Touches: AI audit log, ERP access log, network log correlation for the incident window
Outcome: shortens the time to a documented, reportable timeline during an active incident
POA&M item drafting for AI-related gaps
Draft Plan of Action and Milestones language for any temporary gap identified during AI system rollout, tied to the specific control and remediation step.
Touches: Configuration baseline exports, prior assessment findings
Outcome: reduces time compliance staff spend translating technical gaps into POA&M language
SSP control narrative drafting from configuration data
Generate draft SSP language describing how the AI system's configuration satisfies specific controls, for compliance staff to review and finalize.
Touches: AI system configuration, ERP connector settings, network architecture documentation
Outcome: shortens SSP update cycles when the AI system's configuration changes
Media protection (MP) documentation for model artifacts
Document where model weights, embeddings, and cached data are stored and how they are protected and sanitized, to satisfy MP family evidence needs.
Touches: Model storage configuration, data retention and deletion procedures
Outcome: closes a documentation gap that is easy to overlook for AI-specific storage
Reference architecture
The architecture is organized around the NIST SP 800-171 control families most relevant to an AI layer, so each layer of the stack has a clear answer to which controls it implements and what evidence it produces.
- 1
Access control layer (AC, IA)
Query access is enforced against the same role and identity attributes the ERP already uses, so access control decisions are made once and inherited, not re-implemented in the AI layer.
- 2
Audit and accountability layer (AU)
Every query, retrieved document, and generated response is logged with user identity, timestamp, and data touched, in a format that supports both periodic AU-6 review and incident reconstruction.
- 3
System and communications protection (SC)
Data in transit between the ERP, the retrieval layer, and the model is encrypted, and outbound internet access is disabled at the network layer for any component touching CDI.
- 4
Configuration management (CM)
Model versions, connector configurations, and the retrieval index are version-controlled and change-managed under the same process as other in-scope systems.
- 5
System and information integrity (SI)
Model outputs touching CDI are logged and, where write-back is possible, require human approval, giving you a documented integrity check point rather than an autonomous action.
Integration notes for your ERP team
- The AI system's access control model is built as a thin layer over existing ERP role definitions, not a parallel permission system that would need its own separate AC evidence.
- Logs from the AI layer are structured to correlate with ERP transaction logs by user and timestamp, so an incident timeline can be assembled from both sources together.
- Encryption in transit uses the same certificate and key management infrastructure already covering ERP traffic, avoiding a second PKI to document.
- Model and connector configuration changes go through the same change control process as other in-scope system changes, with version history retained for CM evidence.
- Any AI vendor or subprocessor relationship is documented in enough detail to support flow-down language in subcontracts, including where data is hosted and who can access it.
- Data retention and deletion for AI-specific artifacts (embeddings, cached responses) follows the same schedule as other CDI-touching records, documented for MP family evidence.
- A control-to-architecture-component mapping document is produced during design, not requested after the fact, so evidence generation for an assessment is a lookup, not a research project.
Deployment options
Air-gapped on-prem
Contractors who want the simplest possible boundary story for SC and CM controls
Removing the external network path simplifies several control narratives at once, particularly SC-7 boundary protection, because there is no external boundary for CDI to cross.
Private or dedicated-tenancy cloud
Contractors needing elastic capacity while keeping personnel and hosting location control
A dedicated tenancy under your control lets you specify hosting region, administrative access, and encryption key ownership in the service agreement, which supports SC and AC control narratives.
Hybrid
Contractors with only part of their ERP handling CDI
CDI-touching modules run in a tightly controlled segment while non-CDI operational data can run more broadly, reducing the scope of the strictest controls to only the data that needs them.
Compliance and data control
How the architecture supports your obligations. Certification and accountability stay with your organisation; the design keeps the evidence straightforward.
DFARS 252.204-7012
The AI system is treated as a system that may process CDI, with adequate security controls implemented and the 72-hour incident reporting timeline supported by sufficiently detailed AI-layer logging.
NIST SP 800-171 (AC family)
AI query access inherits ERP role and permission checks, so access enforcement is evaluated once against the same evidence used for the rest of the environment.
NIST SP 800-171 (AU family)
Full logging of AI queries and responses supports both periodic audit review and rapid incident reconstruction within the reporting window.
NIST SP 800-171 (SC family)
Encryption in transit and at rest, plus disabled outbound internet access for CDI-touching components, supports boundary and communications protection control narratives.
NIST SP 800-171 (CM family)
Model, connector, and index configurations are version-controlled, giving the Compliance Manager a clear baseline to compare against during an assessment.
Where Netray fits
Custom build
Control narrative drafting, incident timeline assembly, and POA&M support are specific enough to your control matrix and ERP configuration that a purpose-built system beats a generic compliance tool.
ERPray
For CDI-touching question answering over ERP data, ERPray's read-only design and visible underlying query support the AC and AU evidence a Compliance Manager needs to produce.
How an engagement runs
Phase 1 . 2-3 weeks
Discovery
- -Review of current control matrix and where the ERP and any existing AI tools already sit against it
- -Interview with the Compliance Manager on evidence gaps and upcoming assessment timelines
- -Control family impact map for the proposed AI architecture
- -Draft mapping document from architecture components to specific NIST SP 800-171 controls
Phase 2 . 6-8 weeks
Pilot
- -One or two use cases live with logging validated against AU family expectations
- -Access control tested against real CDI-scoped roles
- -Sample evidence package generated for internal review
- -Incident timeline drill using pilot logs to validate 72-hour reporting readiness
Phase 3 . 8-12 weeks
Production
- -Pilot use cases hardened and extended
- -Control narratives finalized and folded into the SSP
- -POA&M items closed or updated
- -Evidence generation process documented for repeat use
Phase 4 . ongoing
Scale
- -Additional use cases added with the same control mapping discipline
- -Periodic control evidence refresh ahead of assessments
- -Incident response runbook updates as the AI system evolves
- -Support extending the mapping to additional in-scope systems
Questions to ask any vendor, including us
A short list that separates real SAP S/4HANA AI work from a chatbot demo.
- Can you provide a control-by-control mapping from your architecture to the specific NIST SP 800-171 controls we need to evidence?
- How does your logging support building an incident timeline fast enough to meet the 72-hour DFARS 7012 reporting requirement?
- If you are a subcontractor to us for this system, what flow-down language do you expect in our agreement?
- What encryption standards and key management does the system use for data in transit and at rest?
- How are model and connector configuration changes tracked for CM control evidence?
- Who has administrative access to the AI system, and how is that access reviewed?
- Can we get a sample evidence package before committing, so our assessor's expectations are met?
- What is your process if a control gap is identified during our internal assessment?
Frequently asked questions
Does DFARS 252.204-7012 specifically mention AI systems?
No, the clause predates widespread AI adoption and does not name AI specifically. It requires adequate security, defined by reference to NIST SP 800-171, for any system that processes covered defense information, and that requirement applies to an AI system exactly as it applies to any other system touching CDI.
Which NIST 800-171 control families matter most for an AI layer on an ERP?
Access Control and Identification and Authentication govern who can query the AI system; Audit and Accountability governs logging of queries and responses; System and Communications Protection governs encryption and network boundaries; Configuration Management governs how the AI components are baselined and changed over time.
Does the 72-hour incident reporting clock apply if the incident only involves the AI layer?
If the incident involves covered defense information processed by the AI system, yes, the same DFARS 7012 reporting timeline applies. This is why the AI system's logging needs to be detailed enough to support fast incident reconstruction, not just routine monitoring.
Can a SOC 2 report from our AI vendor substitute for control-by-control mapping?
A SOC 2 report is useful supporting evidence but rarely maps directly to the 110 controls in NIST SP 800-171 or their assessment objectives. Most Compliance Managers still need a separate mapping document that translates the vendor's controls into the specific language their own control matrix requires.
How do we handle flow-down obligations if our AI vendor is effectively a subcontractor?
If the vendor processes CDI on your behalf, DFARS 7012 flow-down language should appear in your agreement with them, including their obligation to implement adequate security and report incidents to you promptly enough for you to meet your own 72-hour clock.
Is an on-prem AI deployment always easier to map to NIST 800-171 than a cloud one?
It is often simpler for the System and Communications Protection family because there is no external network boundary to document, but a well-architected private cloud deployment with a dedicated tenancy and clear encryption and access controls can satisfy the same controls, it just requires more explicit documentation of the boundary.
What evidence should we keep specifically for the AI system ahead of a DIBCAC or C3PAO assessment?
Keep a control-to-component mapping document, sample audit logs showing query and response tracking, access control configuration snapshots, and configuration change history for the model and connectors, all formatted to reference the specific control numbers your assessor will ask about.
Related guides
CMMC Level 2 AI for ERP Without Blowing Up Your Scope
How to deploy AI inside your CMMC 2.0 Level 2 assessment boundary without expanding CUI scope. Enclave architecture a CISO can defend to a C3PAO.
ITAR + on-prem AIITAR-Compliant AI for ERP Technical Data
How to add generative AI to your ERP without creating a deemed export under ITAR. On-prem architecture patterns an Empowered Official can sign off on.
GovCon accounting + DCAA + on-prem AIAI for Government Contractor ERP Under DCAA Scrutiny
AI for government contractor ERP under DCAA scrutiny: draft indirect rate variance narratives, flag unallowable costs, and build audit trails, run on infrastructure you control.
Costpoint + CMMC-scoped AIOn-prem AI for Costpoint inside a CMMC Level 2 enclave
Deploy AI beside Deltek Costpoint inside a CMMC Level 2 enclave: what to check before adding any AI tool, and how on-prem inference avoids new CUI flows.
Buyer guide: cloud AI vs private AIFedRAMP / GCC High AI vs On-Prem AI for Your ERP: An Honest Comparison
An honest CISO comparison of FedRAMP High or GCC High AI copilots versus on-prem private LLMs for ERP data: what each authorization actually covers, and when each fits.
Agents + approval gatesAI Agents for ERP, Running On-Prem
A practical guide to on-prem AI agents for ERP: what they can safely automate, where human approval belongs, and how to design the guardrails.
Plan it with numbers
DFARS 252.204-7012 Compliance Self-Assessment
A 10-question self-assessment covering the full DFARS 7012 clause: NIST 800-171 implementation, SPRS, incident reporting, cloud requirements, and flowdown.
Free ToolCMMC 2.0 Level 2 Readiness Assessment
Answer 10 questions mapped to NIST SP 800-171 control families and get an instant CMMC Level 2 readiness score with prioritized next steps.
Free ToolAI Audit Trail Readiness Checklist
A practical control checklist for building AI audit trails that satisfy compliance assessors, covering request-level logging, log integrity, identity evidence, and model lineage.
GuideAudit Trails for AI Decisions: A Compliance Guide
Build audit trails for AI decisions that satisfy internal and external auditors: what to log, how long to retain it, and how to prove provenance.
GuideITAR and CMMC Handling of AI Workloads
How ITAR and CMMC apply to AI workloads: technical data boundaries, CUI handling, assessed environments, and where on-prem AI is the only option.
GuideERP Audit Trails and Logging
Design ERP audit trails and logging that satisfy auditors: what to log in SyteLine and Infor LN, retention periods, SIEM forwarding, and tamper-evident records.
Talk it through with an engineer who knows SAP S/4HANA
Bring one real question your team cannot answer from the ERP today. We will map the data path, the model, and where it runs, and tell you honestly if AI is the wrong tool for it.