MA.L2-3.7.2 System maintenance control requirements

What MA.L2-3.7.2 requires and why a POA&M will not cover it

If your assessment found MA.L2-3.7.2 not met, you have to close it before your organization can reach Conditional or Final Level 2 status. The requirement asks you to control the tools, techniques, mechanisms and personnel used to conduct system maintenance. In practice, that means you can name every tool a technician or vendor uses on a CUI system, explain how each one was approved, show who may use it and when, and show that its use was recorded and reviewed. Maintenance tools are often privileged software or hardware that can read, change or copy data, so an uncontrolled tool can carry malware into the environment or give someone access beyond their role. The requirement is worth 5 points under the CMMC Scoring Methodology, and under 32 CFR 170.21 any requirement worth more than 1 point cannot go on a POA&M. Your 110-point score is only useful if this one is MET.

The gap usually appears in three places. Vendor technicians connect remotely with their own laptops and vendor-issued remote tools, and nobody on your side has a list of those tools or the accounts they used. Diagnostic utilities, firmware updaters and scripts get copied onto servers during an outage and stay there. Maintenance accounts with administrator rights are shared, or they were created for a project and never removed. Each of these is a maintenance control problem even when the work itself was done correctly. Start by inventorying every maintenance tool, technique and account across the CUI boundary, then match each entry to an approval record, an owner and a review date.

Before you buy anything, confirm with your assessor and with the current CMMC guidance how they expect each of the four areas to be evidenced, since the NIST SP 800-171A assessment objectives set the test and the evidence must be in final form, not drafts. Ask your vendors for their maintenance access procedures in writing, and check whether your contracts require them to use your approved tools. Open-source service desk platforms such as GLPI can hold approval requests, change tickets and maintenance records in one place, which gives an assessor a single trail to test. Whether a given platform fits your evidence needs is something to confirm during scoping, not assume.

Which maintenance tools, people and systems fall under MA.L2-3.7.2

MA.L2-3.7.2 covers every path by which someone or something performs maintenance on a system that handles CUI, not only the technician's laptop. The cards below separate the tools, techniques, mechanisms, personnel and systems that create the control boundary, and each card names the scoping decision that changes the work.

Maintenance tools and diagnostic software

Tools include diagnostic suites, disk imaging utilities, network sniffers, firmware updaters and vendor troubleshooting software. The key scoping decision is whether a tool that also runs on general IT counts. If the same utility touches a CUI system, it is in scope for 3.7.2 even when it was installed for another purpose. Build an approved tool list with versions, owners and the systems each tool may reach, and confirm the boundary against the system security plan. Record how each tool is approved, monitored and inspected.

Maintenance techniques and procedures

Techniques include scripted changes, batch jobs, remote command sessions and step-by-step vendor procedures. A script that a technician runs from a shared folder is a technique that needs control, even if no tool is purchased. Decide whether scripts must be reviewed and signed before use, and whether vendor procedures are accepted only when they are written into the maintenance plan. Confirm with the system security plan which techniques are permitted for each system class.

Mechanisms that carry maintenance

Mechanisms are the channels through which maintenance travels, such as jump hosts, bastion servers, remote support platforms and privileged access brokers. Whether a remote support product counts depends on whether it can reach a CUI system during a session. Map every channel to the systems it can administer, and check that session logs and approvals are kept. Confirm the list of permitted mechanisms with the owner of the system security plan so that unlisted paths are treated as out of bounds.

Maintenance personnel and vendor technicians

Personnel include internal administrators, contractors and vendor technicians who hold elevated privileges during maintenance. The scoping question is whether a person who only works on the platform, such as a managed service provider engineer, is in the maintenance population. Treat them as in scope when they can change a CUI system. List who is authorized, what access each person holds, and how that access is granted and removed. Supervision rules for visitors without the required access authorization belong to a sibling requirement, but the control list still needs them.

Systems that handle CUI

The systems in scope are those that store, process or transmit CUI, plus the supporting infrastructure that can affect them, such as directory services, backup servers and management consoles. Shared infrastructure is the most common source of disagreement. A domain controller that serves both CUI and non-CUI networks is usually in scope. Confirm each boundary against the system security plan and the network diagram, and record the systems that are excluded and why.

How an assessor tests MA.L2-3.7.2 under NIST SP 800-171A

