MA-7 Field maintenance: requirements and evidence

What MA-7 field maintenance asks for and why it is not in any baseline

MA-7 requires the organization to restrict or prohibit field maintenance on the systems and components it defines, and to limit any permitted field work to trusted maintenance facilities that it also defines. Field maintenance means work carried out at the site where a system or component is deployed, such as a branch, a substation cabinet, a data center cage or a remote kiosk. The control exists because repairs at the deployment site expose the equipment to physical tampering, uncontrolled diagnostic tools and technicians whose background and access have not been checked. An assessor who sees MA-7 in a contract or plan is asking the organization to decide where field work is allowed, who may do it and what happens to the equipment when it leaves the site.

SP 800-53B does not allocate MA-7 to the low, moderate or high baselines or to the privacy baseline. An organization that does not add it during tailoring has no baseline obligation to meet, but a contract, a sector rule or a risk assessment may still require it. When that happens, the organization supplements its baseline and records the decision in the security plan. Confirm with the requesting party exactly which requirement applies, because a contract clause that says field maintenance must be controlled is a different obligation from one that names MA-7 directly. Several related controls, including MA-2, MA-4 and MA-5, cover adjacent maintenance activity and will usually be assessed alongside MA-7.

The hard part is usually scoping, not writing the policy. The organization must name which components count as deployed and therefore in scope, which facilities count as trusted, and what evidence proves that a facility meets the trust criteria. For a fleet of remote devices or a multi-site network, this means maintaining an inventory that shows where each component sits and whether a repair at that location is permitted. Before the assessment starts, agree the component list and the trusted facility list with the assessor, and check whether the chosen facilities' work orders, chain-of-custody records and tool approvals can be produced on request.

Which systems, sites and third parties MA-7 applies to

MA-7 only bites on the systems and sites the organization itself defines, so the first work is drawing those boundaries in writing. The cards below cover the decisions that change what evidence an assessor will ask for, from the components you allow in the field to the vendors whose technicians are covered by the same restriction.

Field-maintainable systems and components

MA-7 requires the organization to define which systems or components may receive field maintenance. Each item on that list is a commitment the assessor will test, so an empty or vague list is itself a finding. For each system, record whether technicians may repair it at the deployment site, swap modules, or only return it to a facility. Check that the list matches the system security plan and the asset inventory, since a component missing from one of them is easy to overlook.

Operational sites where maintenance is restricted

The control applies to maintenance performed where the system or component is deployed. The organization must decide which of its locations count as operational sites, such as data halls, branch offices, field cabinets or customer premises. A rack in a leased colocation cage, for example, may be an operational site even when the organization does not staff it. Document each site, and confirm that the physical access records and maintenance logs for those sites can be produced on request.

Trusted maintenance facilities

Where field maintenance is allowed, MA-7 limits it to trusted maintenance facilities the organization defines. A facility is a place a component can be shipped to for repair, not a person. Define each facility by name and address, state who approved it, and record the security conditions it must meet, such as controlled access and media handling. Assessors will ask whether the list is current and whether any component was sent somewhere not on it.

Vendor and contractor technicians

Manufacturers and field service contractors often perform the work that MA-7 describes, so their technicians fall inside the boundary whether or not they are employees. Decide whether each vendor may work at operational sites, under what restrictions, and whether those restrictions appear in the service contract. Ask the vendor for its own repair procedures and technician access controls, and confirm that they match the restrictions the organization set. Support agreements that do not mention field work leave a gap the assessor will find.

Diagnostic and repair records

Each field maintenance event on a defined system should leave a record, so the organization can show who worked on what, where, and under which restriction. Decide which fields the record must hold, such as the site, component serial, technician, facility or approval reference, and the date. Choose where those records live so that the assessor can examine them without asking the vendor for copies. Records that exist only in a contractor's system are hard to produce during an assessment.

Tailoring MA-7 into the baseline

SP 800-53B does not allocate MA-7 to the low, moderate or high baselines, so an organization adds it only when risk or an applicable requirement calls for it. Record that decision in the tailoring rationale and the system security plan, including the reasons it was included or excluded. A system that has no field maintenance at all may still document that exclusion, since that record is the evidence an assessor will look for first. Revisit the decision when the system's deployment model or vendor arrangements change.

