# Mapping DFARS 7012 and NIST 800-171 Controls to AI on Your ERP > Source: https://netray.co/erp-ai/dfars-7012-nist-800-171-ai-erp > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: AI for 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. ## Kind persona ## Erp Family multi-erp ## Erp Products - SAP S/4HANA - Infor SyteLine - Deltek Costpoint - Oracle EBS ## Industries - Aerospace - Defense - Electronics ## Region United States ## Persona Compliance Manager ## Eyebrow DFARS 7012 + NIST 800-171 ## Intro 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. ## Pain Points ### Vendor security claims do not map to control language **Detail:** 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 **Detail:** 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 **Detail:** 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 **Detail:** 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 **Detail:** 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. ## Use Cases ### Control narrative drafting per family **Description:** 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. **Erp Objects:** 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 **Description:** Produce a current snapshot of which roles can query which ERP data through the AI layer, formatted to match AC family assessment objectives. **Erp Objects:** 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 **Description:** Condense raw AI query and response logs into a review-ready summary aligned to AU-6 audit review requirements. **Erp Objects:** 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 **Description:** 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. **Erp Objects:** 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 **Description:** Draft Plan of Action and Milestones language for any temporary gap identified during AI system rollout, tied to the specific control and remediation step. **Erp Objects:** 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 **Description:** Generate draft SSP language describing how the AI system's configuration satisfies specific controls, for compliance staff to review and finalize. **Erp Objects:** 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 **Description:** Document where model weights, embeddings, and cached data are stored and how they are protected and sanitized, to satisfy MP family evidence needs. **Erp Objects:** Model storage configuration, data retention and deletion procedures **Outcome:** closes a documentation gap that is easy to overlook for AI-specific storage ## Architecture **Overview:** 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. **Layers:** #### Access control layer (AC, IA) **Detail:** 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. #### Audit and accountability layer (AU) **Detail:** 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. #### System and communications protection (SC) **Detail:** 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. #### Configuration management (CM) **Detail:** Model versions, connector configurations, and the retrieval index are version-controlled and change-managed under the same process as other in-scope systems. #### System and information integrity (SI) **Detail:** 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. ## Deployment Options ### Air-gapped on-prem **Fit:** Contractors who want the simplest possible boundary story for SC and CM controls **Detail:** 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 **Fit:** Contractors needing elastic capacity while keeping personnel and hosting location control **Detail:** 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 **Fit:** Contractors with only part of their ERP handling CDI **Detail:** 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 ### 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. **Framework:** DFARS 252.204-7012 ### 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. **Framework:** NIST SP 800-171 (AC family) ### Full logging of AI queries and responses supports both periodic audit review and rapid incident reconstruction within the reporting window. **Framework:** NIST SP 800-171 (AU family) ### Encryption in transit and at rest, plus disabled outbound internet access for CDI-touching components, supports boundary and communications protection control narratives. **Framework:** NIST SP 800-171 (SC family) ### Model, connector, and index configurations are version-controlled, giving the Compliance Manager a clear baseline to compare against during an assessment. **Framework:** NIST SP 800-171 (CM family) ## Integration Notes 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. ## Product Fit ### Custom build **Why:** 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 **Why:** 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. ## Engagement ### Discovery **Duration:** 2-3 weeks **Deliverables:** - 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 ### Pilot **Duration:** 6-8 weeks **Deliverables:** - 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 ### Production **Duration:** 8-12 weeks **Deliverables:** - 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 ### Scale **Duration:** ongoing **Deliverables:** - 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 ## Buyer Questions - 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? ## Faq ### Does DFARS 252.204-7012 specifically mention AI systems? **Answer:** 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? **Answer:** 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? **Answer:** 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? **Answer:** 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? **Answer:** 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? **Answer:** 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? **Answer:** 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. ## Search terms DFARS 252.204-7012 AI, NIST 800-171 AI ERP, adequate security AI system, CDI AI ERP, DFARS compliant AI, NIST 800-171 control mapping AI, ERP AI compliance manager, 72 hour incident reporting AI, DFARS AI copilot, defense contractor NIST AI, AI audit logging DFARS, AI system control evidence --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json