This table compares each NIST SP 800-171A assessment objective for 3.7.2 with what the assessor examines, the evidence requested and the findings that most often cause a NOT MET result. Read it as a checklist: every applicable row must be satisfied with final evidence before the requirement can be scored as MET, because a 5-point requirement cannot be carried on a POA&M.

Assessment objective	What the assessor examines	Evidence requested	Common findings
Tools used for system maintenance	Whether the organization approves, controls, monitors and inspects each maintenance tool, including diagnostic and vendor utilities	Approved maintenance tool list, tool inspection records, tool documentation and vendor tool procedures	Tools installed on production systems with no approval record or inspection history
Techniques used for system maintenance	Whether approved methods for remote diagnostics, software updates and hands-on work are defined and followed	Written maintenance procedures, change or work tickets showing the technique used, and records of procedure review	Procedures exist but do not describe actual techniques, or staff use undocumented shortcuts
Mechanisms used for system maintenance	Whether the means of performing maintenance, such as management consoles, jump hosts and maintenance accounts, are identified and controlled	Inventory of maintenance mechanisms, configuration of jump hosts or consoles, and maintenance session logs	Mechanisms not included in the system security plan or with no monitoring
Personnel used for system maintenance	Whether people performing maintenance are authorized, supervised when they lack access authorization, and their elevated access is controlled	Authorized maintenance personnel list, access grants, supervision records and maintenance records naming each person	Vendor or contractor accounts left active after work ends, or unsupervised privileged access
Process: approving and controlling tools	Whether tool approval is a defined process with owners, criteria and records, not an informal decision	Approval workflow records, tool approval forms and evidence the process was followed for recent tools	Approval happens verbally or is not recorded, so no evidence exists for the assessor to test
Process: monitoring and inspecting tools	Whether tools and media are checked for malware and misuse on a defined schedule or before each use	Inspection logs, scan results for maintenance media and records of who reviewed them	Inspections described in policy but no dated records, or results not acted on
Process: maintenance records and review	Whether maintenance activity is recorded and periodically reviewed for unauthorized tools, techniques or personnel	Maintenance records linked to tickets, review minutes and corrective actions taken	Draft records, incomplete entries or reviews that never occurred
Final evidence and assessment status	Whether every applicable objective above is satisfied with evidence in final form, not drafts, before the requirement is scored	Final, dated and approved versions of procedures, lists and records, retained for the assessment period	Draft policies presented as current, so the requirement is scored NOT MET and cannot go on a POA&M

How to implement maintenance control in six steps

This sequence turns MA.L2-3.7.2 from a policy statement into a working control: every maintenance tool, technique, mechanism and person is known, approved, logged and reviewed before an assessor asks to see it.

Inventory maintenance tools and personnel
Build a list of every tool, technique and mechanism used to maintain systems in scope, including remote management consoles, diagnostic software, scripts, vendor laptops and portable media. Add every person who performs maintenance, whether employee, contractor or vendor technician, and record their access level. Your internal IT or security team owns this step. It is done when each item has an owner, a purpose and a documented access level, and when you can point to the list for each in-scope system.
Write the approval and control procedure
Document how a maintenance tool or technique is proposed, reviewed, approved, used, monitored and retired, and who holds each role. Assessors test for procedures covering approving, controlling, monitoring and inspecting maintenance tools, so the document must name those activities explicitly. Management approves the procedure, and it is finished when staff who perform maintenance can follow it without asking how it works.
Set up the maintenance request and approval workflow
Route every planned maintenance action through a ticketing system so each change has a requester, an approver, a scope and a closing record. Open-source service management tools such as GLPI, whose Assistance module supports tickets, problems and changes following ITIL practices, can hold this record. Confirm with the vendor that your chosen tool fits your environment and access controls. The step is complete when a sample maintenance action can be traced from request to approval to closure.
Restrict elevated accounts and vendor access
Limit maintenance accounts to the people and tools on the approved inventory, and remove standing administrative rights that are not needed for the approved work. Vendor technicians should receive temporary, tightly scoped accounts tied to a specific ticket and removed when the ticket closes. Your identity team implements these settings, and the output is an access list that matches the inventory. Coordinate this with the separate CMMC requirements for maintenance personnel and nonlocal maintenance.
Monitor and inspect maintenance tools
Check approved tools and media for malicious code before and after use, and record the results against each tool. Keep logs of maintenance sessions so that activity can be compared with approved tickets. Assessors look for inspection records, so each tool should have a dated entry showing who inspected it and what was found. Responsibility usually sits with the security team, and the step is done when every approved tool has at least one inspection record.
Run a first internal review
Test the whole chain against a sample of recent maintenance events. Confirm that each event has an approved ticket, an authorized person, an approved tool, a logged session and an inspection record, and log any gaps as findings with owners and dates. Because MA.L2-3.7.2 must be fully met to reach Conditional or Final Level 2 status, this review should be treated as a readiness check. Many organizations bring in an outside assessor or implementation partner here to test the evidence independently, but the organization owns the outcome and only an independent certification body issues any certification.