How an assessor tests MA-7 field maintenance

This table maps the single SP 800-53A determination statement for MA-07 to the examine, interview and test methods, the assessment objects an assessor may review, and the findings that commonly appear. Read it as a checklist of what to have ready before an assessor arrives, since each row names the evidence a tester will ask for.

Assessment method	Potential assessment objects	Common findings
Determination statement (MA-07)	The organization restricts or prohibits field maintenance on defined systems or components and limits it to defined trusted maintenance facilities.	Defined systems or components are missing, so the restriction has no scope to test.
Examine	Maintenance policy and procedures addressing field maintenance, system configuration settings, associated documentation and diagnostic records.	Policy states a prohibition, but procedures contain no step that enforces it at the site.
Interview	Organizational personnel with system maintenance responsibilities and system and network administrators.	Staff describe field work as routine, or cannot name the trusted maintenance facilities.
Test	Organizational processes for managing field maintenance and the mechanisms that implement, support or manage it.	No mechanism or workflow shows that field work is approved, routed to a trusted facility or blocked.
Examine: trusted facility records	Documented list of trusted maintenance facilities and the approvals linking each facility to defined components.	No record of trusted facilities exists, or the list is out of date with current vendors.
Examine: diagnostic and maintenance records	Tickets, work orders and diagnostic logs showing where and by whom each maintenance action occurred.	Records do not state the location of the work, so the assessor cannot confirm it stayed off-site.
Test: enforcement mechanisms	Access restrictions, approval gates or change workflows that stop maintenance outside trusted facilities.	Policy restricts nothing in practice because no technical or procedural gate exists.

How to implement MA-7 field maintenance in six steps

This sequence turns MA-7 into a documented, enforced rule: which components are covered, where maintenance may happen, and proof that the rule works in practice.

Define the components covered by MA-7
Start with the system component inventory and mark every component that is deployed at a site where field work could happen, such as servers in branch offices, edge appliances, network devices in colocation space, or hardware at remote facilities. The engineering lead and the system owner do this together, because the system owner knows which items are operationally critical. The output is a scoped component list grouped into classes, with each class linked to its system boundary in the security plan. The step is done when an assessor could pick any deployed component and find its class in the list.
Define trusted maintenance facilities
MA-7 limits field maintenance to trusted maintenance facilities that the organization defines, so the compliance lead and the maintenance owner must name each approved facility and state why it is trusted. Typical evidence includes the facility's location, its access controls, the personnel vetting it applies, and the contractual terms that bind it. The output is a facility register with one entry per approved facility, its owner, its approval date and its review cycle. Ask any external facility to confirm these details in writing before it appears on the register.
Decide restrict or prohibit for each component class
For each class from step one, the risk owner chooses whether field maintenance is restricted, meaning allowed only at a trusted facility under defined conditions, or prohibited outright. Components that hold high-value data or cannot be sanitized before removal are usually better candidates for prohibition, while components that must be serviced on site are candidates for restriction. Record the reason for each decision, since an assessor will ask why a class was not prohibited. The output is a decision table that maps every component class to restrict or prohibit, with a named approver and a review date.
Document the rule in policy and the security plan
Write the field maintenance rule into the maintenance policy and procedures, then reflect it in the system security and privacy plan so the rule is part of the authorized system description. The text should state the covered classes, the permitted and prohibited activities, the approved facilities and the approval path for exceptions. The control owner signs the procedure, and the authorizing official or designated approver reviews the plan. The output is a signed procedure and a plan entry that point to the same component classes and facilities as the register.
Configure the enforcement mechanisms
Translate the rule into operational mechanisms. Use the ticketing system to require an approved change or maintenance request before any field work, with fields for component identifier, facility, technician and approval. Configure access rules so that credentials for field maintenance are issued only to personnel at approved facilities, and set up location and tool records so each field event is traceable. Open-source service management platforms such as GLPI can hold the request workflow, planning and records, and a helpdesk such as Zammad can handle external facility correspondence, though teams should confirm the exact approval and audit features they need against the product documentation. The output is a working workflow with a test request, a configured access rule and a record template.
Test with a sample field event
Run a tabletop or live test in which a sample field event is requested, approved, performed at a trusted facility and closed. Include one deliberate out-of-policy attempt, such as a request from an unapproved facility or for a prohibited class, and confirm the workflow blocks or escalates it. Keep the request, approval, access record, tool record and closure note together so the test can be sampled the way an assessor would sample a real event. The output is a test record that shows each step operated as documented, plus a list of any gaps and their owners. Ask the independent assessor which evidence format they expect before the test is run.

