What MA-6 timely maintenance requires before an assessor arrives
If your system is categorized at the moderate or high impact level, MA-6 asks you to show that failed components can be repaired or replaced within a time you have defined in advance. The requirement is to obtain maintenance support or spare parts for the components you name, within a defined period after a failure. NIST's discussion ties this to having appropriate contracts in place, so an assessor will expect to see the support agreements, service-level terms or spares arrangements that make a timely response possible, not only a statement of intent. MA-6 is allocated to the moderate and high baselines in SP 800-53B and is not part of the low baseline or the privacy baseline, so confirm your baseline selection in your system security plan before you invest in it.
The hard part is not the contract itself. It is deciding which components count and how fast each must be restored. Start from your inventory, using a source such as the component records in your configuration management database, and mark the items whose failure would raise risk to the system's confidentiality, integrity or availability. For each, record the vendor, the support tier, the spare parts position and the time window you will hold yourself to. Assessors test the defined window against what the contract actually delivers, so a window that no agreement can meet will fail even if the paperwork exists. Ask your vendors to confirm response and parts-delivery times in writing, and ask your acquisition team which contracts already cover each item.
The control has three enhancements in SP 800-53 Release 5.2.0: one on preventive maintenance, one on predictive maintenance and one that relates maintenance to the organization's wider risk and supply chain activity. None is allocated to an SP 800-53B baseline, so they are optional unless your authorizing official or contract requires them. Confirm that requirement early, because it changes what evidence you need to produce. The assessment procedure in SP 800-53A examines the maintenance policy, service contracts, service-level agreements and spare parts inventory, interviews maintenance and acquisition staff, and tests whether timely maintenance actually happens. Your readiness check is to pick one high-impact component, trace it from the inventory entry to the contract and to the last maintenance record, and confirm the dates line up.
Which components and contracts fall under MA-6 scope
MA-6 applies only to the system components the organization defines, so scoping is the first decision and it drives everything after it. The cards below cover the component classes, the third parties that carry the obligation, and the scoping choices that change how much work the control requires.
Defining the components in scope
MA-6 asks the organization to name the system components for which maintenance support or spare parts must be available within a defined period after failure. Start from the system inventory and mark each component whose failure would materially affect the system's confidentiality, integrity or availability. Record the decision and the reasoning in the system security plan so an assessor can trace which components were included and which were excluded.
Hardware and physical server platforms
Servers, storage arrays, workstations used for privileged functions and hardware security modules are the components most often named in MA-6 scope. Vendor support coverage, replacement part lead times and on-site response terms all differ by model and must be checked individually. A server with a support contract that expires before the system's planned retirement is a gap an assessor will ask about.
Network equipment and security appliances
Firewalls, routers, switches, load balancers and boundary devices often carry the highest failure impact because a single device can isolate an entire enclave. Confirm which devices have active vendor support, whether spares are held on site or under a vendor replacement commitment, and how quickly a failed unit can be swapped. Devices that are end of support should be documented with a risk decision rather than left unlisted.
Vendor-supported software and firmware
MA-6 covers maintenance support for components, which includes firmware and software that the vendor must patch or repair. Identify which packages depend on a commercial support agreement and which rely on community support or internal engineering. Open-source components without a paid support path should be recorded with the internal or third-party party that accepts responsibility for fixes and the time it commits to.
Managed service providers and contract terms
When a managed service provider operates or repairs components, the obligation for timely support often sits in its contract, not in the organization's own team. Review service-level agreements for response and restoration times, spare parts provisions and the provider's own maintenance records. The contract must match the time period the organization defines for MA-6, and gaps should be closed by amendment before an assessment.
Scoping by impact level and criticality
SP 800-53B allocates MA-6 to the moderate and high baselines only, so low-impact systems do not inherit the control by baseline. Within a moderate or high system, the organization may still set shorter response periods for components whose failure would disrupt critical functions than for those with redundancy. Ask the assessor and your own risk owner to confirm the defined period per component class, and document it so that the period is not chosen after an outage.
How an assessor tests MA-6 under SP 800-53A
This table maps the single SP 800-53A determination statement for MA-6 to the examine, interview and test methods an assessor uses, the evidence each method asks for, and where the control usually fails. Read it as a checklist of what to have ready before an assessment starts.
| Assessment method | What the assessor asks for | Common finding |
|---|---|---|
| Examine: maintenance policy and procedures | Documented policy and procedures that address timely maintenance for defined system components, with named owners and review dates | Procedures mention maintenance in general terms but never define the time period for obtaining support or parts |
| Examine: service provider contracts and SLAs | Support contracts and service-level agreements showing which components are covered, the response or replacement commitment, and the contract term | Contracts exist but do not list the components in scope, or the agreed restoration window is missing |
| Examine: spare parts inventory and availability | Inventory records for critical spares, vendor availability confirmations and lead-time documentation tied to the defined components | No record shows that spares exist, are stored or can be delivered within the defined period |
| Examine: component inventory linked to maintenance scope | Asset inventory showing which components are defined as needing timely maintenance and their support status, such as end-of-support dates | Components with expired support or no vendor are not flagged, so the defined scope is incomplete |
| Interview: maintenance and system administrators | Staff describe how failures are escalated, who calls the vendor and how spare parts are requested, and match the written procedures | Staff describe an informal process that differs from the documented procedure or depends on one person |
| Interview: acquisition personnel | Owners of purchasing describe how support terms are negotiated, renewed and tracked before contracts lapse | Renewals are handled by procurement with no link to the system owner, so coverage lapses unnoticed |
| Test: process for timely maintenance | A walkthrough or sample of a past failure or simulated request, showing the time from failure to vendor engagement or part delivery against the defined period | The defined period is never measured, so the organization cannot show that the process works in practice |
Implementing MA-6 step by step
This sequence turns MA-6 from a statement in a policy into a maintained register of critical components, agreed response arrangements, and a tested process an assessor can sample. Each step hands over a specific artifact that the next step depends on.
Identify components whose failure raises risk
Start from the system inventory and mark each component whose failure would materially affect confidentiality, integrity or availability, such as core network devices, storage arrays, hypervisors, authentication services and security tooling. The system owner and security lead agree the list and record the reason each item is included. Done means a reviewed list of in-scope components, each tied to a system in the security plan. Because MA-6 is allocated only to the moderate and high baselines, confirm the baseline for each system before you scope the list.
Set the maintenance time period for each component
For every component on the list, the organization defines the period within which maintenance support or spare parts must be obtained after a failure. The period comes from the system's availability requirements, recovery objectives in the contingency plan and business owner input, not from a generic default. Record the agreed period against each component and the approver. Done means every listed component has a documented period and a named owner who accepted it. Confirm with the business owner that the period is achievable under the support arrangement you select.
Match each component to a support or spare parts arrangement
For each component, document how maintenance support or a replacement part will be obtained: a vendor support contract with a stated response and parts commitment, a third-party maintainer agreement, or an internally held spare with a named storage location. Where a component has no support arrangement, record that as a finding and decide whether to accept, replace or add coverage. Done means every component maps to one arrangement and each contract's terms are checked against the period set in the previous step. Ask the procurement team for the contract documents, not summaries.
Record inventory, spares and availability
Build the register that shows what is held, where, and whether it is still available. Use the asset inventory for installed components and record spares separately with serial numbers, location, condition and the date the arrangement was last confirmed. Include contract expiry and end-of-support dates so that unsupported components are visible before they fail. Done means the register can be sampled by an assessor and reconciled against the asset inventory with no unexplained gaps. Confirm the register is updated when hardware changes.
Document the timely maintenance process
Write the procedure that tells operations staff what to do when a listed component fails: who raises the request, how the support contract is invoked, how a spare is requisitioned and installed, how the time period is tracked, and when escalation occurs. Link the procedure to the MA policy, incident handling and contingency plan so the roles match. Done means the procedure names roles, not individuals, and has an owner, a version and an approval date. Confirm that the procedure references the register and contract documents by location.
Test the process and retain the results
Run a controlled exercise that follows the documented procedure for at least one listed component, such as a tabletop walkthrough that calls the support provider or a supervised spare request. Measure the elapsed time against the defined period and record any gap. Feed findings back into the register, contracts or procedure, and track corrective actions. Done means a dated test record, the observed timings, and the changes made as a result. The test record is the evidence an assessor will ask to see for the timely maintenance process.
Evidence that passes MA-6 and how to keep it current
An assessor testing MA-6 looks for proof that the organization identified the components whose failure creates risk and could obtain support or spare parts within its defined time period. The artifacts below connect policy, contracts, inventory and records of real failures, and each one goes stale unless someone refreshes it between audits.
Current maintenance support contracts
Assessors examine the service provider contracts that make timely maintenance possible, and the NIST discussion for MA-6 treats appropriate contracts as part of obtaining maintenance support. For each component in scope, keep the contract, the covered products, the support tier and the expiry date in one register. Check that every component named in the system inventory is covered, and that no contract has lapsed without a documented renewal or replacement decision.
Service-level agreements with defined response times
Assessors look for the defined time period in the control and whether the organization's agreements specify how quickly support or parts must arrive. Record the response and restoration times per component class, and confirm they match the time the organization set for its own systems. Where a vendor offers only best-effort support, document the gap and the compensating action, such as a standby system or a spare unit.
Spare parts inventory with locations
The examine method for MA-6 explicitly includes the inventory and availability of spare parts. Keep a list of spares by component, with quantity, physical location, serial or part numbers, and the last date someone confirmed the item was on hand and usable. Where spares are held by a vendor or a third party, record the agreement that gives access to them. Recount stock on a set schedule and reconcile it against the asset records.
Maintenance policy and procedure
The policy and procedures define what the organization treats as a timely maintenance event, who owns contract and spares management, and how a failure gets escalated to the vendor. Assessors examine these documents first. Confirm the procedure names the roles, the escalation path and the defined time periods, and that the review date and approver are current. Map the procedure to the MA-1 policy so the two do not drift apart.
Records of timely maintenance after failure
Assessors test whether timely maintenance happened in practice, so keep a record for each failure: the time it was detected, the ticket opened, the vendor or spare requested, the time support or parts arrived, and the time the component returned to service. Compare each event against the defined period. Where a response missed the target, record the root cause and any change to the contract or stock. A helpdesk ticket history can supply these timestamps.
Refreshing contracts and counts between audits
Stale evidence is the most common reason MA-6 findings occur. Set a recurring review that checks contract expiry dates against a calendar with advance warning, recounts spares against the inventory list, and confirms the component list still matches the system. Pull the component list from the asset inventory, which can be fed by the GLPI Agent or Wazuh Syscollector, and flag any new hardware that has no support coverage. Keep dated snapshots so an assessor can see the state at each review.
What meeting MA-6 costs in money and effort
This table breaks down the money and effort behind MA-6, separating one-time build work from recurring support and evidence upkeep, and naming who is paid for each. Use it to frame a quote request: most of the recurring spend sits with vendor support contracts and spare parts, while the one-time effort sits with building the component register. No public figures are supplied for these components, so each cell points to what to ask for or confirm.
| Cost component | Who is paid, and when | What drives it up or down |
|---|---|---|
| Vendor support contracts | The hardware and software vendors or maintenance providers, recurring over the contract term | Number of components covered, required response windows, and whether coverage is per device or per site |
| Spare parts stock | The organization or its supplier, usually recurring as parts are bought, held and replaced | Components with long lead times, single points of failure, and the defined restoration period |
| Component register and inventory build | Internal staff or an implementation partner, one-time, with periodic refresh | Number of systems in scope, quality of existing asset data, and how many components are judged failure-critical |
| Evidence upkeep | Internal staff, recurring, to keep contract, inventory and availability records current | Frequency of hardware changes, contract renewals, and how much of the inventory is collected automatically |
| External review of contracts and SLAs | Legal, procurement or an advisor, typically at signing and renewal | Number of distinct support agreements and whether they already state response times and parts availability |
| Auditor sampling time | Internal staff supporting the assessor, during each assessment cycle | Number of components and contracts sampled, and whether records can be produced quickly without manual reconstruction |
| Open-source tooling | Licensing is typically no cost for the GPL and AGPL products named, but hosting, administration and integration are paid | Use of existing asset tools, scale of the deployment, and internal or partner capacity to run them |
| What to ask for in a quote | Itemized scope per component class, one-time and recurring fees shown separately, and assumed response windows | Written statement of which components are in scope and which vendor contracts are assumed to exist |
Who owns MA-6 and what an implementation partner can take on
The organization owns MA-6. Assessors test whether the organization obtains maintenance support or spare parts for the components it defines within a defined time after failure, and that obligation sits with the organization's leadership and its system owner, whatever a vendor promises. The decisions that cannot be delegated are which components are in scope, what time window applies to each, and whether the organization accepts the residual risk when a support contract does not meet that window.
- Contracts and service levels: Negotiate and sign the support contracts, hardware maintenance agreements and spare parts arrangements that the time windows depend on.
- Time windows: Define, document and approve the restoration or parts-delivery period for each component, based on the system's impact and mission needs.
- Risk acceptance: Record any component where no support or spares exist within the window, with a named approver and a review date.
- Ownership of the record: Keep the component inventory, the support status of each item and the procedures that cover escalation when a vendor misses a window.
Before relying on any partner, confirm that your own team can name the owner of each support contract and the approver of each time window.
An implementation partner prepares the systems and evidence that support MA-6 under a fixed, written scope. DeployOpen plans, implements and documents self-hosted open-source platforms inside the client's infrastructure, so the partner's work centers on the records and technical proof that show the control operates. The partner does not sign support contracts on the organization's behalf, does not accept risk, and does not issue an assessment result.
- Component inventory: Build a current list of in-scope components with make, model, version, location and the support status reported by the owner, drawing on discovery data where the platform can collect it.
- Evidence pack: Assemble the maintenance policy references, support contract records, service-level documents and spare parts availability records that an assessor will examine.
- Test plan: Draft a test plan that shows how the organization will demonstrate timely maintenance, including sample events and the records each test needs.
- Monitoring setup: Configure inventory and alerting so that components approaching end of support or missing a response window are visible to the owner.
Confirm the scope, deliverables and acceptance criteria in writing before work starts, and confirm which items the partner will not perform.
The independent auditor tests MA-6 and issues the opinion. An auditor or assessor is independent of both the organization and any implementation partner, and only that party reports on whether the control is implemented and operating. Under NIST's assessment procedure for MA-6, the auditor examines documents, interviews staff and tests the organization's processes for timely maintenance, so the auditor will want to see the work done, not a description of it.
- Examination: Reviews the maintenance policy, procedures, service provider contracts, service-level agreements and the inventory and availability of spare parts.
- Interviews: Speaks with maintenance staff, acquisition staff and system or network administrators to confirm how timely maintenance is actually arranged.
- Testing: Checks the processes that ensure timely maintenance, often by following a sample of real maintenance events to their records.
- Reporting: Documents findings and the assessment result. Neither the organization nor the implementation partner can issue this output.
Ask the auditor early which assessment method and sample sizes they expect, and whether they accept evidence produced by an implementation partner.
Where MA-6 evidence usually falls short
MA-6 is tested on whether the organization can actually get maintenance support or spare parts within a time it has defined. Assessors usually find the same few gaps: the time period was never set, the contract does not cover the component, the agreement lapsed, or the parts are listed but not obtainable. Each card below names one gap and the step that closes it.
Undefined response time periods
MA-6 requires a defined time period after failure, and an assessor cannot test timeliness against a target that does not exist. Many programs say maintenance will be done "promptly" or "as soon as possible" with no number attached. Set a response and restoration window for each component class, tie it to the system's impact level and recovery objectives, and record it in the maintenance policy and the support agreement so the two match.
Components without a support contract
The discussion for MA-6 treats appropriate contracts as the way to obtain maintenance support, so a component with no contract has no basis for a timely response. Gaps often sit in older hardware, network devices, peripherals and software bought outside the main procurement path. Reconcile the asset inventory against contract records, flag every component with no coverage, and decide for each whether to contract, replace or accept the risk in writing.
Expired or unclear support agreements
A contract that lapsed last quarter does not support a timely response today. Assessors check service-level agreements against the defined time period, so a vendor promising a four-hour response on a different basis than the organization's own target is a finding. Keep a register with start and end dates, renewal owners and the exact response terms, and set reminders well before expiry so renewals do not depend on someone remembering.
Spare parts recorded but not available
The MA-6 assessment looks at the inventory and availability of spare parts, not just a list. A spreadsheet entry for a spare that sits in a distant warehouse, is already allocated to another system or has no stock at all will not show timely recovery. Verify physical location and status for critical spares, confirm lead times with suppliers, and record which spares support which components so the availability claim can be traced.
No test of the timely maintenance process
The determination statement for MA-6 is tested, which means the organization should be able to show that its process for timely maintenance works in practice. Many programs have a policy and a contract but have never run a request through the process end to end. Run a tabletop or live exercise that opens a maintenance ticket, escalates to the vendor, and measures the time to restoration against the defined period. Keep the ticket history and the results as evidence.
MA-6 questions buyers ask before hiring help
What drives the cost of MA-6 preparation?
The main cost drivers are the number of system components in scope, how many of them already have a support contract or known spare-parts source, and how much of the inventory and contract record has to be built from scratch. Costs fall into two groups. One-time work covers defining which components matter, collecting vendor support terms, building the inventory and writing the procedure. Recurring work covers keeping the inventory current, renewing contracts and refreshing evidence before each assessment. NIST does not estimate compliance costs, so no benchmark figure is available here. Ask any partner for a fixed-scope quote that lists the components covered, the deliverables, and which items are the client's responsibility, such as contract renewals paid to the vendor.
How long does MA-6 preparation take?
There is no fixed duration. The time needed depends mainly on the number of components the organization defines as high risk to fail, the state of its existing asset records, and how quickly it can obtain support terms from its vendors. An environment with a current inventory and documented support contracts needs far less preparation than one where components and contracts must be discovered first. NIST does not set implementation timelines for SP 800-53. Ask for a written schedule tied to the agreed component list, and confirm which milestones depend on vendor responses that the client cannot control.
What does our team have to provide for MA-6 work?
The client's team owns the decisions and the source records. In practice this means:
- Named owners who can state which components are critical enough that a failure would raise risk.
- Access to the asset register, change records, and existing vendor or support contracts.
- Someone with authority to sign off on the defined time period within which support or spare parts must be obtained.
- Procurement contacts who can confirm contract scope, service levels and spare-parts availability.
An implementation partner can organize and document this material, but it cannot decide which risks the organization accepts or negotiate contracts on its behalf. Confirm these responsibilities in the written scope before work starts.
Can open-source tools produce MA-6 inventory evidence?
Yes, a self-hosted stack can produce much of the inventory evidence, but it cannot supply the contract evidence by itself. GLPI's Assets module can record computers, network equipment, peripherals and racks, entered manually or pushed by the GLPI Agent through native inventory built into GLPI since version 10. Wazuh's Syscollector module collects hardware, operating system, software and Windows update data from endpoints and presents it in dashboard inventory views and reports. Zammad can hold the maintenance request tickets, and Grafana Alerting can notify teams when monitored components fail. Support terms, service-level agreements and spare-parts arrangements still come from vendor contracts. Confirm with each tool's documentation which fields and reports you need before relying on them as assessment evidence.
Can a partner replace the independent assessor for MA-6?
No. A partner can prepare the inventory, contract summaries, procedures and test records, but only an independent assessor or auditor reviews the controls and reports on them. The organization owns its controls. DeployOpen prepares systems, controls and evidence for compliance assessments and does not issue audit reports, attestations or certifications. Under the NIST model, the assessment itself is carried out against the SP 800-53A procedure for MA-6, which asks assessors to examine policy, service provider contracts and spare-parts inventory, interview maintenance and acquisition staff, and test whether timely maintenance processes work. Confirm with your authorizing body or customer which assessor qualifications they accept.
Does MA-6 apply to every system we run?
Not necessarily. SP 800-53B allocates MA-6 to the moderate and high baselines only, so a system categorized as low impact does not carry it as a baseline control. It is also not part of the privacy baseline. Your system's categorization, its contract or authorization package, and any tailoring decisions determine whether MA-6 is in scope. Confirm the baseline with the authorizing official before scoping work, because a partner that assumes full coverage may define more work than the requirement needs.
What should we ask for in a MA-6 proposal?
Ask for a written scope that names the baseline, the component list and how components were identified as high risk to fail. Request a list of deliverables, such as the inventory export, the support contract register, the timely maintenance procedure and test records. Ask which items the partner produces, which the client owns, and which need a third party. Confirm the tools proposed, the data sources they read from, and who maintains them after handover. Finally, ask how changes to the component list will be handled and what fixed-scope terms apply to the work.
Which MA-6 enhancements do we have to implement?
SP 800-53 Release 5.2.0 defines three active enhancements for MA-6, covering predictive and preventive maintenance among other topics, and none of them is allocated to an SP 800-53B baseline. That means they are optional unless your authorizing body, contract or risk assessment requires them. Confirm with the authorizing official whether any enhancement is required, and check the NIST catalog for the exact wording before scoping. Including enhancements in scope can add effort, so decide them deliberately rather than by default.
Using self-hosted open-source tools to keep the MA-6 inventory current
MA-6 is only as good as the list of components it covers. Before an assessor can test whether maintenance support or spare parts arrive within the defined window, the organization needs a current record of which components matter, their versions and the support arrangement behind each one. GLPI's Assets module can hold computers, network equipment, peripherals and racks, entered manually or pushed by the GLPI Agent through the native inventory built into GLPI since version 10. Record the contract reference, support end date and the window you have defined against each high-impact asset, so the inventory shows the link between component and support commitment. Wazuh's Syscollector complements this by collecting hardware, operating system, installed software, network interfaces and services from each endpoint into the Wazuh indexer, which gives you versions and states that match what is actually running rather than what was documented.
Failure and repair timelines are the evidence assessors ask for most often. Zammad can hold a ticket for each failure, capturing when the fault was detected, when the vendor or maintainer was contacted, when support or a spare part was received and when the component returned to service. Use one ticket category for maintenance failures so the records can be pulled together for a sample. Grafana Alerting can then build alert rules from queries across your monitoring data sources and flag a component that has been down longer than the window you defined, routing the alert to the ticket queue. Confirm with your own monitoring team which data sources expose device availability in your environment, because the alert is only as reliable as the signal feeding it.
Licensing matters when these tools become part of an assessment package. GLPI is licensed under GPL-3.0-or-later, Wazuh's component under GPL-2.0-only, Zammad under AGPL-3.0-only and Grafana under AGPL-3.0-only. Review the obligations with your legal team before you modify or redistribute any of them. Finally, these tools produce evidence, but they do not replace the contracts or the time windows. The support agreement, its service levels and the defined window are decisions the organization owns and must document in its policy and procedures, and an independent assessor will test whether the tooling matches them. Treat the tools as the record of what happened, not as the source of what was promised.
How DeployOpen prepares MA-6 evidence
The sequence below turns MA-6 from a policy statement into a register of covered components, recorded support commitments and a tested timely maintenance process. Each step ends with a named output the client's assessor can examine, interview against or test.
Agree the component register and scope
DeployOpen works with the client's system owners, maintenance staff and acquisition team to list the system components whose failure would raise risk, such as hardware, network equipment, storage and critical software dependencies. The engagement is fixed-scope, so this boundary and the deliverables are written down before work starts. The client decides which components count, because MA-6 applies to the components the organization itself defines. The output is a signed scope document with a draft component register that the client owns.
Define time windows and support requirements
For each registered component, the client sets the time period within which maintenance support or spare parts must be obtained after a failure. DeployOpen documents these windows alongside the support route for each one, whether that is an internal team, a service provider or a spares holding. The client confirms the windows with its own risk owners, since the windows reflect its tolerance for downtime. The output is a time window table that the client approves and that feeds the support contracts and the test plan.
Review support contracts and spare parts
DeployOpen reviews the existing service provider contracts and service-level agreements against the approved time windows and identifies gaps, such as components without a support route or agreements that do not cover the response period. Where spare parts are relied on, the team checks their location and availability. The client decides how to close each gap and signs off any new contract terms. The output is a gap report that shows which components have a contract or spare part covering their window and which do not.
Deploy the inventory and ticket tooling
DeployOpen installs self-hosted tooling inside the client's own environment. GLPI can hold the Assets records for computers, network equipment, peripherals and racks, entered manually or pushed by the GLPI Agent. Wazuh Syscollector can gather hardware, operating system and software data from endpoints to check the register against what is running. Zammad can record maintenance requests and their timestamps as tickets, and Grafana Alerting can flag open requests that approach their time windows. The client confirms which of these platforms it already runs. The output is a working inventory and ticket setup with access controls the client has approved.
Configure maintenance request workflow
DeployOpen configures the ticket workflow so every failure or maintenance request is logged with the component, the time it was raised, the support route used and the time the component was restored or a part was obtained. Alert rules are set against the approved time windows so that overdue requests are visible to the maintenance owner. The client's staff run the workflow, and DeployOpen confirms each category and alert with them. The output is a documented workflow and a set of configured alerts that the client can show an assessor.
Assemble the MA-6 evidence pack
DeployOpen compiles the artifacts an assessor would look for under the examine method: the maintenance policy and procedures, the component register and time windows, the service provider contracts and service-level agreements, the spare parts inventory and the inventory exports from the tooling. Each artifact is dated, version-controlled and linked to the component it supports. The client reviews the pack for accuracy and approves it. The output is an evidence pack organized by component, ready for independent assessment.
Run the timely maintenance test
DeployOpen and the client run a tabletop or live test of the process for obtaining maintenance support or spare parts within the defined windows. The test uses a representative component, records the time from failure to support or part, and compares it with the approved window. Gaps are logged as findings with owners and remediation dates agreed by the client. The output is a dated test record that shows the process works as documented, or a list of findings that the client must address before assessment.
Hand over for independent assessment
DeployOpen hands over the evidence pack, test record and findings log to the client, along with a short walkthrough of how each piece maps to the assessment objects for MA-6. DeployOpen prepares systems, controls and evidence but does not issue audit reports, attestations or certifications. An independent auditor, assessor or certification body reviews the evidence and issues any report or certificate, and the client decides which assessor to engage. The output is a handover record that the client accepts.