Which evidence passes an MA.L2-3.7.2 assessment

Assessors test MA.L2-3.7.2 by checking whether the organization controls its maintenance tools, techniques, mechanisms and personnel, and whether records show that control in operation. The cards below cover the artifacts that usually carry that proof. Each one must be current, approved and in final form at assessment time, because a draft does not satisfy the objective.

Approved maintenance tool inventory

This is the register of every tool, diagnostic utility and maintenance mechanism allowed on systems that handle CUI, with its owner, version, host scope and approver. Assessors compare it against tools seen on the systems, so unlisted software found during testing is a finding. Keep it current by adding entries before first use and retiring them when a tool leaves service. Confirm that the inventory covers vendor-supplied tools and remote support utilities, not only internal scripts. A draft inventory does not count.

Maintenance procedure with version history

The written procedure sets out which techniques are approved, how a maintenance task is requested, approved, performed and checked, and who may authorize exceptions. Assessors look for an approval signature, an effective date and a revision history that shows when the procedure last changed and why. Review it on a schedule your organization defines and after any significant change to the environment. Check that the procedure matches what staff actually do, since a mismatch is easy for an assessor to spot.

Maintenance tickets with approvals and closure

Each maintenance action should leave a ticket that records the requester, the tool and technique used, the approver, the work performed and the closure check. Together these tickets show that controls operated in practice, not only on paper. Ticketing platforms such as GLPI, whose Assistance module follows ITIL practices, or Zammad can hold this trail if approval and closure steps are enforced. Confirm that tickets cannot be closed without an approval entry and that emergency changes are recorded after the fact with a reviewer.

Tool inspection records

Inspection records show that maintenance tools and media were checked before use for unauthorized modification, malicious code or unapproved functions. Assessors expect dated entries that name the inspector, the tool version checked and the result. Keep these records with each tool in the inventory so the link between inspection and use is traceable. Ask whether inspections repeat after tool updates and whether a failed inspection blocks use, since both points are common areas of questioning.

Personnel access and supervision records

These records show who performed maintenance, what access they held, and who supervised any personnel without the required authorization, such as vendor technicians. Assessors check that elevated maintenance accounts are individually assigned, time-limited where possible and disabled after the work. Keep a log of supervised sessions with start and end times, the supervisor's name and the scope of work. Confirm that the access list matches the account records in your directory, because a mismatch undermines every other maintenance record.

Periodic review records

Periodic reviews show that the organization checks whether the tool inventory, procedure and access records still match reality. Each review should record the date, the reviewer, the items examined, the gaps found and the corrective actions with owners. Schedule reviews on a cadence your organization sets and document any skipped cycles with a reason. Assessors often ask for the most recent review and the action items from the one before it, so confirm that open actions are tracked to closure.

What meeting MA.L2-3.7.2 costs in money and effort

This table compares the main cost and effort components of meeting MA.L2-3.7.2, showing who is paid, whether each item is one-time or recurring, what moves it up or down, and how open-source tooling changes it. No prices or durations are supplied for this requirement, so use the quote questions in each row to compare offers on a like-for-like basis.