Evidence for MA-7 field maintenance that passes testing

MA-7 is tested by examining documented rules and then checking that the rules were followed on real work. The artifacts below connect in a chain: the policy sets the rule, the component and facility lists define its scope, configuration shows enforcement, and records prove what happened in the field. Keep each one current between assessments so the sample an assessor draws is consistent with the rest.

Maintenance policy and field procedures

The written policy and procedures must state that field maintenance is restricted or prohibited on the systems and components the organization defines, and that any permitted field work happens only at trusted maintenance facilities. Assessors read this first to see whether the rule exists at all. Check that the procedure names who approves an exception, which system owner signs off, and how the rule links to the MA-1 review cycle. Reconfirm the document each time the defined scope changes.

Defined field maintenance component list

This is the organization's own list of systems or components where field maintenance is restricted or prohibited. It is the scope the assessor uses to pick samples, so an incomplete list makes every later test look weak. Record each entry with its asset identifier, location, owner and the reason it is in scope, such as a high-impact system or a component under an external contract. Compare the list against the current asset inventory at least at each assessment cycle.

Trusted maintenance facility register

MA-7 limits permitted field work to trusted maintenance facilities that the organization defines, so the register names each facility, the approved scope of its work and the basis for trust, such as contract terms, personnel screening or security certification where the organization requires it. Assessors check that the register matches the facilities actually used. Confirm the entries with the vendor or facility before each review, and remove any facility whose agreement has ended.

Configuration settings that enforce the rule

Assessors look for technical or procedural settings that make the restriction real, such as disabled maintenance accounts, locked service ports, physical or logical lockouts on defined components, or change tickets that cannot close without an approved facility. Export these settings and the matching configuration baseline so they can be compared over time. Verify the settings after every patch or upgrade, since updates can re-enable services that were turned off.

Exception approvals and waiver records

When a field repair cannot wait, the organization needs a documented exception that states the component, the business reason, the approving authority, the time window and the compensating controls. Assessors sample these to see whether exceptions are rare, approved before work begins, and closed on time. Keep each approval linked to its ticket so the chain from request to completion is visible. Review open exceptions regularly so none remain open past their window.

Diagnostic and field work records

Every field maintenance event on a defined component should leave a record of who performed it, which facility sent them, the date and time, the tools and diagnostic sessions used, the changes made and how the component was verified afterward. Assessors test these records against the approval and facility lists to confirm that the work matched what was permitted. Ticketing platforms such as GLPI, which follows ITIL practices for tickets and changes, can hold these records with links to approvals. Confirm the platform retains entries for the period your assessment requires.

What your team, a partner and the auditor each own

Your organization owns MA-7 in full. Only you can decide which systems or components are covered by the field maintenance restriction, which maintenance facilities count as trusted, and whether any field work is permitted at all. Those definitions belong in the system security and privacy plan and the maintenance policy, and they must be approved by someone accountable for the system. Your staff also own the exceptions: when a vendor engineer needs to work on a deployed component at the site, a named owner must approve it, record the reason and confirm the restriction was reapplied afterward.

Scope decisions: Define which deployed systems or components the restriction covers, and document why any excluded item is excluded.
Trusted facilities: Name the maintenance facilities allowed to receive equipment or perform work, and review that list on a schedule you set.
Exception approval: Assign an approver for each field maintenance request and keep the approval with the work record.
Policy alignment: Link MA-7 to the related MA-2, MA-4 and MA-5 procedures so approvals and session records are consistent.

Before any assessment, confirm that someone on your team can explain each scope decision and point to the document that records it.

Using GLPI and Zammad to record field maintenance tickets

Field maintenance records are easiest to defend when each visit to a deployed system leaves a ticket with an approval, a location and a closure record. Two self-hosted helpdesks named in the supplied facts can hold that trail, and the license terms for each apply to how you run them.

GLPI as the change and approval record

GLPI's Assistance module handles tickets, problems and changes following ITIL practices, with plannings, statistics, recurrent tickets and a Kanban view. For MA-7, you can model each field maintenance request as a change that carries the approval of the trusted maintenance facility, the named system and the site where work would occur. Check that your approval workflow forces a decision before work is scheduled, and that closed changes keep their original approval history. Ask whether your configured statuses can show that a request was refused, not only that it was completed.

Zammad for requests from remote sites

Zammad is a web-based helpdesk that brings customer communication from email, chat, telephone and social media into one ticket system. Field maintenance requests often start with a call or email from a remote site engineer, so routing those messages into a single ticket keeps the initial request, the caller's identity and the timestamps in one record. Confirm that requests raised by phone or chat are logged as tickets before any work begins, and that the site contact is recorded against each ticket.

Mapping tickets to trusted facilities

MA-7 limits field maintenance to facilities the organization has defined as trusted, so the ticket should show which facility or vendor performed the work. In either tool, create a field that records the approved facility, its personnel and the equipment removed or serviced at the deployed location. Illustratively, a ticket for a rack controller repair should name the approved facility, not a generic vendor queue. Review the facility list at a defined interval and retain the version in force on each ticket date.

License obligations for both tools

GLPI is licensed under GPL-3.0-or-later and Zammad under AGPL-3.0-only. The difference matters if you modify either product and offer it to users over a network, because AGPL-3.0 requires source availability for network-accessed modifications while GPL-3.0 is triggered by distribution. Ask your counsel which obligations apply to your internal customizations, plugins and hosting model before you deploy either tool in a regulated environment.

Tickets do not prove enforcement

A helpdesk record shows that a process was followed, but MA-7 also asks for restriction or prohibition of field maintenance. Tickets cannot block a technician from working on a deployed component. Confirm with your engineers which technical mechanisms, such as physical access control, disabled remote paths or configuration locks, actually restrict field work, and retain their configuration records as separate evidence alongside the tickets.

What meeting MA-7 field maintenance costs

This table lists the cost components of meeting MA-7 and shows who carries each one, whether it is one-time or recurring, and what moves it up or down. No supplied fact sets a price or duration for this control, so the figures are qualitative. Use the drivers column to scope a written quote.

Cost component	Who is paid or who does the work	One-time or recurring	What drives it up or down
Defining field-maintainable components and sites	Organization staff, with implementation partner support if scoped	One-time, revisited on change	Up with the number of field-maintainable components and sites; down with narrow, written definitions
Defining the trusted maintenance facility list	Organization staff and procurement, sometimes legal	One-time, updated on vendor change	Up with the number of third-party vendors; down with a single consolidated facility list
Policy and procedure drafting for field maintenance	Organization policy owners, implementation partner if scoped	One-time, then periodic review	Up if the MA-1 policy set is not already in place; down when field maintenance extends an existing procedure
Configuring enforcement mechanisms	Platform or infrastructure engineers, implementation partner if scoped	One-time, with later changes	Up with the number of distinct systems and enforcement points; down with standard, reusable configuration
Open-source helpdesk and ticketing setup	Platform engineers; tooling is open source, so license spend is avoided	One-time setup, then hosting and upkeep	Up with integrations and custom workflows; down with out-of-the-box ticket and approval use
Staff time for approvals and exceptions	Maintenance approvers and system owners	Recurring, per field maintenance event	Up with frequent exceptions and ad hoc visits; down with pre-approved facilities and clear exception criteria
Evidence upkeep and records retention	Compliance and operations staff	Recurring	Up with the number of sites and events sampled; down with automated ticket records and consistent naming
External review and auditor sampling	Independent assessor or auditor (not DeployOpen)	Periodic, per assessment cycle	Up with the number of sampled events and sites; down with a clean, complete record set