Cost component	One-time or recurring	What drives cost up or down	How to reduce it
Procedure writing for controlled maintenance	One-time, then reviewed on a recurring basis	Number of maintenance types, vendors and system classes in scope; whether procedures already exist in a system security plan	Reuse existing change and maintenance procedures and map them to the four assessment objects in NIST SP 800-171A
Tool and media inventory and inspection effort	Initial build, then recurring with each new tool	Count of diagnostic tools, laptops, vendor utilities and removable media that touch CUI systems; whether approval records already exist	Keep one register of approved maintenance tools with owner, version and inspection record, and restrict intake to that register
Ticketing or workflow tooling	Recurring if licensed; one-time setup for self-hosted tools	Per-seat licensing on commercial service desks; number of approvers and integrations with change and asset records	Self-hosted open-source options such as GLPI or Zammad can remove license spend for the ticket trail, but ask who maintains, patches and backs them up
Engineering time for access restriction	One-time for jump hosts, accounts and logging; recurring for account reviews	Number of maintenance accounts, whether privileged access is separated, and whether the environment is cloud, on-premises or hybrid	Use time-limited, individually named maintenance accounts and a single controlled access path so restrictions are configured once
Supervision and personnel controls	Recurring per maintenance event	Frequency of vendor visits and remote sessions; whether escorts or session monitoring are required	Schedule maintenance windows and batch vendor work so supervision is planned rather than ad hoc
Evidence upkeep	Recurring	Frequency of maintenance events, number of tools, and how quickly records are closed out after work finishes	Capture records at the point of work through the ticket system so evidence is not rebuilt before an assessment
External review by a consultant	Usually paid by the engagement, sometimes recurring	Scope size, number of systems, and whether the consultant also prepares evidence or only reviews it	Ask for a written scope and deliverables; confirm the reviewer does not later perform the assessment
Assessor sampling and assessment time	Paid to the assessor, typically once per assessment cycle	Number of maintenance records and tools the assessor samples; whether final-form evidence is ready	Prepare final-form records and a sample-ready index before the assessment begins; ask the assessor how sampling will be chosen

Who does what for maintenance control: your team, a partner and the assessor

Your organization owns MA.L2-3.7.2. Assessors test whether the people who run your environment actually control maintenance, so the decisions about which tools may touch CUI systems, which techniques are allowed, which mechanisms enforce them and who may perform maintenance must be made and signed by your staff. Your system owner, security lead and IT operations manager usually share this, with a named approver for each maintenance activity.

Tool and technique approval: Decide which maintenance tools, scripts and remote utilities are permitted, and record who approved each one and why.
Personnel authorization: Maintain the list of people allowed to perform maintenance, including their access level and the date their authorization was last reviewed.
Elevated access decisions: Own the choice of which maintenance accounts carry administrative rights, how they are issued and when they are removed.
Monitoring and inspection: Assign someone to review maintenance tool use and to inspect tools and their records on a schedule you define.
Sign-off: Keep the approved procedures current and make sure the final versions, not drafts, are the ones in use when the assessor arrives.

Before any assessment, confirm that each approval has a dated owner and that the records match what the environment actually shows.

Where organizations fail maintenance control and how to close each gap

Most MA.L2-3.7.2 failures are not missing tools. They are maintenance activity that happens outside the controls the organization already wrote down. Each card below names one gap, the action that closes it, and the evidence an assessor would expect to see.

Vendor technicians using personal remote tools

A vendor engineer connects through a consumer remote access application installed on a personal laptop, so the organization has no record of which tool, which device or which account was used. To close the gap, name the approved remote tools in the maintenance procedure, require vendor staff to use organization-issued accounts, and block unapproved tools at the boundary. Evidence to collect: the approved tool list, firewall or endpoint logs showing only permitted tools, and a sample of vendor session records tied to tickets. Confirm with your vendor contracts that these terms are enforceable before work begins.

No approved maintenance tool list

Maintenance tools are chosen case by case, so nobody can say which diagnostic utilities, scripts or firmware updaters are authorized for systems that handle CUI. Create a controlled list that records each tool's owner, version, purpose and the systems it may touch, then approve additions through a documented review. Evidence to collect: the signed tool inventory, approval records for each tool, and a comparison showing that tools found on systems appear on the list. Assessors look for the approval process itself, not only the list.

Maintenance performed without tickets

Patches, configuration changes and repairs happen through informal requests, so there is no record of who approved the work, what tools were used or who had elevated access. Route every maintenance activity through a ticketing system that captures the requester, approver, tools, personnel and closure notes. Open-source service desks such as GLPI and Zammad can hold these records, provided the ticket fields are configured to capture them. Evidence to collect: tickets for a sample of maintenance events with approval and closure entries, and reports showing no unticketed changes.