Where field maintenance controls usually fall short

Field maintenance controls tend to fail at the edges: the policy says prohibit, but nobody has defined what is covered, who is trusted, or how exceptions end. The gaps below share a root cause. The organization decides on paper what happens at the deployed site but never builds the records that show the decision was enforced.

Prohibition with no enforcement

The maintenance policy says field maintenance is prohibited, yet no technical or procedural step stops it. Engineers can still plug a laptop into a deployed controller or reset a device on the floor. To close the gap, pair the policy statement with a written procedure that names who may stop unapproved work, how site access is logged, and how a violation is reported. Ask the assessor which evidence would show the prohibition operating, not just being written down.

Components never defined

MA-7 applies to systems or components the organization defines, and many programs never define them. Without a list, no one can say whether a vendor visit to a substation cabinet counts as field maintenance. Build an inventory of deployed components that are restricted, tied to the asset register and the system security plan, and reviewed when hardware or firmware changes. An undefined component is an open question at assessment time.

Trusted facilities never listed

The control limits field maintenance to trusted maintenance facilities, but many organizations never name them. Staff then assume a vendor depot or a contractor's repair shop qualifies without any documented review. Maintain a named list of approved facilities with the trust basis for each, such as contractual security terms, personnel screening and chain-of-custody practices. Confirm that the list is approved by the same owner who approves the policy.

Vendor engineers on site without approval

Vendor engineers arrive for an urgent fix and start work before anyone records an approval. The gap is not the visit itself but the absence of a record linking the person, the component, the reason and the approving owner. Require a site work order before any field visit, check the visitor and escort log against it, and treat a visit without an order as a reportable event. Related controls such as MA-2 and MA-5 cover the same people from different angles, so keep the records consistent.

Exceptions with no expiry

A one-time exception to allow on-site repair often becomes permanent because nobody sets an end date. Each exception should state the component, the scope of work, the approver, the start date and an expiry, after which access is revoked and the exception is closed or renewed with fresh approval. Review open exceptions at each policy review. Ask who owns the exception register and how often it is checked against actual site activity.

Diagnostic records not kept

Assessors examine diagnostic records to test whether field maintenance was carried out as approved. Many teams record the outcome of a repair but not the commands run, the software or firmware versions touched, the configuration changes made or the tools connected. Keep a dated record for every field session that captures what was done, by whom, on which component and what was verified afterward. Store these records where they cannot be quietly edited, and sample them before an assessment begins.

Questions buyers ask about MA-7 field maintenance

Is MA-7 field maintenance required by default under SP 800-53?

No. MA-7 is not allocated to the low, moderate or high baselines or to the privacy baseline in SP 800-53B, so it applies only when your organization adds it during tailoring. Typical triggers are a contract clause, a customer or regulator requirement, or a risk decision that onsite maintenance at deployed locations must be restricted. Your authorizing official or the program that owns the system decides whether it applies, and the decision should be recorded in the system security and privacy plan. Ask your assessor early whether they expect MA-7 to be in scope for your system, because a control added late can change the evidence you need.

How much effort does MA-7 take to implement and evidence?

Effort depends mainly on how many systems and components are deployed outside your controlled facilities, how many maintenance providers touch them, and how much maintenance is already done remotely or onsite. The control has one determination statement in SP 800-53A, so the assessment itself is narrow, but the preparation can span policy, procedures, configuration settings and maintenance records. The main cost components are internal staff time to define the restricted systems and trusted facilities, the work to write the procedure, and the time to collect diagnostic records for assessors. Ask any provider to break its quote into scoping, documentation, configuration and evidence collection, and to state which items recur each year.

How long does MA-7 work take, and what does it depend on?

The duration depends on the number of deployed systems in scope, how well current maintenance practices are documented, and whether trusted maintenance facilities are already defined. Organizations with a clear inventory of field-deployed components and an existing maintenance policy usually move faster than those that must first establish which sites exist and who visits them. Schedule dependencies also matter, since the work often needs the maintenance contracts reviewed alongside MA-2, MA-4 and MA-5. No duration is set by NIST, and NIST leaves federal implementation timelines to OMB Circular A-130. Ask for a timeline tied to a written scope with named systems and agreed deliverables.

What does MA-7 require from our own staff?

Your staff must own the decisions that a partner cannot make for you. These include which systems or components are restricted or prohibited from field maintenance, which facilities count as trusted, and which personnel have maintenance responsibilities. Staff are also needed to review maintenance records, confirm that restricted sites are enforced in practice, and interview with assessors who ask about field maintenance processes. Expect system administrators and the teams that manage deployed hardware or software to contribute. A partner can draft procedures and collect configuration evidence, but the organization must approve the policy and operate the process.

Can we implement MA-7 in-house with open-source tools?

Often yes for the record-keeping side, though the control itself is a process and a restriction, not a tool. Self-hosted helpdesk and service management platforms can hold the approvals, tickets and change records that show when field maintenance was requested, who approved it and which trusted facility performed it. GLPI's Assistance module, for example, supports tickets, problems and changes following ITIL practices, which can serve as the maintenance request trail. Zammad is a web-based helpdesk that centralizes ticket communication. Confirm with each vendor whether a given workflow meets your assessor's sampling needs before you rely on it. DeployOpen can install and configure self-hosted platforms in your own infrastructure, but the choice of tools and the policy remain yours.

What will an assessor sample when testing MA-7?

According to SP 800-53A, an assessor examines the maintenance policy, procedures addressing field maintenance, system configuration settings and related documentation and diagnostic records. They interview personnel with system maintenance responsibilities and system or network administrators. They also test the organizational processes for managing field maintenance and the mechanisms that implement or support it. In practice, expect requests for the list of restricted systems, the trusted facility definitions, examples of approved field maintenance events, and proof that restrictions are enforced. Prepare samples in advance, because gaps in the record trail are the most common reason an assessment stalls.

Can a consultant or partner issue the MA-7 assessment result?

No. A partner such as DeployOpen can prepare systems, controls and evidence for an assessment, but it cannot issue assessment reports, attestations or certifications. Those outputs come from an independent assessor or an authorizing official within the organization's governance structure, depending on the program. For a federal or contract-driven assessment, confirm who is accepted as the assessor under your contract or program rules before engaging anyone. Written scope should separate what the partner delivers, such as procedures, configuration evidence and test support, from what the independent assessor determines.

How DeployOpen works on this

DeployOpen prepares the systems, documents and evidence that let an organization show how field maintenance is restricted or prohibited at deployed sites and limited to trusted maintenance facilities. The organization owns the control and its decisions about which systems and components are covered, and an independent assessor reaches the conclusion.

How we scope

Confirm which systems and components the organization has defined as covered by field maintenance restrictions
Record whether field maintenance is prohibited outright or permitted only at named trusted maintenance facilities
Agree in writing which MA-7 examine, interview and test objects the engagement will prepare, and which stay with the organization
Engagements are fixed-scope, with deliverables and timelines agreed before work starts

How we build

Configure the self-hosted service desk so field maintenance requests route through ticket workflows with named approvals
Set up ticket categories, change records and maintenance planning so each field visit has an owner, a site and a facility
Document the mechanisms that enforce the restriction, such as access rules and maintenance facility lists, for assessor review
Test the workflow end to end and capture diagnostic and configuration records that an assessor can sample

How we hand over

Deliver the field maintenance procedure, configuration documentation and sample records mapped to the MA-7 assessment objects
Provide a list of open gaps, owners and dates so the organization can close them before assessment
Walk the organization's staff through the workflow so they can run it without DeployOpen involved
Note clearly that DeployOpen prepares evidence, while only an independent auditor or assessor issues conclusions

How we support

Review the field maintenance records and approvals on a schedule agreed with the organization
Update workflows and documentation when the system, facility list or applicable requirements change
Ongoing support, upgrades and continuous testing are available as a retainer, scoped in writing
Ask any provider to confirm how its platform handles the field maintenance capabilities you need before committing