Elevated accounts left open after work

Administrator or vendor accounts created for a maintenance window remain active for months, which turns a single job into standing access. Set each maintenance account to expire at the end of the approved window, remove it on ticket closure, and review active privileged accounts on a fixed schedule. Evidence to collect: account creation and disablement logs matched to ticket numbers, and periodic access reviews showing no orphaned maintenance accounts. Confirm that your directory can enforce time-bound accounts before relying on this control.

Tools reused across CUI and non-CUI systems

A laptop or USB diagnostic kit used on a general office network is later plugged into a system that handles CUI, carrying malware or misconfigured settings with it. Dedicate maintenance tools to CUI systems where practical, and require inspection and documented clearance before any tool crosses between environments. Evidence to collect: inspection records for shared tools, a segregation rule in the maintenance procedure, and logs showing that inspection happened before use. Note that inspection of media and diagnostic programs is also covered by MA.L2-3.7.4, so the two records should cross-reference each other.

Procedures that exist only as drafts

The maintenance control procedure is written, but it is marked draft, unsigned or missing an owner, so staff follow habit instead. An assessor treats a requirement as met only when the evidence is in final form, so a draft procedure does not satisfy the requirement. Approve the procedure, assign an accountable owner, set a review date and publish it to the people who perform maintenance. Evidence to collect: the approved and dated version, the distribution record, and signed acknowledgments from maintenance staff and vendors.

How a ticketing system can hold maintenance evidence

A self-hosted helpdesk or IT service management tool can hold the approval, scheduling, assignment and closure trail for maintenance work on CUI systems, which is the kind of record an assessor will ask to see when testing MA.L2-3.7.2. Two open-source options to evaluate are GLPI and Zammad. GLPI's Assistance module, released under GPL-3.0-or-later, lets teams create, follow and process tickets, problems and changes following ITIL practices, with plannings, statistics, recurrent tickets and a Kanban view. Zammad, licensed under AGPL-3.0-only, is a web-based helpdesk that gathers requests from email, chat, telephone and social media into one ticket system. Zammad is typically stronger for request intake, while GLPI's change and planning features map more directly to maintenance approvals, so the choice depends on which workflow you need to prove.

A ticketing record is evidence of a process, not proof that the control is operating. The tool does not decide which tools, techniques, mechanisms or personnel are approved, and it does not stop a technician from installing an unapproved utility. Confirm with your assessor and your own procedures that the tool is configured to require a change or maintenance ticket before any maintenance session starts, that approvals are recorded by someone other than the requester, that the maintenance tool or software used is named on the ticket, and that closure notes capture what was done and who did it. Ask your vendor whether these fields can be made mandatory and whether audit history on tickets is retained and cannot be edited silently. Confirm these settings against your own requirements rather than assuming the defaults meet them.

Keep the tickets, approval records and the system security plan aligned. If the ticket says a diagnostic tool was approved, the approved tool list and its inspection records should show the same tool and version. Mismatches between tickets and the actual configuration are the kind of gap an assessor finds quickly. Plan for access to the ticketing system itself, since the people who can approve their own maintenance work undermine the trail, and restrict administrator rights on the platform to a small, named group. Decide who reviews closed maintenance tickets on a set schedule and how that review is documented, so the record shows the control operating over time rather than only at assessment.

Questions buyers ask about MA.L2-3.7.2 cost, effort and outside help

Can MA.L2-3.7.2 go on a POA&M to get a CMMC Level 2 status?

No. MA.L2-3.7.2 is a 5-point requirement under the CMMC Scoring Methodology in 32 CFR 170.24, and 32 CFR 170.21(a)(2) does not allow requirements worth more than 1 point on a plan of action and milestones. It has to be MET before the organization can reach Conditional or Final Level 2 status. Plan the control as finished work, not as a future fix. Because the POA&M route is closed for this requirement, the schedule risk sits entirely in getting the controls and evidence in place before the assessment starts.

How much effort does MA.L2-3.7.2 take to implement?

The effort depends on how many maintenance tools, remote support products and vendor accounts the organization runs against systems that handle CUI. The control covers four elements: the tools, the techniques, the mechanisms and the personnel used for maintenance. Each one needs an approved list, a documented approval step, monitoring and inspection records. A small estate with a few tools and one support vendor is far less work than a plant with OT test equipment, multiple vendors and laptops that move between sites. Ask any consultant or internal lead to size the work by counting tools, personnel groups and maintenance paths before agreeing a schedule.

Can our own team implement MA.L2-3.7.2 without outside help?

Often yes, if someone on the team owns the maintenance process and can produce records that assessors accept. The work is mostly governance and evidence: an approved tool list, approval and removal procedures, personnel controls for vendor technicians, and inspection logs. The technical gap is usually smaller than the documentation gap. Teams that already run a ticketing system and an asset inventory tend to start from a better position. Outside help is most useful when the team lacks time, when the scope spans enclaves or OT, or when the team wants an independent check before the assessment.

What does our team need to provide for a partner to prepare this control?

A partner needs access to the people and records that describe real maintenance practice. Expect to provide:

A current list of maintenance tools, remote support products and the systems they touch
Names and roles of internal staff who approve maintenance and vendor technicians who perform it
Existing maintenance tickets, change records and any inspection or sanitization logs
The system security plan and the network boundary diagram for CUI scope
Contracts or support terms with vendors that govern their access

The organization keeps ownership of its controls. The partner prepares procedures, records and evidence for review, and the team signs off on what reflects actual practice.

How long does it take to get MA.L2-3.7.2 ready?

No researched duration applies here, so treat any timeline as an estimate to test in your own environment. Time is driven by how many maintenance tools and personnel groups exist, whether approval workflows already exist in a ticketing or asset system, how many enclaves or sites are in scope, and how quickly staff can retire unapproved tools. Ask for a written schedule that lists each deliverable and the evidence it produces, and confirm it against your assessment date. The current assessment timing is also in flux, so check the DoW CIO About CMMC page and the eCFR text before committing dates.

What does an implementation partner change for the MA.L2-3.7.2 assessment?

A partner changes the preparation, not the verdict. DeployOpen plans, implements and documents the maintenance controls, prepares the evidence and tests that records match the configured systems. Only an independent assessor can rate the requirement MET. For Level 2 certification, that assessor is a C3PAO authorized or accredited by The Cyber AB. Keeping those roles separate matters because an assessor cannot evaluate controls it designed. Ask any partner to show in writing which deliverables they produce and which steps remain the assessor's responsibility.

How does MA.L2-3.7.2 differ from MA.L2-3.7.5 nonlocal maintenance?

MA.L2-3.7.2 controls who and what performs maintenance and which tools and techniques they use, wherever the work happens. MA.L2-3.7.5 focuses on remote sessions that cross external network connections, requiring multifactor authentication to start them and termination when the work ends. A remote vendor session can fall under both requirements, but 3.7.2 also covers on-site tools, laptops and personnel approvals that never touch the network. Both are 5-point requirements, so neither can be placed on a POA&M. Map each maintenance path to both controls so the evidence for one does not leave a gap in the other.

How DeployOpen prepares maintenance control for an assessment

DeployOpen plans and builds the tool, technique, mechanism and personnel controls that MA.L2-3.7.2 asks for inside your own infrastructure, then documents them so the evidence is ready for an independent assessor. The organization keeps ownership of its controls and decides who may perform maintenance, while DeployOpen prepares the systems and records that show the controls operate.

How we scope

Engagements are fixed-scope, with the maintenance systems, tools and personnel groups agreed in writing before work starts.
The written scope lists which maintenance tools, remote paths and vendor accounts fall under the 3.7.2 control boundary.
Scope also names the four assessment objects in NIST SP 800-171A so each one has a clear owner and evidence source.

How we build

We configure an approval workflow for maintenance tools and techniques, recorded in a ticketing system such as GLPI or Zammad.
We set up tool inventories, inspection records and maintenance logs so each approved tool has a traceable history.
We implement role-based controls for maintenance personnel so elevated privileges are granted, monitored and removed on schedule.

How we hand over

We deliver the maintenance procedures, tool register, approval records and personnel access records in final form.
We test the approval, monitoring and inspection processes and document the results so the organization can rerun them.
We provide a handover walkthrough that shows the organization's staff how to produce each piece of evidence on request.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after the initial handover.
Retainer work can cover periodic review of the maintenance tool register and personnel access as systems change.
Confirm with your assessor or C3PAO which evidence formats they accept before the final package is assembled.